Agentes de IA en Microsoft 365: de la demo a la producción

📋 En resumen

Para quién: CIOs, arquitectos de Microsoft 365 y responsables de gobernanza de IA que ya han pilotado agentes y necesitan decidir qué falta antes de producción
Tiempo de lectura: ~8 minutos
Qué vas a sacar: los cinco controles que separan un piloto de un agente de IA en producción en Copilot Studio y Azure AI Foundry, con la Ley de IA de la UE ya aplicable

Un agente que responde bien en la demo y uno que aguanta tres meses en producción casi nunca son el mismo sistema, aunque compartan el mismo prompt. La demo funciona una vez, delante de un usuario amable, en un buen día. La producción tiene que aguantar la petición número diez mil, con un usuario hostil, a las tres de la madrugada, cuando la API de la que depende está caída.

Desde el 2 de agosto de 2026 hay una razón añadida para tomarse esa diferencia en serio: la Ley de IA de la UE ya es aplicable a los sistemas de alto riesgo, y un agente que actúa sobre datos de clientes o decisiones de negocio entra en ese perímetro casi sin que nadie lo haya decidido. La pregunta ya no es solo "¿funciona?": es "¿puedes demostrar que funciona, quién lo autorizó y qué hizo?".

Lo que separa un piloto de un sistema real no es más inteligencia del modelo. Es la parte aburrida que la demo te dejó saltarte: alcance acotado, datos con permisos respetados, identidad propia, medición objetiva y trazabilidad. Copilot Studio y Azure AI Foundry Agent Service ya traen las piezas para las cinco. El trabajo no es construirlas desde cero — es no publicar sin haberlas activado.

¿Por qué la mayoría de los agentes de IA se quedan atascados entre el piloto y la producción?

Se quedan atascados porque el piloto se optimiza para lo contrario de lo que exige la producción. Una demo premia la capacidad abierta y el camino feliz; un sistema en producción premia el comportamiento acotado, el fallo previsible y la posibilidad de auditar cada paso — nada de eso se ve en una grabación de pantalla, así que nadie lo construye a tiempo.

Es un patrón que se repite con cada cliente que evalúa su primer agente serio: el piloto convence en el comité, alguien da luz verde, y el prototipo se promociona con el mismo esqueleto con el que nació. Falla de forma embarazosa en vez de instructiva, y el proyecto pierde un año de confianza que había costado meses ganar.

¿Cómo se acota el alcance de un agente para que sea fiable?

Un agente sin límites claros no es más útil: es imposible de evaluar, porque "responder cualquier cosa" no tiene criterio de aceptación. El primer control es escribir, en tres frases que firmaría alguien sin perfil técnico, qué hace el agente y qué se niega a hacer. En Foundry ese alcance se expresa en las instrucciones, en su catálogo de herramientas y en las barreras sobre qué puede ejecutar; en Copilot Studio son los temas, los asuntos prohibidos y el comportamiento ante intención desconocida. Microsoft es explícita en que los modelos experimentales no son para producción — conviene elegir el modelo principal deliberadamente, no por inercia.

¿Cómo se garantiza que el agente solo ve los datos que el usuario podría ver?

Un agente sin este control es un problema de fuga de datos con interfaz conversacional: la pregunta no es solo si la respuesta está bien fundamentada, sino si esa fuente respeta los permisos de quien pregunta. Foundry fundamenta las respuestas mediante herramientas de conocimiento — búsqueda de archivos sobre Azure AI Search, SharePoint, Fabric y Blob — y Copilot Studio hace lo mismo contra fuentes que el usuario ya podría abrir. Aquí fallan muchos pilotos "exitosos": durante la prueba un único administrador lanzaba todas las consultas, así que cualquier documento era juego limpio. En producción, mil usuarios con mil ámbitos de permiso la ponen a prueba, y la pregunta pasa de "¿está bien fundamentada?" a "¿fundamentada en los datos de quién?". Por eso la higiene documental en SharePoint es un requisito previo, no un carril paralelo — lo desarrollé en el blueprint de preparación de datos para IA.

¿Necesita el agente su propia identidad, o puede actuar con la mía?

En una demo, el agente actúa como tú. En producción, eso es un incidente de seguridad esperando a ocurrir: un agente que ejecuta acciones necesita un responsable identificable detrás de cada una, y ese responsable no puede ser una credencial prestada. Foundry Agent Service da a cada agente un Microsoft Entra Agent ID propio — acceso acotado y de mínimo privilegio, sin compartir credenciales — combinado con RBAC y redes privadas que lo mantienen dentro de tu red virtual por residencia de datos. Es el eje del checklist de gobernanza de agentes de Microsoft 365 que uso en despliegue: si no puedes responder bajo qué identidad actuó y qué tenía permitido tocar, no estás listo para producción.

¿Cómo se mide la calidad de un agente antes de publicarlo?

