Las empresas llevan décadas generando y acumulando datos en sistemas como ERP, CRM, hojas de cálculo de Excel, data warehouses, registros de aplicaciones, correos electrónicos, documentos y archivos de todo tipo. Se trata de un patrimonio de información enorme, distribuido, más o menos accesible y, en ocasiones, redundante. Sin embargo, si preguntáramos a un analista, a un directivo o a un nuevo empleado qué significa exactamente el margen operativo para la empresa y cómo se calcula, probablemente obtendríamos respuestas imprecisas o incluso contradictorias. ¿Por qué ocurre esto y cómo puede resolverse?

Puntos clave

• Sin una arquitectura del conocimiento compartida, los agentes de IA no pueden interpretar correctamente el significado de los datos empresariales. Es necesario un nivel semántico explícito y gobernado, capaz de transformar información fragmentada en conocimiento fiable.
• La Knowledge Architecture se construye mediante un proceso evolutivo compuesto por distintos niveles progresivos: desde el Modelo Conceptual de Datos (Conceptual Data Model) hasta el Knowledge Graph y la Capa Semántica (Semantic Layer). Cada fase genera activos de información estructurados que alimentan la siguiente.
• La gobernanza de la Knowledge Architecture es una necesidad arquitectónica, ya que los agentes de IA basan sus decisiones y acciones en lo que comprenden a través de la capa semántica. Definiciones obsoletas, relaciones erróneas o controles insuficientes pueden propagar errores a lo largo de workflows y procesos interconectados.

Un problema generalizado: la falta de un lenguaje común y de una comprensión unívoca de los datos empresariales

El problema que acabamos de describir es bien conocido, pero con la llegada de los agentes de IA —sistemas autónomos que leen, consultan, razonan sobre los datos empresariales y, en algunos casos, toman decisiones y actúan— se ha convertido en un aspecto crítico. El motivo es que un agente de IA no puede deducir fácilmente, a partir del contexto, qué entiende la empresa por cliente activo, producto terminado o ingresos netos. Necesita un contrato semántico explícito, formal y navegable. 

Necesita una arquitectura del conocimiento.

Knowledge Architecture: cuatro conceptos, una única cadena

Antes de profundizar en la construcción de esta Knowledge Architecture, es necesario comprender bien cuatro expresiones diferentes que a menudo se utilizan de forma incorrecta o indistintamente: Conceptual Data Model, Ontología, Knowledge Graph y Semantic Layer. No son sinónimos, sino capas diferentes de una misma arquitectura, cada una con un papel muy preciso.

Conceptual Data Model, la representación del mundo empresarial (Capa 1)

El Conceptual Data Model (CDM) es el punto de partida de la Knowledge Architecture. Es una representación conceptual del contexto de negocio, independiente de cualquier tecnología de creación, adquisición o gestión de datos. Sirve para representar las entidades más relevantes para el negocio (por ejemplo: cliente, producto, proveedor, pedido de venta, factura, asiento contable, empleado, etc.) y cómo se relacionan entre sí (por ejemplo: un cliente realiza pedidos, un pedido contiene productos). En algunos casos, si el CDM no es demasiado complejo o cuando se considera útil, puede incluir para cada entidad los principales atributos que la caracterizan, o enriquecerse con información como, por ejemplo, la definición de la entidad, el owner de la definición, el dominio de negocio, etc.

En el CDM no se habla de sistemas de información, tablas, bases de datos, API, etc.: el CDM sirve para representar el negocio tal y como lo concibe la empresa. Está escrito en lenguaje natural, suele representarse mediante diagramas ER o UML y debe ser comprensible tanto para el CTO como para el responsable comercial o un empleado de contabilidad. Su función dentro de la arquitectura del conocimiento es fundamental: proporciona la "materia prima" conceptual a partir de la cual se construirán las estructuras formales de los niveles superiores.

Ontología: del modelo conceptual al conocimiento estructurado (Capa 2) 

La capa ontológica es el nivel en el que el modelo conceptual (CDM) se traduce a una estructura de datos procesable por el sistema. Si una descripción conceptual del CDM establece que "un cliente puede ser una persona física o una persona jurídica", la ontología lo formaliza como una jerarquía de clases, con axiomas lógicos precisos: Persona Física ⊆ Cliente, Persona Jurídica ⊆ Cliente; estos dos subconjuntos son disjuntos.

El lenguaje estándar para definir ontologías es OWL (Web Ontology Language), evolución del lenguaje RDFS (Resource Description Framework Schema). Estos formalismos no son detalles técnicos: son necesarios para habilitar la automatización del razonamiento. Por ejemplo, un motor de inferencia puede deducir, a partir de los axiomas de la ontología, que un sujeto nunca clasificado explícitamente como cliente, pero que ha realizado un pedido, es implícitamente un cliente. Es un salto enorme respecto a un simple esquema de base de datos, que solo conoce aquello que se ha registrado de forma explícita.

En el contexto de la Knowledge Architecture, la ontología formaliza y enriquece el marco conceptual del CDM: no solo se definen las entidades y sus relaciones en un contexto de negocio específico, sino que también se establecen las reglas y restricciones que gobiernan cómo se conectan los datos entre sí.

