Conectar un LLM a tus documentos y a tus APIs no es construir inteligencia empresarial.
Es el primer paso —y el más insuficiente.
Introducción
Una empresa de servicios industriales desplegó, en 2025, lo que su dirección
consideraba un agente de procurement: un LLM conectado al ERP, al CRM, al
repositorio de contratos y a la bandeja de correo de compras. En la demo
funcionaba bien: respondía a preguntas sobre pedidos, redactaba borradores de
solicitudes de compra y resumió en segundos tres semanas de emails con un
proveedor.
Tres meses después, el agente dejó de usarse. No fallaba de forma dramática:
no se inventaba pedidos con números de factura inventados (o casi nunca), y
nadie podía señalar un error concreto que justificara apagarlo. Fallaba de
una forma más insidiosa: no sabía cuál de los dos «contratos marco» de un
proveedor era el vigente, no distinguía si un cliente del CRM era el mismo que
una cuenta del ERP, respondía con la política de descuentos de 2024 porque
era el PDF mejor indexado, y cuando un comprador le pedía «revisa si este
pedido viola alguna restricción», devolvía un resumen plausible en lugar de una
verificación.
El director de TI lo resumió en una frase que hemos escuchado en muchas
salas: «El modelo es inteligente. El problema es que no entiende nuestra
empresa.»
Este artículo es el primero de una serie de veinte en la que vamos a
descomponer esa frase. La tesis que vamos a defender a lo largo de los
próximos días es una sola:
El principal reto de la IA empresarial no es disponer de modelos cada vez
más inteligentes. Es proporcionarles la infraestructura necesaria para
comprender una organización.
El problema
Un LLM es un procesador de lenguaje extraordinario. Dado un texto, predice lo
que razonablemente podría seguir. Con lo suficiente de tu documentación en la
ventana de contexto, parecerá que entiende tu negocio. Pero lo que hace el
modelo no es comprensión: es interpolación estadística sobre lo que le has
mostrado.
La diferencia importa porque una empresa no es un corpus de documentos. Una
empresa es:
- un conjunto de datos repartidos entre ERP, CRM, bases de datos, APIs,
documentos, emails, tickets y sistemas legacy que a veces no tienen API; - un conjunto de significados: cada campo, cada código, cada término tiene
una interpretación acordada internamente que ningún PDF documenta
por completo; - un conjunto de relaciones: quién posee qué, qué depende de qué, qué
contrato cubre qué producto, quién es responsable de qué activo; - un conjunto de acontecimientos: negociaciones, decisiones, incidencias,
cambios de proveedor, correcciones que solo existen en la memoria de la
gente o en hilos de email; - un conjunto de reglas y restricciones: políticas, permisos, requisitos
regulatorios, umbrales de riesgo; - y un conjunto de acciones que esas decisiones deben provocar en sistemas
reales, con trazabilidad y responsabilidad.
Ninguna de esas cosas vive en los documentos que le diste al modelo. Vive en
los sistemas, en las relaciones entre sistemas, en el tiempo y en las
decisiones. Conectar un LLM a una base de datos de documentos le da acceso a
una fracción bidimensional de la empresa: lo que se escribió, no lo que la
empresa es.
Y aquí está el punto que conviene subrayar: el problema no es el modelo.
Los modelos van a seguir mejorando; eso es un hecho, no una promesa. Pero
ningún modelo, por grande que sea, va a inferir de forma fiable que «Customer 49281» del CRM y «ACME LTD» del ERP son la misma entidad, ni que el contrato marco B sustituyó al A el 1 de marzo, ni que el comprador que está viendo un
pedido no tiene permiso para aprobar descuentos superiores al 15 %. Eso no es
inteligencia general: es conocimiento situado de una organización concreta. Y
el conocimiento situado tiene que construirse.
El concepto
Llevamos años usando metáforas para esta capa faltante: «semantic layer»,
«knowledge layer», «context layer». Son útiles como etiquetas de marketing,
pero no como arquitectura: describen una pieza (la semántica, el contexto)
como si fuera el todo.
En esta serie vamos a usar un término más amplio y, a la vez, más
restringido:
Infraestructura Cognitiva Empresarial (ICE): la capa de sistemas
interconectados —semántica, conocimiento, memoria, contexto, razonamiento,
acción y gobernanza— que permite a la IA (modelos y agentes) comprender,
recordar y operar sobre el conocimiento de una organización con
trazabilidad, control y responsabilidad.
Tres notas sobre esta definición de trabajo, que vamos a refinar a lo largo de
la serie y que no deberíamos tratar como definitiva:
- Es una arquitectura, no un producto. La ICE no se compra como una
caja. Se construye a partir de componentes con nombres (grafo de
conocimiento, pipelines de integración, memoria tipada, motor de contexto,
reglas de negocio, gobernanza de datos) que existen hoy, en parte, por
separado. El trabajo es diseñar cómo se integran. - Es una capa, no un destino. Se sitúa entre los sistemas empresariales
(la fuente de datos) y las aplicaciones inteligentes (agentes y
asistentes). No sustituye el ERP ni al data warehouse: los pone al
servicio de una forma nueva. - Tiene propiedades medibles. Comprensión (¿sabe qué representa cada
dato?), conexión (¿sabe quién es quién y cómo se relaciona?), recolección
(¿trae la información correcta en el momento correcto?), razonamiento
(¿divide bien lo que razona el modelo de lo que resuelve la
infraestructura?) y acción auditable (¿puedes explicar por qué decidió lo
que decidió?). Cada una de ellas tiene modos de fallo conocidos, que
vamos a ir viendo.
La razón para nombrar esta capa es práctica: cuando el problema tiene
nombre, el presupuesto, el equipo y el diseño arquitectónico tienen también
nombre. «Conectemos el LLM a los documentos» no sobrevive a la primera
reunión de arquitectura. «Construyamos la capa de conocimiento y contexto
sobre la que van a operar los agentes» sí.
Arquitectura
En su forma más esquemática, la ICE se organiza en capas. El lector
construirá este diagrama a lo largo de la serie; hoy solo hay que ver su
silueta:
APLICACIONES / USUARIOS
↓
AGENTES
↓
REASONING
↓
┌────────────┴────────────┐
↓ ↓
CONTEXT MEMORY
↓ ↓
└──────────┬──────────────┘
↓
KNOWLEDGE (grafo + RAG + búsqueda semántica)
↓
┌──────────┴──────────┐
↓ ↓
ONTOLOGY ENTITY RESOLUTION
↓ ↓
└──────────┬──────────┘
↓
SEMANTICS
↓
DATA
↓
ENTERPRISE SYSTEMS
Transversal a todo el stack —permisos, provenance, auditoría, supervisión
humana— va la gobernanza. Y en la capa de agentes, la acción:
herramientas, workflows y APIs que convierten decisiones en operaciones.
Hoy solo importa una cosa: el modelo (el LLM) no está en este diagrama como
capa. Está dentro del agente, como motor de razonamiento. El resto del
diagrama es lo que el modelo necesita para no adivinar.
Caso de uso
Volvamos al agente de procurement. Descompongamos su fracaso con el orden
que usaremos en toda la serie: empezando por el problema de negocio, no por
la tecnología.
- Problema. Los compradores pierden tiempo localizando información
dispersa (contratos, precios vigentes, historial del proveedor) y
aprobaciones inconsistentes generan descuentos fuera de política. - Decisión que el agente debe apoyar: validar un pedido propuesto
contra el contrato marco vigente y las políticas de compra, y proponer la
aprobación. - Conocimiento necesario: qué es un contrato marco y cuál está vigente;
qué es una restricción de compra; quién puede aprobar qué importe; qué
proveedor es el que aparece en el pedido. - Datos: registros del ERP (pedidos, proveedores, cuentas), contratos en
PDF, emails de negociación, política de descuentos, catálogos de
productos. - Relaciones: pedido → referencia a → contrato; contrato → cubre →
productos; producto → depende de → componentes; proveedor → provee →
componente. El «Customer #49281» del CRM y «ACME LTD» del ERP → misma
entidad. - Contexto: quién hace la pregunta (y qué permisos tiene), qué fecha es
(qué contrato está vigente ahora), en qué etapa del proceso está el
pedido, qué nivel de riesgo conlleva la decisión. - Memoria: las conversaciones previas con ese proveedor, la última
revisión del contrato, la incidencia de entrega fallida del trimestre
pasado, la decisión que tomó el director en un caso similar. - Razonamiento: aplicar la restricción «descuento máximo 15 % fuera de
promo» al pedido concreto; comprobar que el precio está dentro del rango
contractual; cruzar la fecha del pedido con la vigencia del contrato. - Acción: generar la solicitud de aprobación en el ERP con la
justificación adjunta; escalar al comprador si el descuento supera el umbral. - Infraestructura: todo lo anterior —identidad de entidades, grafo de
relaciones, memoria, contexto, reglas, herramientas de acción,
auditoría— es lo que el agente necesitaba. El modelo solo puso la
última pieza.
La lección no es «usad un grafo de conocimiento». La lección es que el
fracaso no estaba en la capa de lenguaje: estaba en que ninguna de las capas
5 a 10 existía para el agente.
Trade-offs
Construir esta capa tiene costes que conviene reconocer desde el primer día:
- Coste. Una capa de conocimiento bien hecha cuesta más que conectar un
RAG a un vector store. Se paga con arquitectura, pipelines y gobernanza. - Complejidad. Cada componente (grafo, memoria, contexto, reglas) es un
subsistema con su propia operación. No es un proyecto de tres semanas. - Latencia. Recuperar, contextualizar y verificar añade pasos al camino
de la respuesta. Hay que diseñar qué se resuelve en caliente y qué se
precalcula. - Mantenimiento. El conocimiento de una empresa cambia: contratos,
proveedores, organigramas, políticas. Lo que no se mantiene se estropea
(lo veremos en detalle más adelante en la serie). - Seguridad. Centralizar conocimiento es centralizar superficie de
ataque. Los permisos tienen que aplicarse en la capa de conocimiento, no
solo en la de aplicación. - Escalabilidad. No todas las preguntas necesitan el mismo esfuerzo. La
arquitectura debe ser selectiva: traer el grafo entero para una consulta de
«¿cuánto me cuesta esta pieza?» sería absurdo. - Limitación honesta: la ICE no convierte un proceso roto en un proceso
bueno. Si la organización no sabe qué contrato marco es el vigente porque
nadie lo ha validado nunca, la infraestructura va a hacer que esa
incertidumbre sea visible —que es mucho— pero no va a resolverla sola.
Implicación para la empresa
Para el CIO o el CTO, el cambio de mentalidad es concreto: el presupuesto de
IA no debería empezar en el modelo ni en el agente, sino en la pregunta «¿qué
capas de comprensión existen hoy en esta organización que la IA pueda usar?».
Para el CDO, la ICE es un proyecto de datos con un consumidor nuevo: el
agente exige datos con identidad, semántica y provenance a un nivel que el
reporting tradicional nunca exigió. Para operaciones, la promesa no es
«menos trabajo» a corto plazo, sino decisiones consistentes: el mismo
criterio, aplicado igual, a las tres de la tarde y a las once de la noche.
Y para el equipo de IA, el mensaje es el más importante de la serie: si su
agente falla en producción y no saben por qué, el problema probablemente no
está en el prompt.
Conclusión
Hemos puesto nombre a la capa que faltaba en el agente de procurement: una
Infraestructura Cognitiva Empresarial, compuesta de semántica, conocimiento,
memoria, contexto, razonamiento, acción y gobernanza. Lo que queda por ver es
cómo se construye, pieza a pieza. Y para eso conviene empezar desde el
suelo: desde el dato, que es donde todo empieza y donde casi todo se
desmorona.
Siguiente artículo
Si el agente de procurement necesitaba comprender la empresa, el primer
ingrediente era el más humilde: sus datos. Pero hay una distinción clásica
que casi todos los proyectos de IA confunden, y confundirla explica la mitad
de los fracasos que hemos descrito: la diferencia entre tener datos y tener
conocimiento. Mañana: De los datos al conocimiento: el verdadero reto de la IA empresarial.
Fuentes
- Russell, S. y Norvig, P. Artificial Intelligence: A Modern Approach —
distinción clásica entre representación del conocimiento y procesamiento
del lenguaje. - Definición de trabajo de la ICE: propuesta por Cirtra (2026), desarrollada
en este artículo y en la serie. No es un estándar de industria; se presenta
como marco arquitectónico.
