La buena práctica central de la ciencia de datos en Microsoft Fabric no es entrenar más modelos, sino tratar el modelo semántico como el contrato de negocio y publicar agentes que solo consulten fuentes gobernadas. Un Fabric Data Agent no reemplaza ese contrato, lo hace consultable en lenguaje natural. La inteligencia está en hacer preguntable el vocabulario del negocio, no en inventar métricas.
¿Por qué el modelo semántico es la primera buena práctica?
Antes de hablar de agentes, notebooks o Copilot, ordena las métricas y las decisiones. El modelo semántico es el contrato común: define las medidas, las dimensiones, las relaciones, la seguridad y el vocabulario del negocio. Cuando ese contrato está limpio, cualquier consumidor (Excel, Power BI o una IA) ve los mismos números. Cuando está pobre, la IA no lo arregla: lo amplifica.
En la práctica, preparar el modelo para que la IA lo entienda significa trabajar cuatro cosas concretas:
- Nombres de negocio y descripciones claras en cada tabla y columna.
- Medidas certificadas, no columnas sueltas que cada persona interpreta distinto.
- Sinónimos para que una misma métrica responda a la forma en que la gente pregunta de verdad.
- Relaciones limpias y columnas técnicas ocultas, para que el modelo no exponga ruido.
Este orden es deliberado: criterio antes que herramienta. La ciencia de datos que se salta el contrato semántico produce dashboards que nadie confía y respuestas de IA que suenan seguras pero no cuadran.
¿Qué hace exactamente un Fabric Data Agent y qué no?
Un Fabric Data Agent acota un dominio, interpreta preguntas en lenguaje natural y ejecuta consultas sobre fuentes aprobadas. No inventa KPIs ni sustituye el modelo: es la capa que permite conversar con el contrato semántico y, así, lograr que un agente de IA responda sobre tus datos sin salirse de las fuentes gobernadas. Según Microsoft Learn, el Fabric Data Agent está en disponibilidad general como experiencia base, opera en solo lectura y respeta los permisos del usuario y las políticas de Purview.
Esa distinción importa. El agente no es un chatbot que adivina cifras: es un intérprete acotado que solo puede tocar lo que el modelo y la gobernanza ya aprobaron. La cadena de responsabilidad es simple:
- El modelo semántico define medidas, dimensiones, relaciones, seguridad y vocabulario.
- El Fabric Data Agent acota el dominio, interpreta la pregunta y ejecuta sobre fuentes aprobadas.
- El canal (Microsoft 365 Copilot, Teams vía Copilot Studio o clientes MCP) entrega la respuesta al usuario final.
¿Cómo se instruye a un agente para que sea confiable?
Un agente confiable no suena como un diccionario de tablas: ayuda a decidir sin salirse del contrato semántico. Las instrucciones base que conviene declararle son claras y verificables:
- Responder en el idioma del usuario.
- Usar solo las medidas y fuentes aprobadas.
- Declarar siempre el período y los filtros aplicados.
- No inventar KPIs.
- Explicar los límites de confianza de la respuesta.
- Pedir aclaración cuando falte contexto en lugar de suponer.
- Cerrar con la implicación de negocio, no solo con el número.
La buena práctica es que el agente sea explícito sobre qué miró y qué dejó fuera. Un agente que declara "esto es ventas netas del último trimestre, sin devoluciones" genera más confianza que uno que suelta una cifra sin contexto.
¿Qué validar antes de abrir el acceso?
Publicar un agente y abrirlo a toda la empresa el mismo día es la falla más común. La ciencia de datos en Fabric trata el despliegue como un proceso que se prueba antes de exponerse. Antes de abrir, valida:
- Un conjunto de preguntas de prueba con sus valores esperados.
- Los permisos por usuario, para confirmar que cada persona ve solo lo que le corresponde.
- El consentimiento inicial y las políticas de acceso.
- Una prueba real desde el canal final, no solo desde el entorno de desarrollo.
Compartir un Data Agent documenta el acceso y las pruebas con los consumidores, según Microsoft Learn. Esa documentación no es burocracia: es lo que permite auditar después por qué el agente respondió lo que respondió.
¿Por qué no se deben mezclar los canales de publicación?
Una práctica que se pasa por alto: cada canal es una ruta distinta. Publicar un Data Agent en Microsoft 365 Copilot, conectarlo a Copilot Studio para Teams o exponerlo mediante un cliente MCP como Claude, Codex o VS Code son caminos separados. Cada uno requiere su propia guía operativa, permisos, pruebas y revisión de la documentación vigente.
| Canal | Cuándo usarlo | Qué revisar |
|---|---|---|
| Microsoft 365 Copilot | Consulta directa del contrato desde el flujo diario | Permisos del usuario, licenciamiento |
| Teams vía Copilot Studio | Conversación de equipo, cuando corresponda | Guía de Copilot Studio, gestión de mensajes |
| Clientes MCP (Claude, Codex, VS Code) | Integración con herramientas de desarrollo | Autenticación de Fabric, alcance del acceso |
Mezclar canales sin tratarlos como rutas independientes rompe la trazabilidad. La buena práctica es documentar cada uno por separado y no asumir que lo probado en un canal aplica al otro.
¿Cómo encaja esto en la arquitectura de datos?
Todo lo anterior se apoya en una arquitectura ordenada. La arquitectura medallion (Bronze, Silver, Gold) da la base: datos crudos, datos limpios y productos de datos listos para consumo. El modelo semántico se construye sobre la capa Gold, y el agente consulta ese modelo. Nunca al revés.
Esta es la diferencia entre un sistema vivo y un experimento aislado: cuando el sistema funciona, cada capa alimenta a la siguiente con reglas claras, y la IA se conecta al final de la cadena, sobre fuentes ya gobernadas. En el experimento, alguien conecta un modelo a datos sin contrato y espera que la magia ocurra. No ocurre.
Buenas prácticas en resumen
- Ordena primero el modelo semántico: es el contrato, no un detalle técnico.
- Publica agentes que solo consulten fuentes gobernadas y en solo lectura.
- Instruye al agente para declarar período, filtros y límites, y para pedir aclaración.
- Valida con preguntas de prueba, permisos y una prueba desde el canal final antes de abrir.
- No mezcles canales: cada ruta de publicación tiene su propia guía y sus pruebas.
- Apóyate en la arquitectura medallion para que la IA consuma solo la capa Gold.
Si tu equipo quiere construir esta capacidad de forma ordenada, el siguiente paso natural es formar el criterio antes que multiplicar herramientas. La formación y la consultoría son caminos válidos según el punto de partida de cada organización. Para ver cómo se aplica este enfoque sobre Microsoft Fabric, con el modelo semántico como contrato y agentes gobernados desde el primer día, mira la demo gratuita.
Preguntas relacionadas
¿Un agente de datos reemplaza al modelo semántico en Fabric?
No. Un Fabric Data Agent no reemplaza el modelo semántico, lo hace consultable en lenguaje natural. El modelo sigue siendo el contrato que define medidas, dimensiones, relaciones, seguridad y vocabulario; el agente solo interpreta preguntas y ejecuta sobre fuentes aprobadas.
¿Qué instrucciones base debe tener un Fabric Data Agent?
Responder en el idioma del usuario, usar solo medidas y fuentes aprobadas, declarar período y filtros, no inventar KPIs, explicar límites de confianza, pedir aclaración si falta contexto y cerrar con la implicación de negocio.
¿Qué se debe validar antes de abrir un agente a la empresa?
Un conjunto de preguntas con valores esperados, los permisos por usuario, el consentimiento inicial y una prueba real desde el canal final. Compartir un Data Agent documenta el acceso y las pruebas con los consumidores.
¿Se pueden mezclar los canales de publicación de un Data Agent?
No conviene. Publicar en Microsoft 365 Copilot, conectar a Copilot Studio para Teams o exponer mediante clientes MCP son rutas distintas. Cada una requiere su propia guía operativa, permisos, pruebas y revisión de la documentación vigente.
¿En qué capa de la arquitectura se conecta la IA?
La IA se conecta al final de la cadena, sobre la capa Gold de la arquitectura medallion. El modelo semántico se construye sobre datos ya limpios y gobernados, y el agente consulta ese modelo, nunca datos crudos sin contrato.