No se gestiona lo que no se mide, y un sistema no determinista no se publica a ojo. Hace falta un arnés de evaluación: puntuar el comportamiento contra un conjunto de pruebas, fijar una base y un umbral que debe superar. Foundry incluye evaluadores de agentes que funcionan como pruebas unitarias — devuelven aprobado o suspenso según si completó la tarea y si usó las herramientas correctas con eficiencia. El SDK de evaluación de Azure AI permite fijar un umbral explícito antes de publicar y conectarlo como puerta de calidad en CI/CD vía GitHub Actions, de modo que una regresión bloquee el despliegue en vez de llegar al usuario final.

¿Qué pasa cuando el agente falla y nadie sabe explicar por qué?

Es el control que más se pospone, hasta el primer incidente serio, cuando se descubre que no hay forma de saber qué hizo realmente el agente. Un sistema no determinista no se depura leyendo el código, porque el código no decidió el comportamiento: lo decidió el modelo, en tiempo de ejecución, con entradas que nadie vio. Hacen falta trazas.

Foundry guarda las trazas en Application Insights con las convenciones de OpenTelemetry; el rastreo del lado servidor se activa solo al conectar el recurso, sin cambios de código, con trazas visibles en minutos. Encima, la evaluación continua muestrea interacciones reales y las puntúa por calidad y seguridad casi en tiempo real, así que la degradación aparece en un panel y no en una reclamación de cliente. La prueba de este control: si el agente falla esta mañana, ¿puedes recuperar esa conversación exacta y explicar el fallo antes de comer? Si la respuesta es "habría que suponerlo", tienes una demo en producción, no un sistema en producción.

Piloto frente a producción, en una tabla

¿Copilot Studio o Azure AI Foundry para pasar estos controles?

Los dos cubren los cinco controles, pero los expresan distinto. Copilot Studio abstrae más —moderación, fundamentación e identidad más resueltos de fábrica— y encaja con agentes de negocio. Foundry Agent Service da control más fino sobre modelos, herramientas, evaluación y redes, para ingeniería con requisitos más estrictos. En despliegues reales es habitual usar ambos a la vez, cada uno donde rinde mejor; lo desarrollo en la comparativa entre Copilot Studio y Foundry.

Lo que de verdad predice si un agente llega a producción

La opinión que defiendo en cualquier llamada con un director de TI: la señal que más importa no es lo inteligente que es el agente, sino cuánto de lo que necesita ya está desplegado y gobernado en el tenant. Un agente que reutiliza identidad, datos y monitorización existentes es una victoria rápida; uno que necesita las cinco cosas desde cero no es un proyecto de una semana, es un programa, y hay que presupuestarlo como tal. Lo he visto invertir conversaciones enteras: el cliente llega convencido de que la decisión difícil es elegir la mejor tecnología, y al puntuar el caso de uso real contra lo que ya existe, "qué plataforma" se convierte en "qué reutilizar". Reutilizar es la ventaja silenciosa que decide más despliegues que cualquier comparativa de modelos.

Preguntas frecuentes

¿Cuánto debería tardar el paso de piloto a producción?

Menos que el propio piloto si reutilizas identidad, datos y monitorización ya desplegados; un programa completo si hay que construirlos desde cero. Los cinco controles anteriores lo revelan pronto, para presupuestar con honestidad antes de prometer una fecha.

¿Hace falta Azure AI Foundry, o basta con Copilot Studio?

Los dos cubren los cinco controles con distinto nivel de abstracción: Copilot Studio resuelve más de fábrica y encaja con agentes de negocio; Foundry da control fino para requisitos de ingeniería más estrictos. Muchas organizaciones usan ambos en paralelo.

¿Es obligatoria la evaluación automática para un agente interno sencillo?

Sí, en proporción a su riesgo: uno sencillo necesita un conjunto de pruebas pequeño y un umbral claro; uno complejo, evaluación continua sobre tráfico real. Ninguno puede saltarse una medida objetiva de calidad, porque "en las pruebas parecía correcto" no es defendible cuando algo se degrada.

¿Esto sustituye la gestión de ciclo de vida de aplicaciones que ya tenemos?

No, la extiende. Entornos, pipelines y soluciones gestionadas siguen aplicando igual que en cualquier despliegue de Power Platform; los cinco controles añaden lo propio del agente —fundamentación, identidad, evaluación no determinista, trazas— encima de la disciplina de ALM que ya deberías tener.

La conclusión

La distancia entre un piloto y un sistema en producción no es capacidad del modelo: es fiabilidad, construida con piezas poco vistosas —alcance acotado, datos que respetan permisos, identidad gobernada, evaluación objetiva, trazabilidad real. Microsoft ya pone herramientas de primer nivel para las cinco; el trabajo del equipo es no publicar un agente antes de haberlas activado todas. Pasa tu agente actual por estos cinco controles con honestidad: el que falle es el trabajo que estabas a punto de saltarte.