... seguimos con el post de arquitectura con los Fabric Data Agent...
12. Probar el agente en Foundry
Antes de publicar nada, hay que probar. Desde el Área de Juegos de Foundry hacemos preguntas como:
- ¿Cuáles son las ventas totales?
- Dame las ventas por categoría.
- ¿Cuál es el top 10 de productos por ventas?
- Compara las ventas de este año frente al año anterior.
Y aquí debemos comprobar que el agente realmente está usando Fabric. ¿Cómo lo sabemos?
- Si responde con frases genéricas → mal.
- Si devuelve datos concretos del modelo → bien.
- Si aplica filtros, periodos y medidas correctamente → mejor.
La prueba buena no es que “conteste bonito”. La prueba buena es que conteste con datos correctos y sobre todo, los mismos valores que el agente creado en Fabric. Y esa distinción, que parece obvia, en el mundo de la IA se olvida más veces de las que uno se imagina.
13. El pequeño lío de las dos interfaces de Foundry
Aquí apareció una de esas partes que conviene contar, porque seguramente le pasará a más gente y así os ahorráis el susto.
En la interfaz anterior el agente funcionaba y devolvía consultas sin problemas. Pero al pasar a la interfaz nueva, donde aparece la opción de publicar en Teams, la conexión no aparecía de la misma forma. ¿¿¿What??? Sí, tal cual.
Y esto tiene sentido. La experiencia clásica y la nueva experiencia de Foundry pueden manejar agentes, conexiones y recursos de forma diferente. De hecho, en la documentación aparecen referencias diferenciadas entre la experiencia actual y la experiencia clásica de la herramienta de Microsoft Fabric para agentes de Foundry.
En la práctica, esto significa que una conexión que funciona en la interfaz antigua no siempre aparece automáticamente en la nueva experiencia. Y no, no es magia, es que son experiencias distintas y hay que darles cariño a las dos.
La solución fue clara:
- Crear o revisar la conexión desde la nueva experiencia de Foundry.
- Asegurarse de que está en el proyecto correcto.
- Añadirla explícitamente al agente.
- Guardar la versión del agente.
- Probar de nuevo.
No hay que asumir que porque algo funcione en la experiencia antigua, ya está listo para publicarse desde la nueva. Y este pequeño detalle me ahorró un par de horas de “pero si esto ya lo tenía hecho”… así que si os pasa, ya sabéis por dónde ir.
14. Tercera pieza: publicar el agente
Una vez que el agente funciona en Foundry, llega el momento de publicarlo.
En la nueva interfaz aparece la opción:
Publicar
Y dentro del proceso de publicación podemos preparar el agente para:
- Microsoft Teams
- Microsoft 365 Copilot
Microsoft nos documenta que los agentes de Foundry pueden publicarse en Microsoft 365 Copilot y Microsoft Teams para que los usuarios interactúen con ellos desde esas interfaces. Y aquí la idea ya cambia bastante.
Porque hasta ahora estábamos creando y probando un agente. Ahora estamos preparando una aplicación que Teams pueda usar. Que no es lo mismo.
Y Teams, para poder hablar con el agente, necesita una pieza adicional. Esa pieza es Azure Bot Service. Y aquí viene el momento de sorpresa que ahora contamos.
15. ¿Y por qué aparece ahora Azure Bot Service?
En la pantalla de publicación puede aparecer algo como:
Azure Bot Services No se encontraron servicios de bot
Y la primera reacción, honestamente, es:
¿¿¿Otro chatbot??? ¡Pero si ya tengo el mío en Foundry!
Tranquilos, que no cunda el pánico. La respuesta es NO. NO estamos creando otro chatbot. El chatbot sigue siendo el agente de Foundry. Lo que estamos creando aquí es el puente técnico que permite que Teams se comunique con ese agente. Nada más. Ni un chatbot nuevo, ni una IA distinta, ni un competidor de Foundry.
La arquitectura queda así:
Microsoft Teams à Azure Bot Service à Agent Application de Foundry à Agente de Foundry àFabric Data Agent à Modelo de datos
Cada capa a lo suyo:
- Azure Bot Service es la puerta de entrada desde Teams.
- Foundry sigue siendo donde vive la lógica del agente.
- Fabric sigue siendo donde viven los datos.
Microsoft nos indica que el proceso de publicación a Teams y Microsoft 365 Copilot requiere una suscripción de Azure en la que se puedan crear recursos de Azure Bot Service y aplicaciones en Microsoft Entra ID. También documenta que el proceso de publicación puede requerir el proveedor Microsoft.BotService. Todo esto conviene tenerlo apuntado por si necesitáis pedir permisos a IT.
Y aquí veríamos la pantalla donde aparece “No se encontraron servicios de bot”, para que os suene cuando os la encontréis.
16. Crear el Azure Bot Service
Desde la propia pantalla de Foundry aparece la opción:
Crear un Bot Service
Al pulsarla, se nos abre el portal de Azure para crear el recurso. Los campos principales son:
- Suscripción
- Grupo de recursos
- Nombre del bot
- Región
- Plan de precios
- Microsoft App ID
Para una prueba, lo normal es crear un recurso sencillo. Por ejemplo:
- Nombre: bot-agente-fabric-datos
- Grupo de recursos: Fabric
- Región: West Europe
Una vez creado el recurso, volvemos a Foundry y pulsamos el botón de refrescar en el selector de Azure Bot Services. Y entonces ya debería aparecer el bot recién creado. Lo seleccionamos y listo. Y aquí veríamos el recurso Azure Bot Service ya creado en Azure Portal, con toda su ficha de propiedades.
17. Rellenar los datos del agente para Teams
Después aparece otra parte importante: los metadatos del agente. Y ojo con esta parte, porque ya no tiene nada que ver con Fabric. Tiene que ver con la publicación de una app en Teams.
Teams necesita saber quién publica el agente, cuál es su web, cuáles son sus términos de uso y cuál es su política de privacidad. Es como cuando publicas una app en cualquier tienda: te piden esos datos para que el usuario final sepa con quién está hablando.
Los campos obligatorios son similares a estos:
- Nombre del desarrollador
- Sitio web
- Dirección URL de Términos y condiciones de uso
- URL de la Declaración de privacidad
Aquí hay que introducir URLs reales y válidas, preferiblemente con HTTPS. Por ejemplo:
- Nombre del desarrollador: Javier Sánchez Rivero
- Sitio web: https://losdatoscomoherramienta.blogspot.com
- Términos de uso: https://losdatoscomoherramienta.com/terminos-de-uso
- Política de privacidad: https://losdatoscomoherramienta.com/politica-de-privacidad
¿Y qué pasa hasta que se rellenan estos campos? Pues que el botón de preparación del agente aparece deshabilitado. Y ojo, esto NO es un error. Simplemente faltan datos requeridos para generar la aplicación que se va a publicar en Teams. Si no lo sabes, te puedes tirar diez minutos buscando qué es lo que está mal :)
Y aquí veríamos la sección de “Editar detalles del agente” con los campos obligatorios marcados y esperando a que los rellenemos.
18. Preparar el agente para la publicación
Una vez seleccionado el Azure Bot Service y completados los metadatos, se activa la opción:
Preparar agente
Este paso prepara la aplicación que después se podrá usar en Teams o Microsoft 365 Copilot. Y ojo, porque aquí ya no estamos tocando el modelo de datos ni la conexión con Fabric. Estamos empaquetando el agente para que pueda ser consumido desde Teams.
La diferencia es importante y creo que conviene resumirla:
- Fabric Data Agent → consulta datos
- Foundry Agent → orquesta la conversación
- Azure Bot Service → permite que Teams hable con el agente
- Teams → interfaz final del usuario
Cada pieza tiene su trabajo. Y una no puede hacer el trabajo de otra. Por eso todas son necesarias.
19. Publicar en Teams
Una vez preparado el agente, continuamos con la publicación. Dependiendo de la configuración del tenant, aquí pueden aparecer distintas opciones:
- Publicar solo para mí
- Publicar para la organización
- Enviar para aprobación del administrador
Para una prueba inicial, mi recomendación es siempre la misma: publicar solo para uno mismo. Así podemos validar que:
- El agente aparece en Teams.
- El chat se abre correctamente.
- El agente responde.
- La conexión con Fabric sigue funcionando.
- Los permisos del usuario son correctos.
Y sólo cuando todo esto esté OK, ya podemos pensar en publicarlo para más usuarios. Ir directo al “para toda la organización” en la primera prueba es tirarse a la piscina sin saber si tiene agua. Yo prefiero comprobar primero :)
Microsoft nos explica que el proceso permite publicar agentes en Teams y Microsoft 365 Copilot, y que puede requerirse aprobación o configuración administrativa dependiendo del alcance de la publicación. Es decir, para publicar “para toda la organización” muy probablemente te va a hacer falta que el admin de tenant apruebe la app. Tenedlo en cuenta.
20. Probar el agente desde Teams
Una vez publicado, vamos a Teams. Buscamos el agente en la zona de aplicaciones o desde la experiencia donde haya quedado publicado. Lo abrimos y empezamos con preguntas sencillas.
Por ejemplo:
- ¿Cuáles son las ventas totales?
- Dame las ventas por año.
- ¿Cuál es el top 10 de productos por ventas?
- ¿Qué categoría tiene mayor margen?
Y aquí no buscamos sólo que el agente responda. Buscamos confirmar que el flujo completo funciona:
Teams à Azure Bot Service à Foundry à Fabric Data Agent à Modelo de datos
Cuando la respuesta llega con datos reales del modelo… ¡Magia de la buena! Ya tenemos la cadena completa funcionando. Y aquí veríamos el agente respondiendo dentro de Microsoft Teams, con los datos reales del modelo apareciendo en el chat.
21. Permisos: el punto que no hay que olvidar
Este tipo de arquitectura tiene una parte muy bonita: respeta la seguridad. No es un “agente todopoderoso que ve todo”. Los permisos siguen mandando.
Pero eso también significa que los permisos importan. Y mucho. No basta con que el agente exista. El usuario que haga preguntas debe tener permisos adecuados en las distintas capas.
En términos prácticos:
- Debe poder usar el agente publicado.
- Debe tener acceso al Fabric Data Agent.
- Debe tener permisos sobre el origen de datos.
- Si el origen es un modelo semántico, debe tener permiso Build.
Microsoft nos indica que, para que el agente de Foundry pueda acceder al Fabric Data Agent, se requiere que el usuario tenga los permisos adecuados y que el Fabric Data Agent y el proyecto de Foundry estén en el mismo tenant. También se documenta que se copian los valores workspace_id y artifact_id desde la URL del Fabric Data Agent para establecer la conexión.
Y esto es importante porque puede ocurrir algo tan curioso como esto:
El agente abre en Teams… pero no puede responder con datos.
Y en ese caso el problema puede no ser Teams. Puede no ser Foundry. Puede ser simplemente un permiso en Fabric. Así que si os pasa, ya sabéis dónde mirar antes de volveros locos :)
Por ir terminando, este proceso deja varias lecciones interesantes, y me gustaría dejarlas por escrito porque creo que son útiles.
La primera es que no estamos creando un único objeto mágico. Estamos montando una cadena. Y esa cadena tiene varias piezas: datos, agente de datos, agente conversacional, conexión, Bot Service, Teams, permisos. Todas cuentan.
La segunda es que Foundry y Fabric se entienden, pero hay que darles bien las coordenadas. La conexión no aparece por arte de magia. Hay que decirle a Foundry:
- Este es mi workspace.
- Este es mi Fabric Data Agent.
- Esta es la conexión.
- Este agente debe usar esta conexión.
Cuatro cosas. Ni una menos.
La tercera es que Teams no habla directamente con Foundry. Teams necesita Azure Bot Service. Y Azure Bot Service NO es otro agente. Es el canal técnico para que Teams pueda conversar con el agente publicado. Esta idea es tan importante que la repito por tercera vez a lo largo del post :)
La cuarta es que las instrucciones importan. Un agente sin instrucciones claras puede responder desde conocimiento general. Un agente bien instruido sabe que, cuando se habla de ventas, clientes, productos o métricas, debe consultar Fabric. La diferencia entre un agente que “contesta” y uno que “ayuda de verdad” está muchas veces en las instrucciones.
Publicar un agente de Foundry en Teams conectado a Fabric no es difícil, pero tampoco es un botón mágico. Hay que entender qué papel juega cada componente.
El error habitual sería pensar: creo un agente y ya está.
Pero realmente el camino es:
- Primero preparo los datos.
- Después creo el agente de datos.
- Después conecto Foundry.
- Después valido el comportamiento.
- Después creo el canal de Teams.
- Después publico.
- Después pruebo con permisos reales.
Y aquí, para mí, está la parte más interesante. Estamos empezando a ver una forma muy potente de llevar los modelos de datos al lenguaje natural. No como una demo bonita. No como una respuesta inventada. Sino como una conversación conectada a un modelo semántico real, con medidas reales, permisos reales y usuarios reales.
Y eso cambia bastante el juego.
Porque el usuario ya no necesita saber dónde está la tabla, cómo se llama la medida o qué visual tiene que abrir. Puede preguntar. Y si detrás hay un buen modelo, un buen Fabric Data Agent y un buen agente de Foundry, la respuesta puede llegar directamente en Teams.
Eso sí: como siempre en datos, la calidad no empieza en la IA. Empieza en el modelo. Y esto es algo que no me canso de repetir, porque es donde se juegan de verdad los proyectos.
Y hasta aquí el post por hoy. Si habéis llegado hasta aquí, ya sabéis todo lo necesario para montar la cadena completa: Fabric → Fabric Data Agent → Foundry → Azure Bot Service → Teams. Ahora os toca a vosotros probarlo, romperlo, arreglarlo y sacarle jugo.
¡Nos vemos en los datos!
Y como premio por haber llegado hasta aquí... te dejo el link donde presenté los Fabric Data Agent acompañado por el equipo Timdel:
