Cómo construir una capa de conocimiento para una empresa

Diez días hemos desmontado lo que un agente necesita. Mañana empieza a
construirse. Y la primera pieza es la que lo sostiene todo: la capa de
conocimiento. No es un repositorio. Es la integración deliberada de datos,
semántica, ontología, entidades, relaciones y conocimiento, con un dueño,
métricas y un proceso de mantenimiento.

Introducción

Hemos terminado la primera pregunta de la serie —¿qué necesita un agente?— y
la respuesta fue larga: datos con significado, entidades resueltas,
relaciones, conocimiento recuperable, memoria tipada y contexto situado.

Ahora empieza la segunda pregunta, y con ella cambia el registro de la
serie: ¿cómo se construye, pieza a pieza, la infraestructura que se lo
proporciona?

Y la primera pieza es la más grande: la capa de conocimiento. Todo lo
que hemos visto hasta ahora (semántica, ontología, entity resolution,
relaciones, knowledge graph, RAG) son piezas de esta capa. Hoy las
asentamos juntas por primera vez, como una arquitectura con nombre, y no
como una colección de proyectos sueltos.

El problema

Una empresa de manufactura ha hecho, en tres años, «todo lo que se dice que
hay que hacer»: un data lake, un data mart, un glosario de datos, un RAG
sobre la documentación técnica, y un par de intentos de knowledge graph que
no cuajaron. Tiene, en principio, todas las piezas. Y sin embargo, cuando
quiere desplegar un agente para el área de ingeniería y calidad, descubre
que las piezas no se tocan:

• El RAG conoce los manuales, pero no sabe qué manual aplica a qué
  producto, porque esa relación está en otra base de datos.
• El data mart tiene los datos de producción, pero con nombres de campo que
  no coinciden con el glosario.
• El «knowledge graph» que se hizo en 2024 modelaba la organización, no los
  productos, y nadie lo ha tocado desde entonces.
• El glosario es un Excel de 2022 que nadie ha actualizado.

El problema no es la falta de piezas: es que no hay una capa de
conocimiento que las integre con una semántica común, un modelo de dominio y
un proceso de mantenimiento. Hay cinco proyectos de datos que cada uno
funciona a medias y que juntos no funcionan.

El concepto

La capa de conocimiento (knowledge architecture) es la arquitectura que
integra, sobre los sistemas de datos existentes, las piezas que un agente
necesita para comprender el dominio. Se apoya en lo que hemos definido en la
primera mitad de la serie:

CAPA DE CONOCIMIENTO
  = DATOS (fuente)
  + SEMÁNTICA (significado común)
  + ONTOLOGÍA (modelo del dominio, restricciones)
  + ENTIDADES (entity resolution, identidad canónica)
  + RELACIONES / KNOWLEDGE GRAPH (hechos y conexiones)
  + CONOCIMIENTO EN PROSA (RAG: manuales, políticas, informes)

Pero integradas no como cinco proyectos, sino como una capa con:

1. Una fuente de verdad por concepto. Cada concepto (un producto, un
   cliente, un contrato) tiene una fuente canónica declarada. No cinco
   versiones que el agente tiene que «elegir».
2. Una ontología de dominio que las une. La ontología (día 4) define los
   tipos de entidad y relación; las fuentes de verdad los pueblan.
3. Entity resolution entre fuentes. La identidad canónica (día 5)
   conecta los registros de distintas fuentes en la misma entidad.
4. Un grafo que materializa las relaciones. El KG (día 7) es donde las
   relaciones concretas se vuelven consultables.
5. Un RAG para lo que no es estructurable. Los manuales, políticas e
   informes que no entran en el grafo se indexan para el RAG (día 8), con
   metadatos que los conectan al grafo (a qué producto aplican, qué versión,
   qué vigencia).
6. Un dueño y métricas. Alguien es responsable de que la capa sea
   correcta y esté actualizada, y hay métricas que lo miden (cobertura,
   frescura, tasa de contradicciones).

La capa de conocimiento no sustituye al data lake ni al data mart: se apoya
sobre ellos. La diferencia es de propósito: el data lake existe para
analizar; la capa de conocimiento existe para que un sistema (un agente)
pueda comprender el dominio y actuar sobre él. Esa diferencia de propósito
es la que explica por qué los proyectos de datos tradicionales no la
construyen por defecto.

Arquitectura

En el diagrama de la serie, la capa de conocimiento es el bloque central de
la infraestructura cognitiva:

              AGENTES
                 ↓
          REASONING
                 ↓
     ┌───────────┴───────────┐
     ↓                       ↓
  CONTEXT                 MEMORY
     └───────────┬───────────┘
                 ↓
        KNOWLEDGE  ← HOY: la capa de conocimiento
        (grafo + RAG + semántica
         + ontología + entidades)
                 ↓
        DATA / ENTERPRISE SYSTEMS

La capa de conocimiento es la frontera entre «los datos que la empresa
tiene» y «lo que el agente puede comprender». Es la pieza más grande del
diagrama, y la que más tarda en construirse, porque es la que requiere
decisiones de negocio (qué conceptos, qué fuentes canónicas, qué reglas) y
no solo de ingeniería.

Caso de uso

La empresa de manufactura, con su agente de ingeniería y calidad.
Descomponemos:

