La torre de Babel de los datos

Son las dos de la madrugada y entra en urgencias una mujer de cuarenta y dos años. La llamaremos Vega. Está consciente, pero suda frío y le falta el aire; refiere un dolor en el pecho que no cede. El médico de guardia tiene minutos, no horas, para decidir, y para decidir bien necesita responder tres preguntas concretas: qué medicación toma a diario, si tiene alergias documentadas y si ya vivió antes un episodio parecido. Teclea su nombre en el sistema del hospital. La pantalla devuelve tres líneas: una bronquitis tratada hace cuatro años. Nada más.

Lo desesperante es que la información existe. Vega tiene una endocrinóloga que gestiona su historia desde hace siete años. Hace unos meses la evaluó un cardiólogo en otra ciudad. Y ya pasó por una urgencia muy parecida en un tercer centro, donde le hicieron un electrocardiograma completo. Cada dato está escrito, guardado en algún disco, y ninguno de esos profesionales tiene el menor interés en ocultarlo. El obstáculo no es el secreto ni la pérdida: es estructural. Los datos de Vega están repartidos en esquemas que no se hablan entre sí.

La endocrinóloga usa un software que guarda el diagnóstico en un campo llamado diagnostico_principal. El sistema del cardiólogo, hecho por otra empresa, lo registra como dx_p. Para la medicación, la primera clínica emplea una estructura plana (medicacion_actual con nombre, dosis y frecuencia); la segunda diseñó una base relacional con una tabla de prescripciones que pide un identificador numérico (farmaco_id), los miligramos por toma (mg_por_toma) y el número de tomas diarias (tomas_dia). Dos formas legítimas y razonables de anotar exactamente lo mismo. Y, sin embargo, incompatibles.

Si trabajas en software, ya sabes que conectar esas dos bases no es ciencia ficción. Es posible. Pero es un trabajo artesanal, caro y frágil: hay que programar un puente de código (un middleware), mapear a mano qué columna equivale a qué columna y escribir una excepción por cada formato de fecha o de número. Y ese puente caduca. El día en que una de las clínicas actualice su sistema y renombre un solo campo, el puente se rompe en silencio. Multiplica ese esfuerzo por miles de hospitales, decenas de proveedores y décadas de historias clínicas, y la integración deja de ser un reto de ingeniería para revelarse como un problema de diseño a escala planetaria. La información existe; lo que falta es la capacidad de razonar con ella.

La información de Vega no está perdida ni oculta. Está atrapada en idiomas que nunca acordaron hablar entre sí.El problema de Babel

El mismo hecho, cuatro idiomas distintos

El drama de urgencias es la versión extrema; pero el mecanismo que lo causa late en el sistema más banal. Para verlo en cámara lenta, bajemos a un escenario sin víctimas: una tienda de ropa. A las 16:32, en la tienda del centro, el vendedor 17 le vende una camiseta a un cliente. La llamaremos venta_001. Es un hecho del mundo, uno solo. Y, sin embargo, si nos asomamos a los servidores del negocio, descubriremos que sus distintos sistemas anotan ese mismo instante en cuatro lenguajes radicalmente distintos.

Para el punto de venta (la caja) lo que importa es la transacción y quiénes la protagonizan. El hecho se guarda como una fila en una base relacional:

INSERT INTO ventas
  (id, cliente_id, producto_id, monto, fecha, vendedor_id)
VALUES (1, 1042, 88, 49.90, '2026-05-14', 17);

Para contabilidad, en cambio, la identidad del vendedor o del cliente es irrelevante. Su única obsesión es que las cuentas cuadren por partida doble. El mismo evento se descompone en un asiento:

asiento: 2026-05-14
  debe:  cuentas_por_cobrar        49.90
  haber: ventas_brutas            42.29
  haber: impuesto_al_consumo       7.61

El equipo de analítica de producto ve otra cosa todavía. Le importa el comportamiento y el canal, para medir campañas. Estructura el hecho como un evento de telemetría:

{
  "evento": "compra_completada",
  "id_usuario": "u_1042",
  "sku": "sku-88",
  "ingreso": 49.90,
  "canal": "tienda_fisica",
  "id_sesion": "s_abcdef"
}

Y para inventario, por fin, solo ocurrió una cosa: una camiseta salió del almacén. El evento se reduce a un movimiento de existencias:

{
  "movimiento": "salida",
  "producto": 88,
  "cantidad": 1,
  "almacen": "tienda_central",
  "ref": "vta-1"
}