El Knowledge Graph: el modelo cobra vida con los datos reales (Capa 3)

Un Knowledge Graph es un modelo de datos semántico que organiza la información en entidades interconectadas (nodos) y sus relaciones (aristas), creando una red estructurada comprensible tanto para las personas como para las máquinas. Mientras que las bases de datos tradicionales almacenan los datos en tablas "rígidas" (los atributos de cada registro existen siempre, aunque no estén informados), el Knowledge Graph captura únicamente las conexiones reales entre informaciones diferentes.

Los Knowledge Graphs se componen de cuatro elementos fundamentales:

• nodos (entidades), que representan los "objetos" del dominio (clientes, productos, transacciones, sedes, etc.);
• aristas (relaciones), que definen cómo se conectan las entidades entre sí;
• etiquetas y propiedades, que aportan riqueza semántica tanto a los nodos como a las relaciones;
• ontologías, que proporcionan el marco conceptual de referencia.

La estructura fundamental de un Knowledge Graph es la "triple semántica": Sujeto, Predicado y Objeto (por ejemplo: Producto_00347 – tieneProveedor – Empresa_Acme). En un Knowledge Graph, cada dato se convierte en una relación explícita, navegable de forma multidimensional e interoperable mediante lenguajes como SPARQL. Los Knowledge Graphs se implementan sobre Graph Databases, como Neo4j, Stardog, TigerGraph o FalkorDB. A diferencia de las implementaciones basadas en bases de datos relacionales, no presuponen un esquema fijo y rígido: siempre es posible añadir nuevas relaciones sin necesidad de reconstruir tablas.

Con la evolución de la IA generativa y la aparición de los llamados "agentes", los Knowledge Graphs han recuperado protagonismo porque constituyen el medio a través del cual los agentes de IA pueden razonar sobre los datos empresariales: cada nodo es una instancia de una entidad, cada arista representa una relación semánticamente tipificada y cada recorrido es una secuencia de pasos lógicos que el agente puede seguir y rastrear.

Knowledge Graph vs. Graph Database: una distinción importante  

Es habitual confundir estos dos conceptos, pero es importante entender la diferencia:

• El Knowledge Graph es un modelo semántico que captura el significado del negocio y las relaciones, definiendo qué representan los datos y cómo se relacionan los distintos conceptos entre sí: el "qué" y el "por qué" de la arquitectura de la información.
• La Graph Database, por el contrario, es la tecnología de infraestructura que almacena y consulta datos estructurados en forma de grafo: el "cómo" y el "dónde" de la gestión de los datos.

Las implementaciones empresariales de mayor éxito utilizan ambos en combinación: el Knowledge Graph define la capa semántica comprensible para los usuarios de negocio, mientras que la Graph Database proporciona la tecnología necesaria para permitir consultas rápidas (queries), analytics en tiempo real y aplicaciones de IA.

La Semantic Layer: la interfaz compartida (Capa 4)

La Semantic Layer es la capa arquitectónica más cercana al data consumer, ya sean analistas, cuadros de mando de BI o agentes de IA. No es una base de datos ni una ontología: es un contrato semántico que expone métricas calculadas, dimensiones de análisis, jerarquías y un glosario de negocio unificado. Es una capa que amplía lo que, en algunos contextos y por parte de algunos proveedores, se ha denominado metrics layer.

La Semantic Layer resuelve una limitación estructural que el Knowledge Graph por sí solo no puede superar. De hecho, un Knowledge Graph destaca por modelar relaciones y significado contextual: puede representar cómo un cliente está conectado con un producto, ese producto con un proveedor y ese proveedor con eventos de riesgo posteriores. Sin embargo, no permite definir KPI compartidos dentro de la organización, versionables y calculados con las mismas reglas de agregación entre distintos departamentos. Un Knowledge Graph no puede garantizar que el mismo cálculo sea aplicado por dos equipos diferentes que, en una misma reunión, deban presentar los ingresos. Ya sabemos por experiencia que el problema rara vez reside en los datos: es un problema semántico.

Para los agentes de IA, esta capa es el punto de entrada preferente: cuando los modelos LLM consultan los datos a través de una Semantic Layer, su precisión aumenta de forma significativa. El contexto de negocio descrito en la Semantic Layer y las relaciones estructuradas navegables en el grafo previenen las alucinaciones y las interpretaciones erróneas de la IA que ya conocemos.

Del Conceptual Data Model al Knowledge Graph: el recorrido práctico

La Knowledge Architecture no surge de un salto repentino: es una cadena de transformaciones incrementales que parte del Conceptual Data Model y llega hasta el Knowledge Graph y la Semantic Layer, con entradas (inputs) y salidas (outputs) bien definidas en cada etapa.

Conceptualización (Fase 1)

Se comienza con los stakeholders: entrevistas, talleres, análisis de la documentación existente. El objetivo es producir un Conceptual Data Model compartido que capture las entidades del dominio y las relaciones fundamentales. Atención: el CDM debe surgir del negocio, no del departamento de TI. El mayor riesgo es construir un modelo que refleje la estructura de los sistemas existentes en lugar de la lógica y el conocimiento del dominio de negocio.

