De los datos al conocimiento: el verdadero reto de la IA empresarial

Una empresa puede tener terabytes de datos y, aun así, no tener acceso a
casi ninguno de sus conocimientos. Para un agente de IA, eso no es un
problema menor: es el problema.

Introducción

Ayer dijimos que el agente de procurement no fracasó por el modelo, sino
porque la empresa no le había proporcionado una capa de comprensión. Para
construirla, hay que empezar por el suelo. Y en el suelo hay una distinción
que casi todos los proyectos de IA confunden porque, en el día a día, nadie
la usa: la diferencia entre dato, información y conocimiento.

No es pedantería académica. Es la diferencia entre «el sistema tiene los
datos» (casi siempre cierto) y «el agente puede actuar sobre lo que esos
datos significan» (casi siempre falso).

El problema

Imaginemos la empresa tipo donde vamos a desplegar agentes de IA. Sus datos
están en:

• el ERP: pedidos, facturas, cuentas, proveedores, stocks, órdenes de
  fabricación;
• el CRM: oportunidades, contactos, tickets de ventas, notas de
  seguimiento;
• documentos: contratos, políticas, manuales, especificaciones técnicas,
  actas de comité, informes de calidad;
• APIs: de terceros, de partners, de servicios internos;
• bases de datos temáticas que nadie ha catalogado;
• emails y tickets: donde en realidad se toman muchas de las decisiones;
• y sistemas legacy que nadie sabe cuándo va a sustituir y que
  contienen el conocimiento más antiguo y a veces más valioso.

Junto, forman un activo enorme. El CFO puede decir «tenemos todos los datos»
y tener razón en los gigabytes. Pero pregúntale a su agente de IA tres cosas:

1. «¿Cuál es la situación actual del cliente X?» — El agente encuentra
   «X» en cinco sistemas distintos, cada uno con un trozo de la historia,
   ninguno con el todo.
2. «¿Qué pasa si el proveedor Y sube el precio del componente Z?» — El
   agente no sabe qué productos dependen de Z, qué contratos lo cubren ni
   qué clientes se verían afectados.
3. «¿Cómo se decidió en el caso similar del año pasado?» — La decisión
   existe, probablemente en un email y en la cabeza de la persona que la
   tomó. No está en ningún lugar que el agente pueda leer.

Los tres fallos tienen el mismo origen: los datos existen, pero el
conocimiento no es accesible para el agente. El conocimiento no está
«ahí», distribuido por los sistemas, porque el conocimiento no es una
colección de registros: es significado, relaciones y experiencia.

El concepto

La jerarquía que usamos en esta serie es la clásica formulada por Russell
Ackoff en 1989, que sigue siendo la más útil:

DATA  →  INFORMATION  →  KNOWLEDGE

• Dato. Un símbolo o registro sin significado acordado. 49281 en una
  celda. 0x3F en un log. ACME LTD en un campo de texto. Por sí solo, no
  dice nada: es un token que espera a ser interpretado.
• Información. Datos organizados y dotados de un contexto mínimo que los
  hace legibles: «el pedido número 49281 de ACME LTD, emitido el 12 de
  marzo, por 14.300 €». La información responde a quién, qué, cuándo. Es
  lo que produce un dashboard, un extracto SQL bien escrito o un bien
  etiquetado ticket.
• Conocimiento. Información interpretada: significado, relaciones,
  reglas y experiencia que permiten decidir y actuar. «ACME LTD es el mismo
  cliente que Customer #49281, su contrato marco vigente es el B, los
  descuentos sobre el 15 % requieren aprobación del director, y la última
  vez que aceptamos una excepción fue por una incidencia de entrega
  documentada». El conocimiento responde a qué significa y qué hacer.

Tres propiedades del conocimiento que lo distinguen de los datos:

1. Requiere interpretación. El mismo registro 49281 es una cosa
   distinta según el sistema, la fecha y la persona que lo lee.