Observa la desconexión. Cuatro equipos, cuatro estructuras. Cada esquema es perfecto y coherente para quien lo diseñó. La fractura aparece cuando la dirección pide una visión global. Si le entregas estas cuatro piezas a una computadora, no tiene ninguna forma obvia de saber que las cuatro hablan del mismo suceso. Contabilidad no sabe quién vendió la camiseta; analítica no sabe de qué almacén salió; la caja no sabe separar el impuesto. Cada software capturó solo la sombra del evento que le interesaba y la archivó en su dialecto privado.

A esta fragmentación masiva la llamaremos, a lo largo del libro, la torre de Babel de las ontologías. Conviene desactivar una alarma: en datos, la palabra ontología no es un concepto filosófico inalcanzable.

El elefante en la habitación oscura

Hay una vieja parábola que describe esta torre de Babel mejor que cualquier diagrama de arquitectura. En una habitación a oscuras encierran a un elefante, y entran a tientas varios hombres que jamás han tocado uno. El primero palpa una pata y, convencido, anuncia: «esto es una columna». El segundo abraza la trompa y lo corrige: «no, es una gruesa manguera». Un tercero acaricia la oreja y jura que es un abanico; otro topa con el colmillo y asegura que es una lanza pulida; el último se aferra a la cola y sentencia que es una cuerda. Ninguno miente. Cada uno informa con honestidad lo que sus manos encontraron. Y, sin embargo, todos se equivocan, porque confunden la parte que tocaron con el animal entero.

Esa es, exactamente, la situación de nuestros sistemas. El punto de venta toca la pata y la nombra vendedor_id; contabilidad abraza la trompa y la llama cuentas_por_cobrar; analítica acaricia la oreja y la registra como evento; inventario topa con el colmillo y anota movimiento. Cada ontología de dominio es uno de esos ciegos: palpa una región de la misma realidad, la describe con rigor impecable dentro de su alcance y la bautiza con un nombre que no se parece a ningún otro. La torre de Babel no nace de la mentira ni de la incompetencia; nace de que cada quien toma su vista parcial por la totalidad.

Pero el elefante existe. Hay un animal completo debajo de las cinco descripciones incompatibles, y la pregunta decisiva es qué lo reconstruye. La respuesta es el corazón de este libro: lo que devuelve el animal entero no es una sexta ontología más fina, sino un repertorio de preguntas anterior a todas ellas. «¿Quién?», «¿qué?», «¿dónde?», «¿cuándo?», «¿cuánto?» y «¿cuál?» no tocan una parte del elefante: son las coordenadas que sitúan cualquier parte dentro del mismo cuerpo. La pata y la trompa dejan de ser objetos rivales y pasan a ser dos respuestas (al «qué» y al «dónde») de un único hecho.

La causa de todo el problema

La raíz de esta torre de Babel (y el punto de partida de este libro) se enuncia en una frase: hemos permitido que cada sector invente, desde cero, su propia forma de entender la realidad. La ingeniería médica no hereda nada de la contabilidad. El comercio no comparte cimientos con el derecho. La educación diseña bases que jamás conversarán con las del urbanismo. Cada industria levanta su pirámide con planos distintos y luego nos sorprende lo carísimo que resulta contratar gente para tender puentes colgantes entre las cimas.

Llevemos esa frase a un caso donde el aislamiento no cuesta dinero, sino una nave espacial.

El patrón es siempre idéntico. Donde cada parte cultiva su jardín semántico amurallado, el coste de conectar no crece poco a poco: crece de forma combinatoria. Si tienes n sistemas y los quieres comunicar de a pares, el número de puentes que debes construir y mantener es n(n−1)/2. Diez sistemas no piden diez traductores: piden cuarenta y cinco. Y cada uno de ellos es un punto que puede romperse.

Por eso el integrador de datos (ese rol que casi ninguna escuela enseña y que casi toda empresa necesita) existe. Su oficio es escribir y vigilar esos n(n−1)/2 puentes: los ETL que vacían una base en otra, los mapeos columna a columna, las excepciones por cada formato de fecha. Es trabajo valioso y, a la vez, trabajo que no debería existir. Es el impuesto que paga la industria por un pecado original de diseño.

Lo que ya se intentó (y por qué no bastó)