1. Problema. Un lote de componentes entra en control de calidad y el
   equipo necesita saber, rápido: qué especificación aplica, qué
   desviaciones se han aceptado históricamente para ese tipo, y si hay
   alguna no conformidad abierta que afecte al lote. Hoy lleva horas
   consultar cinco sistemas.
2. Decisión. Aceptar o rechazar el lote, y con qué acciones correctivas.
3. Conocimiento necesario. La especificación vigente del componente; las
   tolerancias aceptables; el historial de desviaciones aceptadas para ese
   tipo; las no conformidades abiertas que lo afectan.
4. Datos. Especificaciones (gdoc), datos de producción (ERP/MES),
   historial de calidad (sistema de calidad), no conformidades (sistema de
   gestión).
5. Relaciones. Componente → especificación vigente; especificación →
   tolerancias; componente → desviaciones históricas; no conformidad →
   afecta a → lote; lote → líneas de producción.
6. Contexto. El lote es para un cliente con cláusula de calidad estricta;
   hay una revisión de certificación en curso; el técnico de calidad está de
   baja (decide un supliente con menos contexto).
7. Memoria. Un lote similar el trimestre pasado se aceptó con una
   desviación específica y la justificación; la no conformidad NC-2026-041
   afecta a este tipo de componente y está abierta.
8. Razonamiento. Aplicar la especificación vigente al lote; cruzar con
   las desviaciones aceptadas históricamente (¿esta desviación ya se
   aceptó?); cruzar con la NC-2026-041 abierta (¿afecta?); aplicar la
   cláusula del cliente.
9. Acción. Rechazar el lote por la no conformidad abierta, con la
   justificación y las acciones correctivas propuestas; notificar al
   proveedor.
10. Infraestructura. La capa de conocimiento integrando especificaciones
    • producción + calidad + no conformidades, con la ontología del dominio
      de calidad, la entity resolution entre sistemas y el grafo de
      relaciones, más el RAG para las especificaciones en prosa. Sin la capa
      integrada, cada consulta es un viaje por cinco sistemas.

Trade-offs

• Coste. Una capa de conocimiento bien hecha es un proyecto de meses,
  con expertos de negocio implicados. No es un sprint.
• Complejidad. La integración de cinco fuentes con una semántica común
  es el 80 % del trabajo; el grafo y el RAG son el 20 % visible. Subestimar
  la integración es el error más común.
• Secuenciación. No se construye la capa entera de golpe. Se empieza por
  el dominio que el primer agente necesita (en el caso, calidad), se
  integra bien, y se expande. La tentación de «modelarlo todo» es la que
  mata los proyectos de knowledge graph.
• Mantenimiento. La capa tiene que actualizarse: nuevas especificaciones,
  cambios de tolerancia, cierres de no conformidades. Sin un proceso de
  mantenimiento y un dueño, se estropea en un año y da confianza falsa.
• Calidad de fuente. La capa amplifica la calidad de las fuentes: si el
  ERP tiene datos dudosos, la capa los hereda. La gobernanza de fuente es
  parte del diseño (día 18).
• Limitación honesta: la capa de conocimiento representa el conocimiento
  explicitable y estructurable. La experiencia del inspector que «sabe»
  que una desviación es aceptable porque «se ve bien» no entra en la capa
  hasta que se explicita. La capa mejora lo explícito; no lo reemplaza.

Implicación para la empresa

Para el CDO, la capa de conocimiento es el proyecto que ordena los cinco
proyectos de datos sueltos en una arquitectura con propósito. Y es un
proyecto con dueño: sin un responsable de la capa, es cinco responsables que
no son responsables de la integración.

Para el equipo de IA, la lección es de secuencia: no se empieza por el
agente ni por el grafo. Se empieza por la capa de conocimiento del primer
dominio, bien integrada. El agente viene después, y viene bien, porque se
apoya en algo que es correcto.

Para la alta dirección, el mensaje es de inversión: la capa de conocimiento
es la inversión que todos los agentes posteriores van a compartir. Cada
agente que se construye sobre ella cuesta menos y es más fiable. Es la
diferencia entre construir un agente cada vez desde cero y construir una
plataforma que los agentes usan.

Conclusión

La capa de conocimiento es la integración deliberada de datos, semántica,
ontología, entidades, relaciones y conocimiento en prosa, con fuentes de
verdad declaradas, un modelo de dominio, un grafo, un RAG y un dueño. Es la
pieza más grande de la infraestructura cognitiva y la que más tarda, porque
requiere decisiones de negocio, no solo de ingeniería.

Hoy la capa de conocimiento está construida. Pero un agente no solo
necesita el conocimiento estable de la empresa: necesita recordar lo que
pasa en la operación, a diario. Y eso es la memoria, que hoy vimos como
concepto y que mañana vamos a diseñar como arquitectura.

Siguiente artículo

Mañana: Diseñando la memoria de una organización para sus agentes de IA. Veremos cómo se combinan memoria, knowledge base, RAG, knowledge graph
y eventos en una arquitectura de memoria que el agente usa a diario, y qué
significa retener, consolidar y hacer expirar el conocimiento.

Fuentes

• Definición de trabajo de la ICE: ver serie, Día 1.
• La arquitectura de conocimiento como integración de ontología, grafo y
  RAG es el enfoque descrito en la literatura de agentic knowledge systems
  y en el contenido de Cirtra sobre Agentic Knowledge Systems.