Integrar cinco sistemas que guardan los mismos hechos con cuatro nombres
distintos no es un problema de ETL. Es un problema de comprensión. Y los
agentes de IA lo heredan tal cual.
Introducción
Ayer definimos el salto de datos a conocimiento. Hoy atacamos la primera
pared que lo bloquea: los sistemas de una empresa no se entienden entre sí.
No porque sean de fabricantes distintos o hablen formatos incompatibles —
eso es la mitad fácil —, sino porque no comparten un significado acordado
para las cosas que nombran.
Esa pared tiene nombre, y es uno de los más antiguos de la ingeniería de
datos: semántica.
El problema
El ejemplo clásico, y el que encontraremos en casi cualquier empresa que
intente desplegar un agente sobre sus sistemas, tiene esta forma:
| Concepto | Sistema A (CRM) | Sistema B (ERP) | Sistema C (Facturación) | Sistema D (Legacy) |
|---|---|---|---|---|
| La organización que compra | customer |
account |
client |
party |
| La persona de contacto | contact |
business_partner |
client_contact |
party_contact |
| La relación comercial | opportunity |
sales_order |
— | deal |
| El documento | quote |
quotation |
invoice_draft |
order_form |
Cuatro sistemas, cuatro vocabularios, y una trampa: los nombres no solo
difieren, se solapan. «Customer» en el CRM y «account» en el ERP a veces
son la misma cosa, a veces son cosas distintas (en el ERP, «account» puede
ser una cuenta financiera; en el CRM, una organización). Y «party» en el
sistema legacy puede ser un cliente, un proveedor, un empleado o un
contribuyente fiscal, según la tabla.
Ahora imagina a un agente de IA que recibe esta pregunta: «¿Cuánto nos
debe nuestro mayor cliente?». El agente tiene acceso a los cuatro sistemas.
Puede contar customers en el CRM, accounts en el ERP, clients en
facturación y parties en el legacy. ¿Cuál es el «mayor cliente»? ¿Medido
por facturación (ERP), por oportunidades abiertas (CRM), o por saldo
pendiente (facturación)? Y «cliente»: ¿incluye a los que también son
proveedores? ¿Y a las cuentas maestras con sub-cuentas?
El agente no va a resolver esto. No porque sea tonto, sino porque la
ambigüedad no está en la pregunta: está en la empresa. Y la empresa no la ha
resuelto todavía, porque hasta ahora cada sistema operaba en su silo y nadie
necesitaba un significado común.
El punto que conviene fijar: el problema no es de integración técnica.
Conectar los cuatro sistemas, mover los datos y normalizar los formatos es
trabajo de ingeniería, y se hace. Lo que no se hace con ingeniería es
decidir qué significa cada cosa, y esa decisión es semántica, y es de
negocio, y es la que los agentes necesitan antes de poder hacer cualquier
cosa.
El concepto
La semántica es la disciplina del significado. En el contexto
empresarial, se ocupa de:
- Significado. Qué representa cada término en cada contexto.
- Vocabularios y terminología. Los nombres que la organización usa y sus
equivalencias. - Conceptos. Las cosas que la organización distingue (un «cliente» no es
lo mismo que un «proveedor», aunque ambos sean «parties»). - Taxonomías. Jerarquías de conceptos: un «producto» puede ser
«componente», que puede ser «refaccionario». Una taxonomía organiza
conceptos en árboles. - Semántica común. El conjunto de acuerdos sobre qué significan los
conceptos y cómo se relacionan, compartido por todos los sistemas y, cada
vez más, por los agentes. - Integración semántica. El proceso de lograr que varios sistemas
expresen los mismos hechos con significados compatibles.
La integración semántica no es mapear campos. Mapear campos (customer.id →) es un síntoma tratado: resuelve la coincidencia de nombres en
account.id
un caso concreto. La integración semántica es decidir qué conceptos existen
en la empresa, qué significa cada uno y cómo se corresponden entre
sistemas, de modo que cualquier sistema nuevo —incluido cualquier agente—
puede incorporarse sin reinventar la interpretación.
Una analogía útil: un data lake sin semántica común es como un hospital donde
cada departamento escribe las historias clínicas con su propia nomenclatura.
Puedes juntar todas las carpetas en un armario (integración técnica), pero si
«PTA» significa una cosa en cardiología y otra en cirugía, nadie —humano ni
máquina— puede leer el conjunto.
Arquitectura
En el diagrama de la serie, la semántica es la primera capa por encima del
dato:
KNOWLEDGE
↑
SEMANTICS ← hoy: significado, vocabularios, taxonomías
↑
DATA
↑
ENTERPRISE SYSTEMS
La semántica es la frontera entre «datos que existen» y «datos que
significan algo». Sin ella, la capa de conocimiento no puede construirse,
porque el conocimiento está hecho de conceptos y relaciones, y los conceptos
necesitan significado.
Hay una gradación práctica que conviene reconocer, porque las empresas no
llegan de golpe a una semántica perfecta:
- Glosario. Un documento con los términos clave y sus definiciones.
Útil, pero no ejecutable: un LLM puede leerlo, pero no razonar sobre él
de forma fiable. - Vocabulario controlado / taxonomía. Lista de términos aceptados con
jerarquías. Mejor: permite mapeos consistentes. - Modelo semántico (ontología ligera). Conceptos, relaciones y
restricciones expresados de forma que un sistema pueda verificarlos.
Es donde la semántica deja de ser documentación y pasa a ser
infraestructura.
El nivel 3 es al que vamos a llegar en dos días (ontologías). Por ahora, la
idea es que la semántica es un espectro: no es un todo-o-nada, y las
empresas avanzan por él por grados, empezando por los conceptos que sus
agentes necesitan primero.
Caso de uso
Un retailer con cuatro sistemas (el de la tabla). Descomponemos:
- Problema. El director comercial pregunta a su asistente de IA
«¿Cuál es la situación de nuestro mayor cliente?» y recibe tres respuestas
distintas en tres días, según qué sistema el agente consultó primero.
Nadie se fía ya del asistente. - Decisión. El director necesita una cifra única de «mayor cliente»
para preparar la junta. - Conocimiento necesario. Qué se considera «cliente» (¿incluye
distribuidores? ¿clientes online?); cómo se mide «mayor» (ingresos,
margen, ticket medio); cómo se consolidan las cuentas maestras y
sub-cuentas. - Datos.
customer,account,client,partyen cuatro sistemas,
con IDs distintos, duplicados y cuentas maestras. - Relaciones. Cuenta maestra → sub-cuentas; cliente → pedidos; pedido
→ líneas; cliente → también proveedor (en algunos casos). - Contexto. La pregunta es para la junta (necesita una cifra
consolidada), no para la operación diaria (donde bastaría el dato del
ERP). - Memoria. La última vez que se hizo esta consolidación fue a mano, por
un analista, y tardó dos semanas. El método está en un Excel. - Razonamiento. Aplicar la definición de «cliente» y de «mayor»,
consolidar sub-cuentas, excluir o incluir distribuidores según la regla. - Acción. Devolver la cifra con la definición aplicada, para que el
director pueda defenderla. - Infraestructura. Para que el agente dé siempre la misma respuesta
correcta, necesita una semántica común: qué es un cliente, cómo se
consolidan las cuentas, y una regla explícita de «mayor». Sin eso, cada
consulta es una ruleta de sistemas.
Lo que resuelve el retailer no es un problema de más datos: tiene de sobra.
Es un problema de significado: la palabra «cliente» tiene que significar lo
mismo para el director, para el analista y para el agente.
Trade-offs
- Coste. Definir semántica común requiere involucrar a los dueños de
negocio de cada sistema, no solo al equipo de datos. Es caro en tiempo de
gente que no está disponible. - Complejidad. Los casos borde (¿es un distribuidor un cliente?) no se
resuelven con una definición: requieren decisiones explícitas que la
organización pospone porque no le obligan a elegirlas. - Mantenimiento. La semántica deriva. El CRM se renombra, el ERP migra,
aparece un nuevo concepto (¿»socio»?). El vocabulario común tiene que
actualizarse o se estropea. - Adopción. Si el equipo comercial sigue usando «customer» y el de
finanzas «account», la semántica común es un mapa que nadie usa. Necesita
que los agentes y los dashboards la consuman de verdad. - Limitación honesta: la semántica común no elimina la ambigüedad del
mundo real; la explica. A veces «mayor cliente» depende realmente del
contexto, y la infraestructura lo que hace es dejar al usuario elegir la
definición, no inventar una respuesta única.
Implicación para la empresa
Para el CDO, la semántica es el primer activo de la infraestructura
cognitiva y el más subestimado: no es un proyecto de datos, es un proyecto
de acuerdos. Y los acuerdos requieren un dueño.
Para el equipo de IA, la lección es operativa: antes de entrenar o afinar
un agente sobre estos sistemas, hay que sentar con los dueños de negocio la
lista de conceptos que el agente va a manipular y su significado acordado.
Esa reunión, incómoda y aburrida, es la que separa un agente que da
respuestas consistentes de uno que da tres respuestas distintas.
Para la alta dirección, el mensaje es el mismo de ayer, afinado: el gap entre
«tenemos los datos» y «nuestros agentes entienden la empresa» empieza en el
significado, y el significado es una decisión de negocio, no una
configuración técnica.
Conclusión
La semántica es la primera capa de la infraestructura cognitiva: convierte
datos en cosas que significan algo. Un glosario es el mínimo viable; un
modelo semántico formal es el destino. Y entre los dos, la pregunta que
vamos a responder mañana: ¿cómo pasamos de un documento con definiciones a
una representación que una máquina pueda verificar?
Siguiente artículo
Mañana: Qué aporta una ontología a la inteligencia artificial empresarial. Veremos por qué una taxonomía no basta, qué es realmente una
ontología, y cómo una ontología es la diferencia entre un glosario que un
humano lee y una representación que un agente razona.
Fuentes
- Definición de trabajo de la ICE: ver serie, Día 1.
- La distinción entre integración técnica e integración semántica es
estándar en la literatura de data integration y semantic web (W3C); se
presenta aquí en términos operativos.
