IA en producción con Microsoft Foundry: una configuración de referencia privada para agentes

La mayoría de los pilotos de IA en Azure empiezan con una clave copiada en una app y un endpoint de modelo abierto a internet. Sirve para una demo y suspende la primera revisión de seguridad. Esta es la configuración que uso cuando un agente tiene que salir a producción en Microsoft Foundry: Entra ID en lugar de claves, todo detrás de endpoints privados, guardrails en cada paso del agente, evaluaciones antes de cada release y trazas en Application Insights. Cada afirmación enlaza con las páginas oficiales de Microsoft para que puedas comprobarla.

Dominik Heinrich

7 de noviembre de 202611 min de lectura

1. Cuándo Azure es el lugar adecuado para tu IA y qué ha cambiado en los nombres

Azure es la opción natural cuando tu empresa ya vive en Microsoft: identidades en Entra ID, documentos en SharePoint, personas en Teams y cargas en suscripciones de Azure con landing zones y políticas. Así tu plataforma de IA hereda el gobierno que ya tienes en lugar de construir uno nuevo. La oferta de modelos es amplia: Microsoft describe acceso a más de 10.000 modelos de Microsoft, OpenAI, Anthropic, Meta y otros en el catálogo de Foundry Models.

Los nombres han cambiado dos veces, y eso confunde muchos resultados de búsqueda. La propia página de Microsoft muestra la historia: Azure AI Studio, después Azure AI Foundry y ahora Microsoft Foundry. También cambió la API de agentes. La misma página relaciona la antigua Assistants API (Agents v0.5/v1) con la Responses API (Agents v2), y los antiguos términos threads, messages y runs con conversations, items y responses. Si un tutorial todavía crea threads y runs, describe la experiencia clásica.

En el resto del artículo sigo la documentación actual de Microsoft Learn sobre Foundry y la arquitectura de referencia baseline de chat con Microsoft Foundry del Azure Architecture Center, el plano oficial más cercano a un agente empresarial.

2. Recurso, proyecto e identidad: ninguna clave en tu código

Foundry tiene dos niveles: un recurso de Foundry, que contiene red, políticas y despliegues de modelos, y dentro proyectos, donde los equipos construyen agentes. Crea el recurso con una identidad administrada asignada por el sistema y con la gestión de proyectos activada. El quickstart de Microsoft deja claro que la creación del proyecto falla sin la identidad administrada y que la Azure CLI necesita la versión 2.80.0 o superior para los comandos de proyecto.

Desde el primer día, que las aplicaciones se autentiquen con Microsoft Entra ID: la web app usa su identidad administrada, las personas reciben roles mediante grupos y nadie copia una clave de API en un archivo de configuración. La arquitectura baseline hace exactamente eso: la aplicación web llama al agente por un endpoint privado y se autentica en Foundry con su identidad administrada. Las claves son la excepción para herramientas que no admiten Entra ID, y entonces van a Key Vault con rotación, no al código.

Mantén al menos dos proyectos, mejor dos recursos en suscripciones separadas, para no producción y producción. Los despliegues de modelos, las cuotas y los guardrails son distintos, y quieres probar un cambio antes de que lo vean tus clientes.

bash

# Azure CLI 2.80.0+ (project commands). Names are examples.
az group create --name my-foundry-rg --location eastus

# Foundry resource with a managed identity and project management
az cognitiveservices account create \
  --name my-foundry-resource \
  --resource-group my-foundry-rg \
  --kind AIServices \
  --sku S0 \
  --location eastus \
  --custom-domain my-foundry-resource \
  --assign-identity \
  --allow-project-management true

# A project for the team that builds the agent
az cognitiveservices account project create \
  --name my-foundry-resource \
  --resource-group my-foundry-rg \
  --project-name my-foundry-project \
  --location eastus

Consejo práctico

Si la creación del proyecto falla con un mensaje de que debe activarse una identidad administrada, el recurso se creó sin --assign-identity. Corrígelo ahí en lugar de recurrir a claves.

3. Privado por defecto: la configuración estándar de agentes en tu propia red

Foundry Agent Service ofrece una configuración estándar con red privada. En ella aportas tu propia red virtual y tus propios recursos de Azure para guardar el estado del chat y del agente: Azure Storage para archivos, Azure Cosmos DB para conversaciones y Azure AI Search para datos vectoriales. Todos quedan detrás de endpoints privados y el acceso público al recurso de Foundry se desactiva. La arquitectura de referencia baseline añade los bordes: los usuarios entran por Azure Application Gateway con firewall de aplicaciones web, la interfaz de chat corre en App Service en tres zonas de disponibilidad y el tráfico saliente de los agentes pasa estrictamente por Azure Firewall, que aplica reglas de salida.

