Un agente de datos de Fabric no inventa métricas ni reemplaza tu modelo semántico. Interpreta preguntas en lenguaje natural, ejecuta consultas de solo lectura sobre fuentes gobernadas y respeta los permisos de quien pregunta. La inteligencia no está en la IA, sino en el contrato de negocio que ya definiste.
Cuando alguien pregunta "¿cuánto vendimos el trimestre pasado?" a un asistente conectado a los datos, es fácil pensar que la magia ocurre en el modelo de lenguaje. No es así. La respuesta útil depende de tres piezas distintas que suelen confundirse: el modelo semántico, el agente y el canal. Separarlas es la diferencia entre una demostración puntual y algo que dirección puede usar para decidir.
Tres piezas que no son lo mismo
El error más común es tratar al agente como si fuera el modelo. No lo es. Cada capa tiene una responsabilidad clara:
- Modelo semántico. Define las medidas, las dimensiones, las relaciones, la seguridad y el vocabulario del negocio. Es el contrato: aquí vive la definición de "ventas netas", "margen" o "clientes activos".
- Fabric Data Agent. Acota un dominio, interpreta las preguntas y ejecuta consultas sobre fuentes aprobadas. No crea KPIs nuevos: hace consultable lo que el modelo ya declara.
- Canal. Es la superficie de consumo. Microsoft 365 Copilot de forma directa, Teams mediante Copilot Studio cuando corresponda, o clientes MCP como Claude, Codex o VS Code con autenticación de Fabric.
Como resume la guía de conceptos de Fabric Data Agent, el agente opera en solo lectura y respeta los permisos del usuario. No es un motor que reinventa el negocio: es un intérprete que se apoya en el modelo semántico como fuente de verdad. Si quieres profundizar en esa capa base, revisa nuestra guía sobre el modelo semántico como contrato de negocio.
Compartir el agente no reparte los datos
Este es el punto que más sorprende a los equipos de negocio: compartir un Data Agent no otorga acceso a los datos. Para obtener una respuesta, la persona necesita permiso sobre el agente y sobre el modelo semántico subyacente. Son dos accesos, no uno.
Esto tiene una consecuencia práctica importante. El agente respeta la seguridad a nivel de fila (RLS) y a nivel de objeto (OLS) que definiste en el modelo. Un gerente y un analista pueden hacer la misma pregunta y recibir alcances distintos si su seguridad es distinta. Por eso, antes de abrir el agente a dirección, se valida con las credenciales reales del usuario final, no solo con las del administrador que lo construyó. Probarlo únicamente con permisos de administrador esconde justo los errores que aparecerán en producción.
Las instrucciones son el criterio del agente
Un agente sin instrucciones responde como un diccionario de tablas técnicas y genera ruido. La preparación consiste en darle un criterio explícito. Las instrucciones base razonables incluyen:
- Usar solo las medidas y fuentes aprobadas, nunca inventar KPIs.
- Declarar siempre el período y los filtros de la respuesta.
- Explicar los límites de confianza cuando la pregunta es ambigua.
- Pedir aclaración si falta contexto en lugar de adivinar.
- Cerrar con una implicación de negocio, no solo con un número.
Esta preparación mejora la calidad de las respuestas, pero conviene ser honesto sobre su límite: el comportamiento de la IA no es determinista. Preparar bien el modelo y las instrucciones sube la probabilidad de una buena respuesta, no la garantiza al pie de la letra. Ese matiz importa cuando alguien promete "respuestas siempre correctas". Para el trabajo previo sobre el propio modelo, sirve nuestra guía de preparar datos para Copilot en Power BI.
No mezcles los canales
Publicar un Data Agent en Microsoft 365 Copilot, conectarlo a Copilot Studio y exponerlo mediante MCP son rutas distintas. Cada una requiere su propia guía operativa, sus permisos, sus pruebas y su revisión de la documentación vigente. Tratarlas como intercambiables lleva a fallos difíciles de diagnosticar.
Hay además una condición de cumplimiento que conviene tener presente: según el canal, algunas respuestas pueden procesarse fuera del límite de cumplimiento de Fabric. Esto no es un detalle menor para una empresa con requisitos de datos. Antes de una demostración o un uso real se validan el estado de cada función, el tenant, la capacidad F2 o superior cuando corresponda, las licencias, la configuración geográfica de IA y las políticas de datos.
Cuando el canal es un cliente MCP, el patrón cambia de forma. El endpoint de Fabric Data Agent sigue el formato de la API de Fabric, pero no se consume como una API REST abierta: se usa mediante el protocolo MCP con initialize, tools/list y tools/call, y cada solicitud necesita un token de Fabric. Como explica la documentación de servidores MCP de Fabric, estas piezas siguen en versión preliminar, así que el estado de cada función se confirma antes de comprometerlo con un cliente. Si quieres el detalle de esa ruta, revisa nuestra nota sobre MCP para consultar datos de Power BI y Fabric.
Disponible no significa validado
Un endpoint que devuelve status: ok solo demuestra disponibilidad. No prueba que las respuestas de negocio sean correctas. La validación real exige inicializar el cliente, listar las herramientas, ejecutar una consulta y comparar el resultado con métricas ya conocidas. Es la diferencia entre "el servicio responde" y "el servicio responde bien".
Este principio aplica a toda experiencia con IA sobre datos. La pregunta correcta no es "¿funciona?", sino "¿coincide con lo que ya sabemos que es verdad?".
Cómo diseñar una prueba controlada
Antes de abrir el agente a dirección, conviene construir una suite de validación pequeña y concreta. La idea es tratar las preguntas críticas como casos de prueba, con período explícito y valores esperados. Un formato útil:
| Pregunta | Período y filtro | Respuesta esperada | Criterio de aceptación |
|---|---|---|---|
| Total de una medida certificada | Período explícito, filtro declarado | Valor conocido de un visual revisado | Coincide con el visual de referencia |
| Misma pregunta, otro usuario | Usuario con RLS distinto | Alcance acotado por su seguridad | El RLS se aplica correctamente |
| Pregunta ambigua a propósito | Sin período | El agente pide aclaración | No inventa un período por su cuenta |
Los valores esperados no se inventan: nacen de visuales ya revisados en el modelo. El criterio de publicación incluye validar DAX mediante Execute Queries, la continuidad del calendario, el esquema simplificado, las instrucciones y las respuestas verificadas. Si una configuración solo se ve en la interfaz y no queda persistida, se documenta como verificación manual, no se da por hecha.
Esta disciplina convierte a las preguntas en una herramienta de calidad: en lugar de descubrir un error de modelo cuando un gerente ya presentó el número en una reunión, lo descubres en la suite, antes de publicar.
Qué hacer con esto
Si tu empresa está evaluando conectar un agente conversacional a sus datos, empieza por escribir cinco preguntas ejecutivas reales que tu dirección hará el primer día, con su período, su filtro y el valor que ya conoces de un visual revisado. Ese pequeño documento revela de inmediato si tu modelo semántico está listo o si el agente amplificaría huecos que hoy no ves. Si quieres ver cómo se aterriza este enfoque en un caso concreto, mira la demo gratuita.
Preguntas relacionadas
¿Un agente de datos de Fabric puede modificar el modelo semántico?
No. El Fabric Data Agent opera en solo lectura: interpreta preguntas y ejecuta consultas sobre fuentes aprobadas, pero no altera medidas, relaciones ni datos. Modificar metadatos o modelos corresponde a otras rutas, como el servidor MCP local para desarrollo, no al agente de consulta.
¿Si le doy acceso al agente a un usuario, ya puede ver todos los datos?
No. Compartir el agente no reparte permisos sobre los datos. La persona necesita acceso al agente y al modelo semántico subyacente, y las respuestas siguen respetando la seguridad a nivel de fila y de objeto que definiste. Dos usuarios con seguridad distinta pueden recibir alcances distintos ante la misma pregunta.
¿Por qué el agente a veces responde distinto a la misma pregunta?
Porque el comportamiento de la IA no es determinista. Preparar bien el modelo, las instrucciones y las respuestas verificadas sube la calidad y la probabilidad de una buena respuesta, pero no garantiza una salida idéntica palabra por palabra. Por eso la validación se hace contra valores conocidos, no contra una respuesta literal fija.
¿Es lo mismo un endpoint MCP que una API REST del negocio?
No. El endpoint de Fabric Data Agent se consume mediante el protocolo MCP con initialize, tools/list y tools/call, y requiere un token de Fabric en cada solicitud; no admite registro dinámico de clientes. Cuando un producto necesita respuestas versionadas, estables y auditables, una API gobernada propia sigue siendo la ruta adecuada, no el endpoint MCP.
¿Qué significa que una función esté en versión preliminar para una empresa?
Que puede cambiar y que debe validarse antes de comprometerla en una demostración o un uso real. Power BI MCP y Data Agent MCP están documentados como versiones preliminares, así que se confirman el estado de cada función, el tenant, la capacidad, las licencias, la configuración geográfica de IA y las políticas de datos antes de abrirlo a dirección.