2. Vive en relaciones. Un dato aislado casi nunca basta: el conocimiento
   es, en gran parte, entre los datos.
3. Es temporal y situacional. El conocimiento válido ayer (el contrato
   marco A) puede ser falso hoy (lo sustituyó el B). Un dato no caduca; el
   conocimiento sí.

Y una cuarta, decisiva para esta serie: el conocimiento no se «tiene» ni
se «no tiene»; se hace accesible o no. La organización lo produce
continuamente (cada decisión, cada negociación, cada incidencia lo genera),
pero si no hay una representación que lo haga recuperable y verificable,
para el agente equivale a no existir.

Esto explica el patrón que vimos ayer: la empresa tenía los datos (ERP,
CRM, PDFs), y aun así el agente no sabía nada. Porque entre «los datos
existen» y «el agente puede razonar sobre ellos» hay un espacio que nadie
llena por defecto: la construcción deliberada de conocimiento.

Arquitectura

En el diagrama de la serie, hoy solo nos ocupamos del suelo:

                KNOWLEDGE        ← lo que el agente necesita
                     ↑
        ┌────────────┴────────────┐
        ↑                         ↑
    SEMANTICS                 (relaciones, reglas,
   (significado)              experiencia)
        ↑
       DATA                   ← lo que la empresa tiene hoy
        ↑
  ENTERPRISE SYSTEMS
  (ERP, CRM, docs, APIs, legacy, emails, tickets)

El salto DATA → KNOWLEDGE no es un pipeline: son dos problemas distintos
que suelen confundirse. El primero es técnico (extraer, mover,
transformar datos, que es lo que hace un data warehouse o un lakehouse). El
segundo es cognitivo (dotar a los datos de significado, identificar
entidades, expresar relaciones, fijar reglas, conservar la experiencia), y
es el que ninguna herramienta de integración de datos resuelve por sí sola.

La mayoría de las arquitecturas de datos de 2015-2025 resolvieron muy bien el
primero y casi no tocaron el segundo. La mayoría de los proyectos de IA de
2024-2026 descubrieron el segundo a base de fracasos.

Caso de uso

Un fabricante de componentes industriales, empresa general de la que no
necesitamos más detalles. Descomponemos con el orden de la serie:

1. Problema. El tiempo medio para responder a una solicitud de un
   cliente que exige una modificación técnica es de dos días: hay que
   localizar la especificación vigente, el historial del cliente, los
   materiales disponibles y el estado del pedido.
2. Decisión. Aceptar, modificar o rechazar la modificación y con qué
   impacto en plazo y coste.
3. Conocimiento necesario. Qué significa cada código de material; qué
   especificación es la vigente frente a las anteriores; qué materiales
   sustituyen a otros; qué acuerdos hay con ese cliente; qué capacidad tiene
   producción esta semana.
4. Datos. Todo está repartido: el ERP tiene materiales y pedidos; un
   gestor documental tiene especificaciones (algunas en versiones); el CRM
   tiene el historial comercial; los ingenieros tienen los acuerdos en
   emails.
5. Relaciones. Material → especificación vigente; material → sustituido
   por → material; cliente → acuerdo → condiciones; pedido → línea →
   material. Ninguna de estas relaciones existe como tal en ningún sistema:
   está implícita en los procesos y en las cabezas.
6. Contexto. La solicitud llega el día 18 de un mes con capacidad
   comprometida; el cliente es estratégico; la modificación afecta a un
   componente con certificación.
7. Memoria. El cliente pidió algo similar en 2024 y se resolvió con un
   material sustituto aceptado por calidad; la decisión está en un email de
   un ingeniero que se ha jubilado.
8. Razonamiento. Cruzar la modificación con la especificación vigente,
   comprobar la sustitución aprobada, estimar el impacto en plazo con la
   capacidad real.
9. Acción. Responder al cliente con la decisión, actualizar el pedido en
   el ERP, notificar a producción.