Ese último punto importa más de lo que parece. Un agente con búsqueda web o una conexión MCP es software que hace llamadas salientes en nombre de un prompt. Con una lista explícita de destinos permitidos en el firewall, una inyección de prompt no puede enviar datos en silencio a cualquier host.

Planifica subredes y zonas DNS privadas antes de crear nada. La arquitectura usa subredes separadas para la integración de App Service, los endpoints privados, la integración del agente, Azure Bastion, los agentes de build y el firewall. Añadir red privada a posteriori a un entorno de agentes en marcha es mucho más difícil que empezar con ella.

Consejo práctico

Empieza con la implementación de referencia de Foundry Agent Service enlazada desde la arquitectura baseline. Despliega la red, los endpoints privados y el firewall con infraestructura como código y te ahorra días de depuración de DNS.

Configuración de referencia en Microsoft Foundry, basada en la arquitectura baseline de chat con Foundry del Azure Architecture Center: todo privado, salida por el firewall y observabilidad en Application Insights.

4. Elegir y desplegar el modelo: estándar, batch, prioridad o aprovisionado

Elige el modelo por la tarea, no por el titular: uno pequeño y rápido para enrutar y extraer, uno más potente para respuestas que exigen razonamiento y un modelo de embeddings para la búsqueda. Después, el tipo de despliegue. Microsoft compara cuatro: los despliegues estándar comparten capacidad entre clientes, así que el rendimiento puede variar con la demanda; batch encaja con trabajos grandes sin conexión; priority processing compra menor latencia; y provisioned throughput reserva una capacidad fija solo para tu despliegue, lleguen peticiones o no.

Esa última frase es a la vez la trampa de costes y la ventaja. Provisioned throughput da latencia predecible para una carga intensa y constante, pero también pagas a las tres de la madrugada. Empieza con un despliegue estándar, mide tokens por minuto y latencia durante unas semanas y solo entonces decide si la carga base constante justifica capacidad aprovisionada.

Antes de desplegar, consulta qué versiones de modelo y SKU ofrece realmente tu región. El quickstart muestra un comando para ello, y un despliegue falla con DeploymentModelNotSupported si la combinación no existe en tu región.

bash

# Which versions and SKUs of a model exist in your region?
az cognitiveservices model list \
  --location eastus \
  --query "[?model.name=='gpt-5-mini'].{version:model.version,skus:join(',',model.skus[].name)}" \
  --output table

# Standard (shared capacity) deployment to start with
az cognitiveservices account deployment create \
  --name my-foundry-resource \
  --resource-group my-foundry-rg \
  --deployment-name gpt-5-mini \
  --model-name gpt-5-mini \
  --model-version "2025-08-07" \
  --model-format OpenAI \
  --sku-capacity 10 \
  --sku-name GlobalStandard

5. Construir el agente: prompt agent, hosted agent y una caja de herramientas curada

Foundry Agent Service te acompaña en cualquier punto entre lo declarativo y el código completo. Un prompt agent se define con instrucciones, un modelo y herramientas, y Foundry lo ejecuta. Un hosted agent empaqueta tu propio código, por ejemplo un framework que ya usas, y Foundry lo aloja y escala. O llamas a la Responses API desde un agente que ejecutas en otro sitio. El runtime de agentes gestiona conversaciones, llamadas a herramientas y el ciclo de vida del agente.

Las herramientas son lo que hace útiles a los agentes y también lo que los hace arriesgados. Las toolboxes de Foundry te permiten curar una vez un conjunto de herramientas, como búsqueda web, búsqueda en archivos, intérprete de código, servidores MCP y funciones propias, y compartirlas entre agentes. Trata una toolbox como una API que publicas: cada herramienta tiene un responsable, una descripción clara, acceso de mínimo privilegio y una prueba. Para responder con tus propios documentos, la arquitectura baseline conecta el agente con Azure AI Search por un endpoint privado, así que la recuperación se queda dentro de tu red.

Empieza con un prompt agent y dos o tres herramientas. La mayor parte del valor de una primera versión viene de buenas instrucciones y una recuperación fiable, no de una lista larga de herramientas. Añade herramientas solo cuando una evaluación muestre que el agente las necesita.

Foundry Agent Service + Microsoft Agent Framework Explained, Microsoft Mechanics (YouTube). Se carga desde YouTube solo cuando haces clic.

6. Guardrails en cada paso, no solo en la caja de chat

