Agentes de datos impulsados por ontologías en Microsoft Fabric IQ: Una guía práctica
Aprenda cómo Microsoft Fabric IQ combina modelos semánticos, ontologías y MCP para llevar a los agentes de IA empresarial de la recuperación de datos al razonamiento comercial regulado.
Fuentes: Microsoft Fabric IQ and Data Agents for Ontology based Consumption
En resumen: la IA empresarial está experimentando un cambio significativo. La primera ola de IA generativa empresarial se centró principalmente en la recuperación de datos. La próxima ola de agentes empresariales irá más allá de simplemente obtener datos; podrán razonar utilizando un significado empresarial regulado.
Question
↓
LLM
↓
Vector Search / RAG
↓
Documents
↓
Answer
El modelo emergente se basa en el razonamiento a partir del significado empresarial:
Business Question
│
▼
Agent / Planner
│
┌─────────┴─────────┐
▼ ▼
Semantic Model Ontology
"How measured?" "What does it mean?"
│ │
└─────────┬─────────┘
▼
Enterprise Data
│
▼
Insight / Decision
│
▼
Action
Esta diferencia es de gran importancia.
Una base de datos simple puede indicarle a un agente algo como:
customers.CustomerId = sales.CustomerId
Por el contrario, una ontología puede indicarle al agente:
Customer ── PURCHASES ──> Product
Y un modelo semántico puede ir un paso más allá y indicarle:
Total Revenue = governed enterprise measure
Estos representan tres niveles de comprensión completamente diferentes.
Microsoft está integrando estas ideas bajo Fabric IQ: el modelo semántico proporciona mediciones analíticas fiables, la ontología ofrece un vocabulario empresarial compartido y una estructura de relaciones, la capa de grafos permite el recorrido de datos conectados, y los Agentes de Datos exponen toda esa inteligencia a través de conversaciones. Microsoft presenta a Fabric IQ como la capa de contexto empresarial que convierte datos analíticos y operativos en bruto en conceptos comerciales sobre los cuales un agente puede razonar realmente.
El aspecto arquitectónico que hace esto verdaderamente interesante es el siguiente:
Se puede publicar un Agente de Datos de Fabric y exponerlo a través del Protocolo de Contexto de Modelo (MCP), de modo que los agentes Microsoft Foundry — o cualquier otro agente compatible con MCP — puedan utilizar la inteligencia empresarial regulada como si fuera otra herramienta más.
Microsoft ahora admite exactamente este flujo: un Fabric Data Agent publicado puede aparecer como una herramienta MCP ante un agente Foundry, y un único agente Foundry puede luego coordinar varios Fabric Data Agents junto con otras herramientas y fuentes de conocimiento.
1. Por qué la ontología vuelve a ser importante de repente
La ontología no es una idea nueva.
Tampoco lo son los grafos de conocimiento.
Igualmente, los modelos semánticos no son algo novedoso.
Lo que realmente ha cambiado es quién los utiliza.
Historialmente, la tecnología semántica empresarial era utilizada principalmente por:
- plataformas de búsqueda
- Herramientas de BI
- Sistemas de integración de datos
- Gestión de taxonomías
- Aplicaciones basadas en grafos
- Especialistas en el área
Ahora hay un nuevo usuario en este escenario:
Agentes de IA.
Y los agentes se enfrentan a un verdadero obstáculo aquí.
Los modelos de lenguaje grandes razonan bien a partir de la información que se les proporciona, pero las bases de datos empresariales casi nunca describen el negocio de la manera en que las personas lo piensan naturalmente.
Por ejemplo:
CUSTOMER_MASTER.CUST_ID
SALES_TXN.CUST_ID
SALES_TXN.PROD_NM
SALES_TXN.NET_REV
No obstante, una persona piensa en términos como:
Customer
│
│ PURCHASES
▼
Product
│
└── generates → Revenue
La distancia entre estas dos representaciones es la fuente de una gran parte de la incertidumbre en los agentes.
Al carecer de un fundamento semántico, el agente se ve obligado a adivinar:
- qué tablas corresponden a qué conceptos empresariales
- cuáles uniones son realmente válidas
- qué representa realmente una columna determinada
- qué definición de métrica debe considerarse autoritativa
- cómo se relacionan entre sí las entidades
- sí dos campos con nombres diferentes significan realmente lo mismo
Eso es un problema tolerable en una demostración con cinco tablas.
Con cientos de productos de datos empresariales, esto se vuelve realmente arriesgado.
La función de Ontología de Fabric está diseñada específicamente para funcionar como un vocabulario empresarial compartido y legible por máquinas, compuesto por tipos de entidades, propiedades, relaciones, restricciones y vinculaciones a datos reales de OneLake. Ese vocabulario puede ser utilizado tanto por usuarios humanos como por agentes.
2. Pero “Gráfico de Conocimiento” no significa una sola arquitectura
Un flujo de decisiones visual que acompaña esta discusión ayuda a aclarar por qué elegir un enfoque basado en gráficos y ontologías no es una solución que funcione para todos los casos.
[Insertar: Flujo de decisión para soluciones de gráficos y ontologías]
No existe una única forma correcta de arquitecturar un gráfico.
El panorama puede dividirse aproximadamente en cinco patrones.
Patrón 1 — RDF / Gráfico de Conocimiento Semántico
Este es el enfoque tradicional de la web semántica:
Subject ─ Predicate ─> Object
Por lo general, se combina con:
RDF
RDFS
OWL
SPARQL
Ventajas: semántica expresiva y rica, interoperabilidad basada en estándares, enfoques maduros para el modelado de ontologías y soporte para el razonamiento formal.
Desventajas: mayor complejidad en el modelado, necesidad de habilidades especializadas e infraestructura que con frecuencia supera las necesidades reales de la aplicación.
3. Gráficos de propiedades etiquetados
El modelo de gráfico de propiedades etiquetadas (LPG) adopta un enfoque más centrado en la aplicación:
(Customer)
│
│ PURCHASED
│ {date, quantity}
▼
(Product)
Tanto los nodos como las aristas pueden tener sus propias propiedades.
Herramientas como Neo4j popularizaron este modelo porque se adapta naturalmente a aplicaciones que realizan muchas operaciones de recorrido.
Ventajas: modelado intuitivo de grafos, alto rendimiento en el recorrido de los mismos, algoritmos avanzados para grafos y una sólida experiencia en desarrollo de aplicaciones.
Desventajas: el esquema del grafo por sí solo no se convierte en un vocabulario semántico empresarial regulado; esa capa de significado aún debe modelarse y gestionarse por separado.
Microsoft Fabric Graph sigue este enfoque LPG, mapeando las tablas de OneLake a tipos de nodos y aristas y permitiendo el recorrido mediante GQL. La implementación de GQL por parte de Microsoft sigue el lenguaje estandarizado ISO Graph Query Language.
4. Un camino más sencillo: ontología más un grafo en memoria
No todo agente requiere una base de datos de grafos empresarial completa.
Para aplicaciones de tipo chat, escenarios con pocas conexiones, asistentes con alcance limitado o trabajos de prueba de concepto, se puede representar una ontología simple como JSON puro:
{
"entities": {
"Customer": {},
"Product": {}
},
"relationships": {
"Purchases": {
"from": "Customer",
"to": "Product"
}
}
}
La capa de aplicación puede cargar esa definición en NetworkX, Memgraph, una biblioteca RDF o cualquier otra estructura de gráfico en memoria.
Este enfoque se configura rápidamente y su ejecución es económica.
El problema es que la gobernanza, la seguridad, el seguimiento de la línea de origen, la escalabilidad, mantener los datos sincronizados y la propiedad compartida de las definiciones semánticas son aspectos que debe resolver por sí mismo.
5. Por qué Microsoft Fabric se destaca aquí
Fabric aborda el problema desde un ángulo diferente.
En lugar de partir de la premisa de que todos los datos empresariales deben migrarse a una base de datos gráfica, la arquitectura puede comenzar con la premisa de que los datos empresariales permanecen donde están, en OneLake, y la inteligencia semántica y de relaciones se aplica sobre ellos.
En forma de diagrama:
Fabric IQ
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Semantic Model Ontology Graph
│ │ │
trusted metrics business meaning traversal
│ │ │
└─────────────────┼──────────────────┘
│
OneLake
Microsoft establece una distinción clara entre estas responsabilidades: los modelos semánticos proporcionan KPI confiables y estructuras analíticas, la ontología ofrece un vocabulario empresarial compartido, el grafo se encarga del recorrido a través de datos conectados, y los agentes de datos u operaciones brindan interacción e acciones inteligentes basadas en ese contexto.
Esa separación de responsabilidades es importante desde el punto de vista arquitectónico.
6. El modelo semántico, la ontología y el grafo son tres cosas diferentes
A menudo estos términos se utilizan como si fueran sinónimos. No lo son.
Una forma útil de pensar en ello:
DATA
"What happened?"
│
▼
SEMANTIC MODEL
"How should it be measured?"
│
▼
ONTOLOGY
"What does it mean?"
│
▼
GRAPH
"How is everything connected?"
│
▼
AGENT
"What should I investigate or do?"
Un modelo semántico de Power BI podría definir mediciones como:
Total Revenue
Average Order Value
Customer Count
Revenue by Segment
Una ontología podría definir entidades y relaciones como:
Customer
Product
Customer ── PURCHASES ──> Product
El grafo es lo que realmente instancia y recorre esas conexiones:
Customer A
│
├── PURCHASES → Laptop
│
├── PURCHASES → Monitor
│
└── PURCHASES → Dock
Luego, el agente de datos presenta toda esa información a través de interacciones en lenguaje natural.
Fabric también permite derivar una ontología directamente de un modelo semántico existente: las tablas se convierten en tipos de entidad, las columnas en propiedades, y las relaciones ya definidas en el modelo semántico se convierten en relaciones de la ontología.
7. Construyéndolo: un producto de datos de ventas mínimo
Para mantener el enfoque en la arquitectura en lugar de en la ingeniería de datos, el ejemplo se mantiene deliberadamente simple.
Solo se utilizan dos tablas de origen:
NP_SalesDataProduct_LH
customers
──────────────
CustomerId
CustomerName
Segment
City
State
Country
sales
──────────────
OrderId
OrderDate
CustomerId
ProductName
ProductCategory
Quantity
UnitPrice
DiscountPct
Revenue
SalesChannel
La relación entre ellas es sencilla:
customers.CustomerId
1
│
*
sales.CustomerId
Esto es suficiente para explicar toda la arquitectura sin que la complejidad del modelado obstaculice la lección subyacente.
8. Paso 1: Crear el producto de datos de Fabric
Los dos archivos CSV se cargan en un Fabric Lakehouse:
NP_SalesDataProduct_LH
│
├── Tables
│ └── dbo
│ ├── customers
│ └── sales
│
└── Files
├── customers.csv
└── sales.csv
[Insertar captura de pantalla: Lakehouse que muestra clientes y ventas]
En esta etapa ya cuenta con un Fabric Data Agent funcional.
Puede responder a preguntas como cuál es el ingreso total, qué categorías de productos generan más ingresos y cómo se distribuyen los ingresos por segmento de clientes.
Pero hay algo digno de atención que ocurre en el fondo.
Al no haber definido semántica adicional, el agente debe inferir la unión por sí mismo:
customers.CustomerId
=
sales.CustomerId
y también debe inferir que:
Revenue → SUM(Revenue)
Eso le proporciona un punto de referencia para comparar.
9. Paso 2: Agregar el modelo semántico
A continuación, introduce el contrato analítico.
Customer
1
│
*
Sales
con medidas reguladas como:
Total Revenue =
SUM(sales[Revenue])
y:
Total Orders =
DISTINCTCOUNT(sales[OrderId])
En este punto, el agente ya no tiene que adivinar qué significa “Ingresos Totales”.
Esa definición pertenece a la capa semántica.
Esto señala un principio importante para los agentes empresariales:
Los agentes deben utilizar métricas reguladas en lugar de reconstruir los cálculos empresariales a partir de columnas brutas cada vez que llega una pregunta.
10. Paso 3: Agregar la ontología
A partir de aquí se pasa de las definiciones analíticas al significado a nivel empresarial.
La ontología en este ejercicio define solo dos tipos de entidades:
Customer
Product
El cliente se corresponde con:
customers.CustomerId
customers.CustomerName
customers.Segment
customers.City
customers.State
customers.Country
using:
KEY = CustomerId
Mientras tanto, el producto se deriva directamente de la tabla existente sales:
sales.ProductName
sales.ProductCategory
using:
KEY = ProductName
Nuevamente, no fue necesario crear una tabla física separada de Productos para que esto funcionara.
11. Definir la relación de negocio
A continuación, se agrega una relación:
Customer
│
│ PURCHASES
▼
Product
Lo interesante aquí es cómo funciona el vinculamiento de datos.
La propia tabla sales actúa como puente para esta relación:
Customer.CustomerId
↑
sales.CustomerId
sales.ProductName
↓
Product.ProductName
Así que una fila bruta de ventas como:
sales row:
CustomerId = C001
ProductName = Laptop Pro
se convierte en:
Customer(C001)
│
│ PURCHASES
▼
Product(Laptop Pro)
Este es el momento en que un registro relacional simple se transforma en algo que el negocio reconoce realmente como conocimiento.
El modelo de ontología de Fabric está diseñado específicamente para este flujo de trabajo: primero se definen los tipos de entidad y sus relaciones, y luego esas definiciones abstractas se vinculan a datos concretos almacenados en OneLake.
12. ¿Qué cambia para el agente?
Tomemos esta pregunta:
¿Qué productos compran los clientes empresariales?
Sin una ontología disponible, el agente debe razonar de la siguiente manera:
Find customers table
↓
Find Segment
↓
Filter Enterprise
↓
Determine CustomerId join
↓
Join sales
↓
Find ProductName
Con la ontología disponible, el razonamiento se simplifica a:
Customer
│
Segment = Enterprise
│
└── PURCHASES ──> Product
La pregunta se corresponde casi directamente con el modelo en sí.
Microsoft describe este cambio como un paso para que los agentes dejen de pensar en términos de tablas individuales y pasen a utilizar una visión estructurada basada en entidades, relaciones, definiciones, reglas y mapeos de fuentes.
13. Paso 4: Crear el agente de datos Fabric
El agente de datos es lo que convierte todo esto en una interfaz de lenguaje natural:
User
│
▼
NP_Sales_DataAgent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Lakehouse Semantic Model Ontology
│ │ │
raw facts trusted KPIs relationships
│ │ │
└─────────────┼─────────────┘
▼
OneLake
Microsoft describe a los Fabric Data Agents como una capa de respuesta a preguntas en lenguaje natural limitada a un dominio de datos definido, donde la ontología proporciona el contexto empresarial más profundo del cual se sirven dichos agentes.
14. Luego viene el paso arquitectónico importante: MCP
No es necesario que un Fabric Data Agent permanezca encerrado dentro de Fabric.
Puede publicarse.
Una vez publicado, Fabric expone ese agente como un servidor de Protocolo de Contexto de Modelo.
Conceptualmente, el flujo se ve así:
Fabric Data Agent
│
│ Publish
▼
MCP Server
│
├── tool description
├── input schema
└── governed execution
En ese punto, la inteligencia de datos empresarial se convierte en algo reutilizable: una herramienta de agente que otros sistemas pueden llamar.
15. Microsoft Foundry se convierte en la capa de orquestación
Esto abre la posibilidad de una arquitectura considerablemente más interesante.
USER
│
▼
Microsoft Foundry Agent
│
planning / orchestration
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
CRM Tool Search Tool Fabric MCP
│
▼
Fabric Data Agent
│
┌───────────────────┼───────────────┐
▼ ▼ ▼
Semantic Model Ontology Lakehouse
│ │ │
└───────────────────┼───────────────┘
▼
OneLake
La separación de responsabilidades aquí es importante.
El agente de Foundry se encarga del razonamiento de flujos de trabajo.
El agente de datos de Fabric se encarga del razonamiento de datos.
En su forma actual, la integración de Foundry de Microsoft permite que un agente de Foundry descubra agentes de datos de Fabric publicados a través del Fabric IQ / OneLake Catalog y los trate como herramientas MCP. Un único agente de Foundry tampoco está limitado a un solo dominio: puede obtener y utilizar varios agentes de datos de Fabric al mismo tiempo.
16. Un ejemplo práctico
Imagínese que un usuario envía una solicitud al agente de Foundry con los siguientes requisitos: encontrar el segmento de clientes que aporta la mayor parte de los ingresos, determinar qué productos impulsan el rendimiento de ese segmento y convertir esos hallazgos en una recomendación que el equipo de ventas pueda poner en práctica.
A continuación, se muestra cómo podría desarrollarse la ejecución:
USER
│
▼
Foundry Orchestrator
│
│ "I need enterprise sales intelligence."
│
▼
Fabric Data Agent MCP Tool
│
├── Semantic Model
│ → trusted revenue calculation
│
├── Ontology
│ → Customer → PURCHASES → Product
│
└── Lakehouse
→ transaction data
│
▼
Result:
Enterprise customers generate...
Laptop category contributes...
│
▼
Foundry Agent
│
├── reasoning
├── CRM lookup
├── recommendation generation
└── potentially action
│
▼
Sales recommendation
Lo importante aquí no es que un modelo de lenguaje haya generado una recomendación. Lo relevante es que dicha recomendación se basó en una representación empresarial estructurada, y no fue improvisada a partir de tablas sin procesar ni semántica especulativa.
17. MCP cambia la arquitectura de los agentes empresariales
Sin MCP, los equipos suelen conectar las cosas de esta manera:
Agent A → custom Fabric integration
Agent B → another custom Fabric integrationAgent C → another SQL implementationAgent D → another Power BI integration
Con el paso del tiempo, cada agente acumula conocimientos profundos pero frágiles sobre la plataforma de datos subyacente.
Con MCP en uso, la situación es diferente:
Enterprise Agents
┌───────────┼───────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└───────────┼───────────┘
│
MCP Tool
│
▼
Fabric Data Agent
│
▼
Governed Data IQ
El agente de datos Fabric se convierte en un producto de inteligencia de datos diseñado para ser consumido por los agentes, en lugar de una integración personalizada que cada equipo debe reconstruir. Se trata de un cambio aparentemente pequeño pero de gran importancia arquitectónica.
18. Otra opción: exponer la ontología directamente
Existe un segundo enfoque que merece ser considerado.
En lugar de enrutar todo a través de un Fabric Data Agent, la propia Ontología de Fabric puede exponerse mediante MCP a cualquier agente externo compatible. Microsoft documenta un servidor Ontology MCP que incluye herramientas para descubrir tipos de entidades ontológicas y ejecutar consultas contra la ontología.
Eso ofrece dos patrones distintos:
PATTERN A
External Agent
│
│ MCP
▼
Fabric Data Agent
│
▼
Ontology
en contraste con:
PATTERN B
External Agent
│
│ MCP
▼
Fabric Ontology
Elija el primer patrón cuando desee aprovechar la propia capa de razonamiento conversacional y de agentes de datos de Fabric. Elija el segundo cuando el agente externo ya cuente con su propia lógica de planificación sofisticada y solo necesite un acceso más directo al modelo semántico empresarial.
19. Ventajas y desventajas del patrón de Fabric
Ventajas
Semántica centralizada. Las definiciones empresariales se encuentran en un único lugar gestionado, en lugar de copiarse y pegarse en cada solicitud.
Basado en OneLake. No existe un requisito estricto de duplicar todo el conjunto de datos en una plataforma de grafos separada.
Tres capas que trabajan juntas. Las métricas analíticas y la semántica a nivel de relaciones pueden coexistir en el modelo semántico, la ontología y el grafo.
Diseñado para agentes. Tanto los Fabric Data Agents como la capa de ontología se crearon expresamente para funcionar como fuentes de referencia para los agentes de IA.
Abierto a través de MCP. La capa de inteligencia resultante puede ser utilizada por Foundry, así como por clientes MCP personalizados.
Separación clara de responsabilidades.
Fabric → data intelligence
Foundry → orchestration intelligence
Esa división crea un límite notablemente claro a nivel empresarial.
20. Compromisos
Existen algunas consideraciones importantes.
Gran parte de esto sigue siendo tecnología en versión preliminar. El soporte para ontologías, varias integraciones con Fabric IQ y Foundry, así como las capacidades MCP relacionadas, siguen siendo funciones en versión preliminar; por lo tanto, debe verificarlas según los términos actuales de prueba de Microsoft antes de utilizarlas en entornos de producción.
La gobernanza de ontologías es un trabajo real y continuo. Una vez que varios dominios comiencen a definir sus propias entidades como Customer, Account, Product, Contract y similares, alguien tendrá que encargarse de la nomenclatura, la versionado y la alineación entre dominios.
La ontología no puede corregir datos defectuosos. Aunque se apliquen semánticas empresariales elegantes a un conjunto de datos de baja calidad, las respuestas seguirán siendo de mala calidad.
La ontología no siempre es necesaria. Para la agregación sencilla de KPI, consultar directamente el modelo semántico puede ser más simple y suficiente.
No todos los casos de uso de grafos encajan aquí. Los algoritmos de grafos complejos, el razonamiento especializado en estilo RDF o cargas de trabajo de grafos altamente personalizadas pueden requerir, en su lugar, una plataforma dedicada para grafos.
Esa es precisamente la razón por la que un marco de toma de decisiones por fases es útil.
21. La hoja de ruta que utilizaría
En lugar de lanzarse directamente a un proyecto de ontología a nivel empresarial, tiene sentido avanzar por etapas.
Fase 1: Productos de datos
Sources
↓
OneLake
↓
Domain Data Products
El objetivo aquí es establecer datos de dominio fiables y claramente gestionados.
Fase 2: Semántica analítica
Data Product
↓
Semantic Model
↓
Measures / KPIs / Dimensions
Esta fase define cómo la organización mide las cosas.
Fase 3: Semántica empresarial
Semantic Models + Data Products
↓
Ontology
↓
Entities / Relationships / Rules
Esta fase define qué significan realmente las cosas que se miden.
Fase 4: Inteligencia conectada
Ontology
↓
Graph
↓
Traversal / dependency / impact analysis
En esta etapa, se utilizan estructuras de grafo únicamente cuando el recorrido de relaciones realmente aporta valor.
Fase 5: Agentes de datos del dominio
Ontology + Semantic Model + Data
↓
Data Agent
Aquí se convierte ese conocimiento acumulado del dominio en algo comunicable de forma conversacional.
Fase 6: MCP
Data Agent
↓
Publish
↓
MCP
Este paso convierte el producto conversacional en una capacidad que otros agentes pueden utilizar.
Fase 7: Orquestación de agentes empresariales
Foundry Agent
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Sales Data Agent Supply Agent Finance Agent
│ │ │
└──────────────────┼──────────────────┘
│
Fabric IQ
Microsoft ya está avanzando en esta dirección: los agentes Foundry pueden acceder a varios agentes de datos Fabric publicados a través de Fabric IQ, siendo cada uno de esos agentes expuesto como una herramienta MCP.
Hacia dónde se dirige
El cambio arquitectónico más amplio se ve así:
GENERATION 1
LLM + RAG
│
Documents
evolucionando hacia:
GENERATION 2
LLM + Tools + Data
│
SQL / APIs / RAG
y eventualmente hacia:
GENERATION 3
Agent Systems
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Documents Tools Enterprise IQ
│
┌──────────┼──────────┐
▼ ▼ ▼
Semantics Ontology Graph
│ │ │
└──────────┼──────────┘
▼
Enterprise Data
La ventaja en este campo dejará de depender cada vez más de qué modelo es el más potente.
En su lugar, provendrá de la organización que haya creado la capa de contexto empresarial más completa para que esos modelos puedan aprovecharla.
Microsoft define su dirección general como Microsoft IQ, donde Fabric IQ proporciona contexto sobre entidades comerciales y datos, trabajando junto con Work IQ, Foundry IQ y Web IQ.
Ese enfoque sigue siendo válido.
No se puede confiar en que un agente gestione partes de un negocio solo porque es bueno para buscar documentos.
Debe comprender:
Qué son las cosas.
Cómo se relacionan entre sí.
Cómo las mide realmente la organización.
Qué definiciones tienen autoridad.
En qué estado se encuentran actualmente esas cosas.
Y, en última instancia:
Qué acciones tienen sentido teniendo todo eso en cuenta.
Conclusión: De RAG al razonamiento empresarial
RAG proporcionó a la IA empresarial una forma de acceder al conocimiento.
El uso de herramientas dio a los agentes una forma de acceder a los sistemas.
La ontología les ofrece algo completamente distinto:
significado.
Una vez que ese significado se combina con métricas reguladas, relaciones gráficas, datos operativos en tiempo real y orquestación de agentes, se obtiene una arquitectura considerablemente más atractiva:
DATA
│
▼
SEMANTICS
│
▼
ONTOLOGY
│
▼
CONNECTED INTELLIGENCE
│
▼
DATA AGENTS
│
▼
MCP
│
▼
ENTERPRISE AGENTS
│
▼
DECISIONS
│
▼
ACTIONS
Eso, en última instancia, es la verdadera propuesta de valor detrás del análisis basado en agentes y ontologías.
No se trata simplemente de otro chatbot conectado a una base de datos.
Se trata de una arquitectura de inteligencia empresarial en la que los productos de datos proporcionan hechos, los modelos semánticos ofrecen mediciones fiables, las ontologías aportan significado, los gráficos muestran relaciones, los agentes del dominio brindan inteligencia, y MCP permite que toda esa inteligencia sea componible dentro del ecosistema de agentes más amplio.
Esa combinación es lo que hace que la próxima generación de IA empresarial sea mucho más interesante de desarrollar.
Lecturas relacionadas
- MCP para agentes de IA: Estandarizando la integración de herramientas en LangGraph — Este artículo explica qué es lo que realmente estandariza MCP en los sistemas de IA agentes, comparando las integraciones de herramientas ad hoc con las basadas en MCP dentro de un orquestador LangGraph.
- Enviando datos con RTK Query: Una guía práctica sobre mutaciones — Aprenda cómo utilizar builder.mutation() en RTK Query para enviar solicitudes POST, gestionar los estados de carga y error, y crear un componente de formulario funcional.