Sería injusto sugerir que nadie vio el problema. Llevamos décadas intentando derribar la torre, y los intentos se agrupan en dos familias, opuestas y simétricas en su fracaso. Vale la pena entenderlas, porque marcan exactamente el hueco que este libro quiere ocupar.

Y aquí cabe una pregunta incómoda, la que abre la puerta a todo lo demás: ¿y si la solución a este caos fuera anterior (y mucho más simple) que cualquier diseño de base de datos? ¿Y si, mucho antes de que existieran los hospitales, los bancos o el comercio internacional, la humanidad ya hubiera fijado un esquema cognitivo universal que nadie, en ningún idioma, puede evitar usar?

La apuesta de este libro

Volvamos a la venta una última vez. Si detuviéramos a cualquier persona en la calle (sin nociones de bases de datos ni de código) y le pidiéramos describir lo que pasó en esa tienda, su respuesta natural sería algo muy parecido a esto:

«El vendedor (quién) vendió (qué) una camiseta (qué) en la tienda del centro (dónde) esta tarde (cuándo) por casi cincuenta dólares (cuánto).»

Sin el menor esfuerzo, cualquier ser humano produce una descripción estructurada, completa y combinable. La mente no percibe el mundo como un bloque de texto ni como una hoja de cálculo: descompone cualquier evento con un repertorio brevísimo de preguntas fundamentales. Y aquí está el giro: esas preguntas son exactamente las coordenadas que las cuatro sombras de la venta estaban capturando por separado, sin saberlo.

Esa es, enunciada con todas sus letras, la apuesta del libro:

Y viene un beneficio que en 1999, o en 2010, habría sonado a ciencia ficción y hoy es decisivo: cualquier inteligencia artificial entrenada con lenguaje humano entiende esta estructura de fábrica, porque es la misma con la que aprendió a leer. Un modelo de lenguaje no necesita que le expliques qué es un «quién» o un «cuándo». Esas categorías ya viven en él. Si los datos del mundo se expusieran sobre los ejes de las preguntas, un agente tendría que aprender a hablar una sola vez —y no un dialecto nuevo por cada API que toca.

Conviene separar aquí las siete coordenadas en dos grupos, porque así las recorreremos. Seis fijan la posición de un hecho (dónde cae en cada dimensión de la realidad); la séptima, cómo, aporta los enlaces que amarran las otras seis entre sí:

Anticipando un poco la maquinaria que viene, así se ve un fragmento del hecho venta_001 expresado ya en el formato del modelo: cada línea es una tripleta que conecta el hecho con uno de sus valores, y la firma final declara a qué par de ejes pertenece:

(venta_001, agente,   vendedor_17)   ∈ M(O, Q)
(venta_001, lugar,    tienda_centro) ∈ M(O, L)
(venta_001, instante, 16:32)         ∈ M(O, T)
(venta_001, monto,    49.90)         ∈ M(O, N)
(venta_001, clase,    camiseta)      ∈ M(O, K)

No te detengas todavía en la notación; el capítulo 7 la desarma pieza por pieza. Lo único que importa ver aquí es que las cuatro sombras de la Figura 1.1 acaban de fundirse en un solo registro, y que ese registro es legible (de izquierda a derecha, como una frase) por cualquiera de los cuatro sistemas y por una máquina por igual.

Una promesa que se puede comprobar

No te pido que tomes esto como un acto de fe. La fuerza de la apuesta no está en que suene elegante, sino en que estas siete preguntas no son un invento moderno. Filósofos griegos, juristas romanos, escuelas de periodismo del 1900 y los propios niños que aprenden a hablar convergen (sin coordinarse, separados por siglos) en la misma lista. Cuando tantas tradiciones independientes llegan a la misma respuesta, esa respuesta deja de ser una hipótesis y empieza a parecer un descubrimiento.

A esa convergencia (la prueba de por qué estas preguntas y no otras) le dedicamos un capítulo entero. Pero no hace falta esperar a la demostración para empezar a construir. De hecho, conviene construir primero: ver la maquinaria funcionando convence más que cualquier argumento.

Lo que sigue es, sencillamente, la ingeniería. Vamos a diseccionar las siete coordenadas una por una: su carga de significado, sus trampas, los casos límite donde parecen romperse. Empezaremos por las cuatro más concretas (quién, qué, dónde y cuándo), porque son el suelo firme sobre el que se levanta todo lo demás. La paciente Vega nos espera al final del camino; cuando volvamos a su sala de urgencias, la consulta imposible de esta noche será una sola línea.