Durante los últimos años las compañías invirtieron mucho en centralizar información en data lakes, warehouses y plataformas analíticas. El problema es que, aunque los datos estén disponibles, acceder a ellos todavía suele requerir conocer el modelo, escribir SQL, navegar un dashboard o pedir ayuda a un equipo de datos.
Los agentes de IA empiezan a cambiar esa interfaz.
Un escenario particularmente interesante dentro del ecosistema Microsoft es combinar Microsoft Foundry con Microsoft Fabric, permitiendo que un usuario pueda realizar preguntas en lenguaje natural como:
"¿Cómo evolucionaron las ventas del último trimestre?"
"¿Qué productos tuvieron mayor crecimiento en Argentina?"
"¿Cuáles son los clientes con mayor caída de facturación respecto del año pasado?"
Y recibir una respuesta basada en los datos reales que la organización ya administra en Fabric.
La idea no es darle acceso directo al modelo de lenguaje a toda la base de datos. La arquitectura es bastante más interesante.
Dos agentes, dos responsabilidades
Una forma simple de entender esta solución es pensarla como una arquitectura con dos niveles.
Por un lado tenemos un Foundry Agent, responsable de interactuar con el usuario, entender qué necesita, decidir qué herramientas utilizar y construir la respuesta final.
Por otro lado tenemos un Fabric Data Agent, especializado en entender y consultar los datos disponibles dentro de Microsoft Fabric.
La arquitectura conceptual queda así:
Esto permite separar claramente la orquestación de IA de la capa de acceso y semántica de datos.
Microsoft describe justamente este patrón: el agente de Foundry puede decidir cuándo utilizar un Fabric Data Agent, invocarlo, recibir el resultado y utilizarlo para construir la respuesta al usuario.
El rol de Fabric Data Agent
Fabric Data Agent es la pieza que convierte los datos empresariales en una experiencia conversacional.
En lugar de enseñarle a un usuario qué tabla consultar o qué query ejecutar, podemos configurar un agente con conocimiento sobre determinadas fuentes de datos y sobre el significado que esos datos tienen dentro del negocio.
Por ejemplo, podríamos tener un Data Agent especializado en ventas que conozca conceptos como:
Revenue
Customer
Product
Region
Sales Order
Margin
Fiscal Period
Ese agente puede trabajar sobre diferentes componentes de Fabric, como Lakehouses, Warehouses, modelos semánticos de Power BI o bases KQL.
Pero hay un punto importante: el Data Agent no debería ser visto simplemente como un generador de SQL.
Su valor está en agregar una capa intermedia entre la pregunta humana y la estructura técnica de los datos.
La pregunta:
¿Cuáles fueron nuestros mejores clientes este trimestre?
eventualmente puede terminar generando una consulta sobre varias tablas, relaciones, métricas o modelos semánticos.
El usuario no necesita conocer esos detalles.
¿Y qué hace Foundry entonces?
Si Fabric ya puede responder preguntas sobre datos, es razonable preguntarse para qué necesitamos Foundry.
La respuesta está en la orquestación.
El Foundry Agent puede tener más responsabilidades que simplemente consultar información analítica.
Por ejemplo, podría recibir:
Analizá las ventas del último trimestre,
identificá las regiones con caída mayor al 10%
y preparame un resumen ejecutivo.
El agente puede decidir consultar Fabric, interpretar el resultado y luego utilizar el modelo de lenguaje para generar una explicación apropiada para el usuario.
Incluso podemos imaginar escenarios donde el agente tenga varias herramientas:
- Foundry Agent
- Fabric Data AgentVentas
- Fabric Data AgentSupply Chain
- Knowledge BaseDocumentación interna
- API corporativa
- otras herramientas
De esa forma, Foundry se convierte en una capa de interacción y razonamiento sobre distintos sistemas empresariales.
Fabric IQ: una evolución interesante
Microsoft está avanzando además con una integración a través de Fabric IQ y OneLake Catalog.
Con este enfoque, un agente creado en Microsoft Foundry puede descubrir y utilizar Data Agents publicados en Fabric directamente desde OneLake Catalog.
Esto simplifica bastante la arquitectura.
En lugar de configurar manualmente IDs de workspace y artefactos, es posible seleccionar los Data Agents disponibles desde el catálogo de Fabric. Además, un mismo Foundry Agent puede utilizar múltiples Data Agents.
Por ejemplo:
El agente recibe una pregunta y decide cuál utilizar.
Microsoft indica además que, en esta integración, cada Fabric Data Agent se expone al agente de Foundry como un endpoint compatible con Model Context Protocol (MCP).
Esto es especialmente interesante porque empieza a transformar los Data Agents en herramientas reutilizables dentro de arquitecturas multiagente.
Un ejemplo concreto
Supongamos que un director comercial escribe:
¿Por qué bajaron las ventas en agosto?
El flujo podría ser el siguiente.
Primero, el Foundry Agent interpreta que se trata de una pregunta analítica relacionada con ventas.
Entonces selecciona el Sales Data Agent de Fabric.
Fabric puede consultar los datos correspondientes y devolver información como:
Revenue August: -8.4% MoM
Main contributors:
Argentina: -14%
Brazil: -3%
Chile: +2%
Argentina decline concentrated in:
- Enterprise segment
- Product Category A
Foundry recibe esa información y puede construir una respuesta mucho más natural:
Las ventas de agosto cayeron un 8,4% respecto de julio.
El principal factor fue Argentina, donde la caída alcanzó el 14%.
La mayor parte de esa variación se concentra en el segmento Enterprise
y, particularmente, en la categoría de producto A.
Brasil también presentó una pequeña contracción, mientras que Chile
creció un 2% durante el mismo período.
El LLM se ocupa de explicar.
Fabric se ocupa de obtener y procesar el dato.
Esa separación es importante.
Seguridad: el punto que hace viable el escenario empresarial
Cuando hablamos de agentes consultando información corporativa, probablemente la pregunta más importante no sea qué modelo estamos utilizando.
Es:
¿qué datos puede ver cada usuario?
La integración entre Foundry y Fabric está diseñada para trabajar con identidad delegada.
Cuando el Foundry Agent llama al Fabric Data Agent, la consulta puede ejecutarse utilizando la identidad del usuario conectado. Fabric continúa aplicando los permisos que ese usuario ya posee sobre los recursos subyacentes.
Esto evita crear un "super usuario de IA" con acceso indiscriminado a toda la información.
Si una persona no puede consultar determinados datos en Fabric, el agente tampoco debería utilizarlos para responderle.
Para escenarios empresariales, esta característica probablemente sea más importante que cualquier mejora de prompting.
Cómo configurarlo a alto nivel
Sin entrar demasiado en los detalles de implementación, el proceso se puede pensar en cinco pasos.
1. Preparar los datos en Fabric
Primero necesitamos una fuente de datos confiable y gobernada.
Podría ser un Warehouse, un Lakehouse o un modelo semántico de Power BI.
La calidad de la respuesta del agente depende directamente de la calidad y claridad de esa capa.
2. Crear un Fabric Data Agent
Dentro de Fabric creamos el Data Agent, seleccionamos las fuentes correspondientes y configuramos su contexto.
También podemos agregar instrucciones para ayudarlo a entender cómo interpretar conceptos propios de nuestra organización.
Por ejemplo:
Revenue siempre significa Net Revenue.
Cuando el usuario solicite ventas por región,
utilizar SalesRegion y no BillingCountry.
Fiscal Year comienza en julio.
Este tipo de contexto puede marcar una enorme diferencia en la calidad de las respuestas.
3. Publicar y probar el Data Agent
Antes de conectarlo con Foundry conviene validarlo directamente en Fabric.
Preguntas simples:
¿Cuánto vendimos este mes?
Preguntas con dimensiones:
Mostrame ventas por región.
Preguntas comparativas:
¿Qué regiones crecieron más respecto del mismo período del año pasado?
El objetivo es validar primero la capa de datos y recién después agregar la capa de orquestación.
4. Conectarlo con Microsoft Foundry
En Foundry podemos agregar Fabric como herramienta del agente.
En el enfoque más reciente con Fabric IQ / OneLake Catalog, el Data Agent publicado puede seleccionarse desde el catálogo y agregarse como una herramienta del agente.
Luego podemos darle instrucciones al Foundry Agent como:
You are the corporate data assistant.
For questions related to sales, revenue, customers,
products or commercial performance, use the Sales Data Agent.
Do not invent financial values.
If Fabric doesn't provide enough information to answer a question,
clearly explain what information is missing.
Esta parte es fundamental.
Un buen agente no solamente necesita herramientas: necesita saber cuándo utilizarlas.
5. Probar preguntas reales
Finalmente hay que probar el agente con preguntas que realmente haría el negocio.
No solamente:
¿Cuáles fueron las ventas?
Sino también:
¿Por qué cayó el revenue?
¿Qué clientes explican la diferencia contra budget?
Compará Argentina y Brasil durante los últimos seis meses.
Resumime los tres principales cambios que debería mirar el CFO.
Estas preguntas permiten evaluar no solo si la consulta funciona, sino si la experiencia completa tiene valor para el usuario.
Una recomendación: no crear "el agente que sabe todo"
Técnicamente resulta tentador conectar un agente a todos los datos de la organización.
No necesariamente es la mejor arquitectura.
Puede ser más saludable construir Data Agents especializados por dominio:
Sales Agent
Finance Agent
Operations Agent
Supply Chain Agent
Customer Agent
Cada uno con fuentes de datos, vocabulario e instrucciones claramente definidas.
Después podemos colocar un Foundry Agent como orchestrator, responsable de decidir cuál consultar.
Este diseño hace que sea más fácil razonar sobre permisos, ownership, calidad de datos y responsabilidades de cada agente.
Además, el nuevo modelo de integración mediante Fabric IQ permite precisamente que un mismo agente de Foundry tenga varios Data Agents disponibles y seleccione el adecuado según la pregunta.
El verdadero desafío no es el LLM
Cuando uno construye este tipo de solución, es fácil concentrarse demasiado en qué modelo utilizar.
Pero en un escenario empresarial probablemente los desafíos más importantes estén en otro lado:
- ¿Tenemos métricas claramente definidas?
- ¿Los usuarios entienden "revenue" de la misma forma?
- ¿Los modelos semánticos reflejan correctamente las reglas de negocio?
- ¿Los permisos están bien diseñados?
- ¿El agente sabe cuándo tiene suficiente información para responder?
- ¿Podemos observar qué fuente utilizó para llegar a la respuesta?
En otras palabras: un agente de datos bueno sigue necesitando una buena plataforma de datos.
La IA reduce enormemente la fricción para acceder a la información, pero no reemplaza la necesidad de gobernanza, semántica y calidad.
De dashboards a conversaciones
Los dashboards no van a desaparecer.
Hay métricas que queremos observar siempre de la misma manera y visualizaciones que siguen siendo la mejor forma de comprender determinados fenómenos.
Pero los agentes agregan otra interfaz.
Una persona puede mirar un dashboard y después preguntar:
¿Por qué pasó esto?
Y continuar:
¿Qué clientes explican la caída?
¿Ocurrió algo similar el año pasado?
Resumilo en tres puntos para presentarlo en la reunión.
Ese tipo de interacción sería mucho más difícil de resolver únicamente con una interfaz tradicional de BI.
La combinación de Microsoft Foundry + Microsoft Fabric apunta justamente a ese espacio: mantener los datos dentro de una plataforma gobernada, pero permitir que los usuarios interactúen con ellos utilizando lenguaje natural.
Conclusión
Una arquitectura de agentes empresariales no necesita empezar con un sistema multiagente extremadamente complejo.
Podemos comenzar con algo bastante simple.
Fabric sigue siendo responsable de los datos, su semántica y sus permisos.
Foundry agrega la capacidad de razonar sobre la intención del usuario, seleccionar herramientas y transformar los resultados en una conversación útil.
A partir de ahí podemos evolucionar hacia varios dominios, múltiples Data Agents, Fabric IQ, MCP y arquitecturas de agentes más sofisticadas.
Pero la idea fundamental sigue siendo sencilla:
no se trata de enseñarle todos los datos de la compañía a un modelo de IA.
Se trata de darle al agente una forma segura, gobernada y contextual de consultar los datos correctos cuando los necesita.
Y probablemente ahí esté una de las aplicaciones más interesantes de los agentes dentro de una empresa.
Nota: varias de las capacidades de integración entre Microsoft Foundry, Fabric Data Agent y Fabric IQ se encuentran actualmente en preview. Para implementaciones productivas conviene validar disponibilidad regional, requisitos de capacidad, permisos, límites de cumplimiento y estado de cada feature en la documentación oficial de Microsoft.