El filtrado clásico de contenido mira dos sitios: lo que escribe el usuario y lo que responde el modelo. Los agentes tienen dos más. Los guardrails de Microsoft Foundry son colecciones con nombre de controles, y cada control define un riesgo, los puntos de intervención que revisa y la acción a tomar. Se admiten cuatro puntos de intervención: entrada del usuario, llamada a herramienta, respuesta de herramienta y salida. Llamada y respuesta de herramienta son solo para agentes y están en preview, igual que los guardrails de agentes en general.

La respuesta de herramienta es el punto que la mayoría de los equipos olvida. La inyección indirecta de prompts llega por contenido que el agente lee, como una página web o un documento, no por el usuario. Revisar las respuestas de herramientas es la forma de detectar instrucciones escondidas en ese contenido antes de que el modelo actúe. La lista de controles incluye también material protegido, datos personales y task adherence en preview, para marcar a un agente que se aparta de su tarea.

Una fecha a tener en cuenta: Microsoft anuncia que la detección de groundedness (preview) en Azure OpenAI se retira el 30 de abril de 2027. Si dependes de ella, planifica ya el sustituto y comprueba la fundamentación también con evaluaciones.

Consejo práctico

Mantén un pequeño archivo de prompts de ataque de tu dominio, incluidas instrucciones escondidas en un documento que el agente recupera, y ejecútalo con cada cambio de guardrails. Un guardrail sin probar es una suposición.

7. Evaluar antes de cada release: calidad, seguridad y comportamiento del agente

Un agente cambia de comportamiento cada vez que editas una instrucción, cambias la versión del modelo o añades una herramienta. Sin evaluaciones, te enteras por los clientes. Los evaluadores de Foundry cubren calidad general, métricas específicas de recuperación como groundedness y relevance, seguridad y métricas específicas de agentes. Estas últimas son las interesantes: task adherence comprueba si las acciones del agente siguen sus reglas y restricciones de política, intent resolution si entendió lo que quería el usuario, y tool call accuracy si hizo las llamadas correctas con los parámetros correctos.

Construye un conjunto de pruebas de 50 a 200 preguntas reales con resultados esperados, incluidas las incómodas de los tickets de soporte. Ejecútalo en tu pipeline con cada cambio de instrucciones, herramientas o versión de modelo y bloquea la release si una puntuación cae por debajo de la última ejecución aceptada. Puedes añadir evaluadores propios para reglas de tu dominio, por ejemplo que una respuesta sobre un contrato cite siempre la cláusula.

Microsoft describe además un agent optimizer (preview) que evalúa el comportamiento del agente y sugiere mejores instrucciones, descripciones de herramientas y modelos. Trata esas sugerencias como un pull request que aun así debe pasar tu evaluación, nunca como un cambio automático en producción.

8. Observar y controlar costes en producción, y luego comparar las nubes

El trazado de Foundry se basa en OpenTelemetry y está integrado con Azure Monitor Application Insights. Una traza muestra el flujo de una petición: llamadas al modelo, invocaciones de herramientas y decisiones del agente, justo lo que necesitas cuando un agente dio una respuesta extraña el martes. Además, Microsoft describe paneles de producción para consumo de tokens, latencia, tasas de error y puntuaciones de calidad, con alertas cuando las salidas no alcanzan los umbrales de calidad o generan contenido dañino.

El control de costes es sobre todo disciplina: un presupuesto con alertas de previsión en la suscripción, consumo de tokens por agente y por proyecto en los paneles, el modelo más pequeño que pase tu evaluación en cada paso y una revisión periódica de si una carga constante ha crecido lo bastante para provisioned throughput. Repasa la guía Azure Well-Architected para cargas de IA una vez antes de salir a producción y luego cada trimestre.

Los fallos que más veo: claves en la configuración de la app, acceso público que sigue activo tras el piloto, ningún control de salida para agentes con herramientas, evaluaciones hechas una vez a mano en lugar de en el pipeline y una versión de modelo actualizada sin avisar. Cómo queda la misma configuración en AWS está en /blog/aws-bedrock, y en Google Cloud en /blog/google-vertex-ai. Las piezas son parecidas; cambian los nombres, el modelo de red y las herramientas de gobierno.

Consejo práctico

Fija las versiones de modelo en producción y actualízalas como cualquier otra dependencia: primero en no producción, pasando la puerta de evaluación y con un plan de vuelta atrás.

Conclusión
En Azure, un agente en producción es sobre todo la plataforma que ya operas: Entra ID, endpoints privados, un firewall y Application Insights, con los guardrails y evaluaciones de Foundry como puertas que cada cambio debe pasar.

Proyectos reales relacionados

Pruébalo tú mismo

Listo para producción

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos