TL;DR
Los agentes de inteligencia artificial no necesitan solamente acceder a los datos de una empresa. Necesitan saber qué significan, cómo se relacionan, qué reglas los gobiernan, qué ha ocurrido anteriormente y qué información resulta relevante en la situación concreta en la que tienen que actuar.
La Semantic Layer proporciona significado empresarial a los datos. La Ontology define las cosas que existen en un determinado dominio y las relaciones posibles entre ellas. El Knowledge Graph representa las entidades reales y sus relaciones. La Context Layer reúne y selecciona la información que un agente necesita para comprender una situación. Y el Context Graph intenta representar de manera dinámica las relaciones, decisiones, estados, excepciones y antecedentes que explican qué está ocurriendo en cada momento.
No son necesariamente cinco tecnologías que haya que instalar por separado. Son cinco formas de resolver un mismo problema desde niveles diferentes: convertir datos dispersos en contexto utilizable por una inteligencia artificial.
Antes de empezar: qué significa cada concepto y para qué sirve
Semantic Layer — Capa semántica. Es una capa situada entre los datos y quienes los utilizan que traduce estructuras técnicas —tablas, campos, métricas o relaciones— a conceptos comprensibles para el negocio. Permite establecer, por ejemplo, qué significa exactamente "cliente activo", cómo se calcula el margen o qué fecha debe utilizarse para atribuir una venta. Su principal función es conseguir que diferentes aplicaciones, informes, personas o agentes interpreten un mismo dato de la misma manera. Una Semantic Layer convierte datos técnicamente accesibles en datos empresarialmente comprensibles.
Ontology — Ontología. Es una representación formal de los conceptos que existen dentro de un determinado dominio y de las relaciones que pueden existir entre ellos. Puede definir que existen clientes, pedidos, productos, fábricas, máquinas o empleados; qué propiedades puede tener cada uno y qué relaciones son válidas entre ellos. El W3C describe las ontologías precisamente como vocabularios formalizados capaces de representar términos y sus relaciones de una forma procesable por software. Su función fundamental es proporcionar una especie de modelo conceptual compartido del mundo sobre el que trabaja un sistema.
Knowledge Graph — Grafo de conocimiento. Es una representación conectada de entidades reales, conceptos, hechos y relaciones. Mientras una ontología puede establecer que "un cliente puede realizar pedidos", un Knowledge Graph puede representar que "Cliente A realizó Pedido 328", que ese pedido contiene determinado producto, que fue suministrado desde una fábrica y que produjo posteriormente una incidencia. Su función consiste en transformar información aislada en conocimiento conectado que pueda recorrerse, consultarse y utilizarse para razonar.
Context Layer — Capa de contexto. Proporciona a un sistema de IA el conjunto de información necesaria para comprender correctamente una situación antes de responder o actuar. Puede combinar definiciones semánticas, datos, documentos, identidad del usuario, permisos, historial, memoria, políticas, estado de los procesos y señales recibidas en tiempo real. No existe todavía una definición técnica única del término, pero está emergiendo como la capa situada entre los sistemas empresariales y los agentes que determina qué debe saber un agente en cada momento.
Context Graph — Grafo de contexto. Estructura ese contexto como una red de entidades, hechos, decisiones, estados y relaciones que puede evolucionar con el tiempo. Puede representar no solamente que algo es cierto, sino desde cuándo lo es, por qué lo sabemos, qué decisión lo produjo, qué regla se aplicó, qué excepción existe o qué información sustituye a otra anterior. Es un concepto todavía emergente y las definiciones varían, pero la idea común es utilizar grafos para representar el contexto operativo que necesitan los agentes, no solamente el conocimiento relativamente estable de una organización.
La diferencia puede resumirse de una forma muy sencilla:
Semantic Layer: qué significa este dato.
Ontology: qué cosas existen y cómo pueden relacionarse.
Knowledge Graph: qué cosas concretas conocemos y cómo están relacionadas.
Context Layer: qué necesita saber el agente ahora.
Context Graph: cómo está conectado todo lo que importa en esta situación y cómo ha llegado hasta aquí.
El problema ya no son los datos, es la información semántica.
Durante décadas una parte importante de la tecnología empresarial se ha dedicado a almacenar información. Primero construimos bases de datos. Después data warehouses, data lakes, APIs, sistemas de Business Intelligence y plataformas capaces de integrar cada vez más fuentes. El problema fundamental era conseguir que la información estuviera disponible.
Con la inteligencia artificial generativa ese problema está cambiando. Un agente puede tener técnicamente acceso a miles de tablas, documentos, correos electrónicos y aplicaciones y, sin embargo, seguir sin comprender suficientemente la empresa en la que trabaja.
Porque tener acceso a la información y entenderla son dos cosas completamente diferentes.
Podemos darle a una IA una tabla llamada pedidos, otra llamada clientes y otra llamada facturacion. Pero eso no le dice necesariamente qué considera la empresa un pedido confirmado, cuándo una venta debe considerarse realizada, si las devoluciones reducen la facturación del mes original o del mes en el que se producen, qué clientes pertenecen al mismo grupo empresarial o qué excepciones comerciales existen para un determinado cliente.
Ese conocimiento suele existir, pero se encuentra repartido entre bases de datos, aplicaciones, procedimientos, documentación, personas y experiencia acumulada.
La llegada de los agentes convierte ese problema en una cuestión central. Porque un sistema que solamente responde preguntas puede permitirse cierta ambigüedad. Un sistema que empieza a tomar decisiones, ejecutar procesos o modificar sistemas necesita entender mucho mejor el mundo sobre el que está actuando.
Y ahí empiezan a aparecer todas estas capas.
La Semantic Layer: conseguir que los datos tengan significado
La primera dificultad es sorprendentemente básica: que todos llamemos de la misma manera a las mismas cosas.
Pensemos en una pregunta aparentemente sencilla:
¿Cuánto hemos vendido este mes?
Para responder correctamente necesitamos saber qué significa "vendido". ¿Pedidos recibidos? ¿Pedidos confirmados? ¿Mercancía enviada? ¿Facturas emitidas? ¿Facturas cobradas? ¿Importe antes o después de devoluciones? ¿Con impuestos o sin impuestos?
Dos departamentos pueden producir cifras diferentes y ambos estar utilizando datos técnicamente correctos.
La Semantic Layer intenta resolver precisamente este problema. Introduce una capa donde se definen métricas, dimensiones, relaciones y reglas de negocio para que cualquier herramienta que consulte la información pueda utilizar el mismo significado.
En el mundo del Business Intelligence esto permite que dos dashboards calculen de la misma manera el margen o los clientes activos. En el mundo de los agentes ocurre algo todavía más importante: permite que una inteligencia artificial no tenga que deducir por sí misma el significado empresarial de una estructura técnica.
Podríamos decir que la Semantic Layer convierte el esquema de una base de datos en un lenguaje que la empresa reconoce.
Pero sigue existiendo un problema. Saber qué significa "cliente" no significa necesariamente comprender todo lo que puede ser un cliente dentro de la empresa.
La ontología: construir el modelo del mundo
Aquí aparece la ontología.
Una ontología no describe principalmente dónde están almacenados los datos, sino qué cosas existen en nuestro mundo y qué relaciones pueden existir entre ellas.
En una empresa industrial podrían existir conceptos como cliente, proveedor, producto, componente, máquina, planta, pedido, orden de fabricación, empleado o incidencia. Una máquina puede estar situada en una planta. Una orden de fabricación puede producir un producto. Un componente puede formar parte de otro producto. Un empleado puede ser responsable de una máquina.
La ontología proporciona ese vocabulario y establece sus relaciones.
La distinción respecto a la Semantic Layer es importante. La Semantic Layer podría indicarnos que el campo customer_id representa un cliente y que la métrica revenue se calcula de determinada manera. La ontología intenta definir qué es conceptualmente un cliente y cómo encaja dentro del modelo general de la organización.
Es, en cierto sentido, una descripción computable del mundo en el que tendrá que desenvolverse la inteligencia artificial.
Esta idea puede parecer excesivamente académica hasta que empezamos a construir agentes. Entonces resulta bastante evidente: para poder razonar sobre una empresa, un agente necesita alguna representación de las cosas que existen dentro de ella.
El Knowledge Graph: pasar del modelo a la realidad
Una ontología podría establecer:
Cliente → realiza → Pedido.
El Knowledge Graph empieza cuando representamos:
Industrias López → realizó → Pedido 48372.
Y podemos continuar:
Pedido 48372 → contiene → Producto X.
Producto X → se fabrica en → Planta Zaragoza.
Pedido 48372 → originó → Incidencia 291.
Incidencia 291 → asignada a → María.
El conocimiento deja de ser una colección de registros separados y se convierte en una red.
Esto tiene una ventaja enorme para la inteligencia artificial. Las relaciones dejan de tener que reconstruirse continuamente mediante búsquedas aproximadas porque pueden estar explícitamente representadas.
Un buscador vectorial puede encontrar documentos similares a una pregunta. Un Knowledge Graph puede recorrer relaciones.
Si preguntamos quién es responsable del producto relacionado con una incidencia producida por un determinado pedido, el problema ya no consiste simplemente en localizar un texto parecido. Consiste en navegar por una cadena de relaciones.
De ahí que los Knowledge Graphs estén recuperando tanta importancia con la IA generativa. No sustituyen al RAG, a las bases vectoriales o a las bases de datos convencionales. Añaden una estructura que permite representar explícitamente cómo se relacionan las cosas.
Pero incluso eso puede no ser suficiente.
Saber lo que existe no es saber lo que está ocurriendo
Imaginemos ahora que nuestro Knowledge Graph contiene toda la información anterior y preguntamos:
¿Podemos aceptar un nuevo pedido de este cliente?
De repente conocer clientes, pedidos, productos y fábricas resulta insuficiente.
El agente podría necesitar saber que el cliente tiene temporalmente bloqueado el crédito. Que hace dos días el director comercial autorizó una excepción hasta determinado importe. Que una de las plantas está parada por mantenimiento. Que existe una negociación abierta con el cliente. Que el producto solicitado se ha reservado prioritariamente para otro proyecto. Que una regla general de la empresa tiene una excepción específica durante septiembre.
Buena parte de esta información puede no formar parte del conocimiento relativamente estable de la empresa. Es estado, historia, excepción, intención y situación.
Es contexto.
Y probablemente aquí se encuentra uno de los mayores problemas que tendremos que resolver para construir agentes empresariales realmente útiles.
La Context Layer: decidir qué necesita saber una IA
Los modelos tienen una característica fundamental: solamente pueden razonar directamente sobre aquello que se introduce en su contexto.
No importa que una empresa disponga de millones de documentos y miles de millones de registros. Si la información adecuada no llega al modelo en el momento adecuado, para el agente esa información prácticamente no existe.
Por eso la Context Layer empieza a convertirse en una pieza diferenciada de la arquitectura de IA. Gartner ya habla en 2026 de una Enterprise Context Layer como infraestructura necesaria para conectar agentes con la realidad empresarial, mientras diferentes proveedores están empezando a definir arquitecturas alrededor del mismo concepto.
Su trabajo no es simplemente recuperar información.
Su trabajo es construir el contexto adecuado.
Ante una determinada tarea podría determinar quién está realizando la petición, qué permisos posee, sobre qué entidad está trabajando, qué definiciones empresariales deben utilizarse, qué datos son relevantes, qué documentos están vigentes, qué decisiones anteriores afectan al caso, qué reglas deben aplicarse, qué acciones se realizaron anteriormente y cuál es el estado actual del proceso.
Por eso una Context Layer puede terminar incorporando piezas muy diferentes: Semantic Layer, ontologías, Knowledge Graphs, RAG, memoria de agentes, sistemas de permisos, event streams, reglas de negocio o APIs.
No tenemos necesariamente que elegir entre ellas. La Context Layer puede ser precisamente la arquitectura que las coordina.
Y entonces aparece el Context Graph
El Context Graph lleva esta idea un paso más lejos.
Si el Knowledge Graph conecta conocimiento, el Context Graph intenta conectar situaciones.
Supongamos que una regla indica que todos los pedidos superiores a 50.000 euros requieren aprobación financiera.
Un Knowledge Graph podría representar la regla y relacionarla con los tipos de pedido a los que afecta.
Pero imaginemos que hace tres semanas el director financiero autorizó que durante septiembre un determinado cliente pueda realizar pedidos de hasta 75.000 euros sin autorización adicional porque existe un acuerdo comercial específico.
Entonces ya no basta con almacenar la regla.
Necesitamos representar:
qué regla existía, qué excepción se aprobó, quién la aprobó, cuándo, a qué cliente afecta, durante cuánto tiempo, qué documento o conversación constituye la evidencia, qué decisión sustituye temporalmente a qué otra, y en qué situaciones debe aplicarse.
Eso empieza a parecer mucho más un Context Graph.
Las definiciones que están apareciendo alrededor del concepto ponen precisamente el énfasis en elementos como temporalidad, procedencia, decisiones, estado y relaciones entre información que cambia. IBM lo describe como una estructura que hace explícitas las relaciones entre las piezas que forman el contexto de un modelo; otros enfoques más recientes lo describen como un registro vivo de decisiones y contexto operativo.
Y esta distinción me parece especialmente útil:
Un Knowledge Graph intenta representar lo que la organización sabe. Un Context Graph intenta representar qué significa ese conocimiento en la situación actual.
No es una frontera absoluta. Un Knowledge Graph suficientemente sofisticado puede incorporar temporalidad, procedencia, decisiones y contexto, por lo que técnicamente ambos conceptos pueden solaparse. De hecho, algunos enfoques consideran el Context Graph una especialización del Knowledge Graph.
Pero conceptualmente la diferencia resulta muy valiosa.
Del conocimiento al Contexto Vivo
Aquí aparece además otra dimensión que las arquitecturas empresariales tradicionales han tratado bastante mal.
En cualquier organización existe una enorme cantidad de información que no vive correctamente documentada.
Una conversación cambia la prioridad de un proyecto. Un responsable concede una excepción a un cliente. En una reunión se decide retrasar una contratación. Un técnico descubre que determinada máquina funciona mal bajo unas condiciones concretas. Un proveedor avisa por teléfono de que durante agosto no puede servir determinado producto.
La base de datos puede seguir siendo exactamente la misma.
Pero la realidad de la empresa ha cambiado.
A este tipo de información podemos denominarla Contexto Vivo: información que modifica la interpretación de lo que está ocurriendo aunque todavía no se haya convertido en un dato estructurado, una política formal o un procedimiento estable.
Y probablemente uno de los grandes desafíos de los próximos años no será únicamente construir mejores modelos, sino capturar ese Contexto Vivo y convertirlo en contexto procesable.
Un Context Graph puede convertirse en una de las estructuras naturales para hacerlo.
Una conversación puede generar una decisión. Esa decisión puede afectar a un proyecto. La decisión puede sustituir a otra anterior. Puede tener una fecha de caducidad. Puede haber sido tomada por una persona con una determinada autoridad. Puede estar respaldada por un correo electrónico, una reunión o un documento.
Ya no estamos guardando simplemente información.
Estamos guardando por qué la organización está actuando como está actuando.
Una posible arquitectura de la empresa preparada para agentes
Podemos imaginar entonces una especie de progresión.
Los datos nos dicen qué registros existen.
La Semantic Layer nos dice qué significan.
La Ontology define el mundo al que pertenecen.
El Knowledge Graph conecta lo que sabemos sobre ese mundo.
La Context Layer decide qué parte de todo ese conocimiento necesita un agente para una tarea concreta.
Y el Context Graph puede mantener conectada la evolución de esa situación: estados, decisiones, excepciones, evidencias, actores, antecedentes y consecuencias.
No significa necesariamente que una empresa necesite cinco productos diferentes.
De hecho, probablemente sería un error empezar por la tecnología.
Lo importante es comprender que estamos resolviendo problemas diferentes.
Una base de datos puede ser suficiente para almacenar las ventas. Una Semantic Layer puede ser necesaria para definir correctamente qué entendemos por ventas. Una ontología puede ayudarnos a comprender cómo una venta se relaciona con clientes, productos, contratos y territorios. Un Knowledge Graph puede conectar cada venta con sus entidades concretas. Una Context Layer puede seleccionar todo lo que necesita un agente cuando analiza una determinada operación. Y un Context Graph puede incorporar además qué decisiones, excepciones y acontecimientos hacen que esa operación tenga un significado especial precisamente ahora.
Cada capa añade algo que la anterior no representaba suficientemente.
El verdadero cambio: de sistemas de información a sistemas de comprensión
Durante décadas hemos construido sistemas de información.
ERP, CRM, gestores documentales, Business Intelligence, data warehouses y numerosas aplicaciones especializadas tienen fundamentalmente esa función: registrar, organizar, procesar o presentar información.
Los agentes introducen una exigencia diferente.
Necesitan construir una representación suficientemente buena de la realidad para poder actuar sobre ella.
Eso obliga a pasar de una arquitectura centrada exclusivamente en dónde está la información a otra preocupada también por qué significa, cómo se relaciona, de dónde procede, cuándo es válida y por qué importa en este momento.
La diferencia es enorme.
Porque una empresa puede tener perfectamente ordenados sus datos y seguir siendo prácticamente incomprensible para una inteligencia artificial.
Puede disponer de miles de documentos y seguir sin haber capturado las decisiones que explican cómo funciona realmente.
Puede tener un Knowledge Graph extraordinario y seguir sin representar que ayer alguien cambió temporalmente las reglas.
El próximo gran activo empresarial podría ser el contexto
Durante años se ha repetido que los datos eran el nuevo petróleo. Después empezamos a hablar del conocimiento empresarial como ventaja competitiva.
Con los agentes puede aparecer una capa todavía más importante.
El contexto.
No solamente saber que existe determinada información, sino saber cuándo es relevante, quién la produjo, qué sustituye, qué restricciones tiene, qué otras cosas afecta y en qué situación debe aplicarse.
Y esto puede acabar convirtiéndose en una infraestructura empresarial tan importante como hoy lo son el ERP o el CRM.
Porque cuando los modelos sean commodities y múltiples proveedores ofrezcan capacidades de razonamiento extraordinarias, una buena parte de la diferencia entre dos agentes no estará necesariamente en el modelo que utilizan.
Estará en el mundo que son capaces de comprender.
Una organización que haya conseguido construir una buena Semantic Layer, formalizar progresivamente su ontología, conectar su conocimiento, capturar su Contexto Vivo y mantener una infraestructura de contexto persistente dispondrá de algo mucho más difícil de copiar que un prompt o una aplicación.
Dispondrá de una representación computable de cómo funciona realmente la empresa.
Y quizás ése sea uno de los activos más importantes de la próxima generación de organizaciones basadas en inteligencia artificial.
No solamente datos para consultar.
No solamente conocimiento para recuperar.
Contexto para entender, decidir y actuar.