Formalización ontológica (Fase 2)

Mapeo e ingesta (Fase 3)

Los datos brutos de los sistemas de origen, incluidas las tablas del ERP, las entidades del CRM y los archivos estructurados, deben mapearse sobre las clases y propiedades de la ontología mediante reglas de transformación (a menudo expresadas en R2RML o en lenguajes propios de las herramientas ETL). El resultado es una primera carga del Knowledge Graph con las instancias reales existentes en los sistemas de información de la organización.

Enriquecimiento y validación (Fase 4)

El Knowledge Graph nunca está completo en la primera iteración. Es necesario enriquecerlo con relaciones derivadas (inferidas por la ontología), con datos procedentes de fuentes externas y con anotaciones generadas por modelos lingüísticos que leen documentos no estructurados y comprenden información adicional. La validación se realiza con SHACL (Shapes Constraint Language): se definen las formas esperadas de los nodos y se verifican las posibles violaciones de integridad detectadas.

Exposición mediante la Semantic Layer (Fase 5)

Knowledge Architecture: por qué ahora más que nunca

La pregunta es legítima: ¿por qué esta arquitectura, existente desde hace décadas en el mundo de la web semántica, se ha vuelto tan urgente precisamente en el contexto de los datos gestionados por las organizaciones?

La respuesta está en la llegada de los agentes de IA y en la oportunidad de adoptarlos en use cases empresariales para automatizar tareas complejas, aumentar la productividad y reducir los costes operativos. Un Large Language Model, sin un conocimiento estructurado del contexto de negocio, puede consultar datos empresariales y funcionar como un excelente redactor, pero resulta ser un pésimo analista: confabula, interpreta de forma inconsistente y comete errores de interpretación "triviales" para un ser humano. Por el contrario, un agente de IA con acceso a un Knowledge Graph bien construido, con una Semantic Layer que expone las definiciones operativas y las métricas, es capaz de responder a preguntas complejas de forma fiable, trazable y coherente con la realidad empresarial.

El Knowledge Graph no es solo una fuente de datos para el agente: es su modelo del mundo empresarial. Es lo que le permite navegar entre entidades relacionadas, seguir cadenas causales y respetar las reglas de negocio sin necesidad de reescribirlas en cada prompt. Es esto lo que marca la diferencia entre un agente que aprende algo de forma limitada y un agente que comprende el contexto en el que debe desenvolverse.

Gobernanza de la Knowledge Architecture: un componente imprescindible

Con los agentes de IA actuando de forma autónoma sobre los datos empresariales, la gobernanza del Knowledge Graph y de la Semantic Layer deja de ser una best practice y se convierte en una necesidad arquitectónica. Un agente autónomo actúa en función de lo que comprende de la capa semántica y de lo que extrae del Knowledge Graph; por tanto, es necesaria una gobernanza capaz de garantizar la precisión de lo expuesto y una protección adecuada: un agente de IA que trabaja sobre definiciones obsoletas y un grafo con errores no solo genera resultados erróneos, sino que los propaga a lo largo del flujo de trabajo en el que opera y, potencialmente, también a otros procesos con los que interactúa.

Una gobernanza eficaz de la Semantic Layer y del Knowledge Graph requiere al menos tres elementos:

1. ownership de las definiciones, las métricas, las entidades/nodos y sus correspondientes relaciones;
2. version control: trazabilidad de los cambios a lo largo del tiempo;
3. role-based access: qué sistemas y agentes pueden acceder y a qué partes de la capa semántica y del grafo subyacente.

En un entorno tradicional de BI para reporting y dashboarding, un error suele tener un cierto nivel de contención, ya que existen analistas con sensibilidad sobre los datos extraídos y visualizados que pueden detectar el problema, aunque requiera cierto esfuerzo. Con los agentes de IA, al desaparecer este control, los errores pueden propagarse rápidamente y a una escala mucho mayor antes de que alguien los detecte.

El conocimiento como infraestructura

Construir una arquitectura del conocimiento empresarial, desde el CDM hasta la ontología, pasando por el Knowledge Graph y la Semantic Layer, no es un proyecto de TI. Es una inversión estratégica en la capacidad de hacer inteligibles los propios datos, tanto para las personas que interactúan con ellos como para los sistemas de IA que cada vez operarán más sobre ellos.

Las organizaciones que obtienen el mayor retorno de la inversión y generan el mayor valor a partir de sus datos lo consiguen ejecutando estrategias y enfoques avanzados que unifican y formalizan el conocimiento a partir de activos de información distribuidos. La ventaja competitiva no reside en la cantidad de datos disponibles, sino en el significado que se les puede atribuir de forma coherente, gobernada y accesible.

En una época en la que los agentes de IA están destinados a convertirse en operadores activos dentro de los procesos empresariales, una Knowledge Architecture ya no es una opción, sino la plataforma sobre la que construir cualquier forma de inteligencia operativa fiable.