10. Infraestructura. Para que un agente haga esto, cada una de las capas
    5 a 9 tiene que existir como sistema: no como Excel, no como email, sino
    como conocimiento representado, recuperable y verificable.

Lo notable del caso: el fallo no fue de volumen de datos. Fue que las
capas de significado (qué significa un código de material) y de
relaciones (qué sustituye a qué) no estaban representadas. El agente tenía
información de sobra y conocimiento de sobra en la empresa: el problema
era que no estaba en ningún lugar que el sistema pudiera usar.

Trade-offs

• Coste. Hacer accesible el conocimiento cuesta más que mover los datos.
  Exige decisiones de modelo (qué entidades, qué relaciones, qué reglas) que
  son decisiones de negocio, no de ingeniería.
• Complejidad. Cada sistema fuente tiene su propia lógica. Unificar
  significado entre cinco sistemas es un proyecto, no una configuración.
• Calidad de fuente. Si el ERP tiene datos dudosos, el conocimiento
  construido sobre ellos lo hereda. La infraestructura cognitiva amplifica
  lo que hay: para bien y para mal.
• Latencia. Construir conocimiento es más lento que extraer un dato.
  Hay que decidir qué se precalcula y qué se calcula bajo demanda.
• Mantenimiento. El conocimiento caduca. Si la empresa cambia de
  política de descuentos y la capa de conocimiento no se actualiza, el
  agente empezará a aplicar la política vieja con toda la confianza de una
  respuesta verificada, que es peor que una respuesta dudosa.
• Limitación honesta: no todo lo que la empresa «sabe» es
  representable. El criterio del veterano que dice «esto huele mal» no va a
  entrar en un grafo. La infraestructura cognitiva captura la parte
  explicitable, que ya es enorme, pero no es una mente colectiva.

Implicación para la empresa

Para el CDO, el mensaje es directo: el activo que el agente de IA consume no
es el data lake. Es la capa de conocimiento por encima del data lake. Y esa
capa hoy, en la mayoría de las organizaciones, está construida a medias, con
nombres inconsistentes, sin dueño y sin actualizarse.

Para el CIO, hay una consecuencia de presupuesto: los proyectos de «datos
para IA» que se limitan a poner una API encima del ERP van a reproducir el
fracaso del agente de procurement. La inversión que distingue un proyecto
exitoso de uno que muere en piloto es la inversión en significado y
relaciones, que no aparece en ninguna RFP de integración de datos
tradicionales.

Para operaciones, la implicación es la más concreta: el conocimiento que
hoy vive en emails, en Excel y en la cabeza de la gente va a tener que
existir en algún lugar sistemático. No porque el agente lo exija, sino
porque la empresa que no lo tiene ya lo está perdiendo: cada jubilación,
cada baja, cada reorganización se lo lleva.

Conclusión

El salto de datos a conocimiento es el primer peldaño de la infraestructura
cognitiva, y es donde se ganan o pierden los proyectos de IA empresarial.
Hemos visto la jerarquía (dato → información → conocimiento) y por qué los
sistemas actuales resuelven la primera mitad y descuidan la segunda.

Pero hay un primer problema que hay que resolver antes de poder construir
cualquier capa de conocimiento: los sistemas no se entienden entre sí. No
solo porque tengan formatos distintos, sino porque no hablan el mismo
idioma.

Siguiente artículo

Mañana: Los datos no hablan el mismo idioma: el problema de la semántica empresarial. Veremos por qué «customer», «account», «client» y «party»
pueden ser cuatro nombres para tres cosas distintas, y por qué el problema
no es de integración técnica. Es de comprensión.

Fuentes

• Ackoff, R. (1989). «From Data to Wisdom». Proceedings of the 14th Annual
  Computer Software Applications Conference. — La jerarquía
  data → information → knowledge (→ wisdom).
• Definición de trabajo de la ICE: ver serie, Día 1.