Microsoft acaba de relanzar Hosted Agents en Foundry Agent Service, y el momento es importante. El 22 de abril de 2026, Microsoft reemplazó su preview de la era Ignite con una reconstrucción desde cero que incluye aislamiento de hipervisor por sesión, una identidad de agente Microsoft Entra dedicada para cada hosted agent y facturación real de escala a cero a $0.0994 por vCPU-hora. Para los equipos de TI empresarial que han estado aplazando despliegues de producción de agents de IA por preocupaciones de gobernanza, la historia de gobernanza acaba de mejorar sustancialmente.

Este informe cubre lo que se lanzó, lo que significa para sus decisiones de arquitectura Azure consulting y cinco acciones concretas para tomar en las próximas dos semanas.

Lo que Microsoft realmente lanzó

Las capacidades principales de la actualización del 22 de abril, según el anuncio oficial de Microsoft Foundry:

  • Aislamiento a nivel de hipervisor por sesión. Cada sesión lógica de agente obtiene su propio sandbox aislado en VM. Esto no es aislamiento de procesos ni de contenedores, es el mismo tipo de límite que separa las VMs de Azure entre sí.
  • Sistema de archivos persistente con escala a cero. El contenido de $HOME y /files sobrevive períodos de inactividad de hasta 30 días por sesión. El tiempo de espera de inactividad es de 15 minutos, después del cual se desaprovisiona la computación y se guarda el estado. La siguiente solicitud para el mismo ID de sesión inicia nueva computación en segundos con el estado restaurado.
  • Identidad de agente Microsoft Entra dedicada por agente. Se crea automáticamente en el momento del despliegue. Admite delegación On-Behalf-Of (OBO). Las asignaciones RBAC como Azure AI User se manejan automáticamente durante el despliegue.
  • Facturación real de escala a cero. Pague solo mientras la computación esté activa. $0.0994 por vCPU-hora más $0.0118 por GiB-hora. Tamaños de sandbox configurables de 0.25 a 2 vCPU y de 0.5 a 4 GiB.
  • Soporte multiprotocolo. Responses (compatible con OpenAI), Invocations (payloads personalizados flexibles), Activity (canales de Teams y M365) y A2A (agent-to-agent). Los cuatro protocolos se pueden combinar en un solo agente.
  • Versiones inmutables con división de tráfico. Las divisiones de tráfico ponderadas permiten despliegues blue-green y canary sin escribir enrutamiento personalizado.
  • Flexibilidad de frameworks. Microsoft Agent Framework v1.0, LangGraph, Semantic Kernel, CrewAI, LlamaIndex, Claude Agent SDK, OpenAI Agents SDK, GitHub Copilot SDK o código Python/C# simple: la plataforma es agnóstica en cuanto a framework.

Los anuncios complementarios también son importantes. Foundry Toolbox entró en preview pública el mismo día como un endpoint administrado compatible con MCP que agrupa Web Search, Code Interpreter, File Search, Azure AI Search, servidores MCP personalizados, herramientas OpenAPI y A2A. Foundry Memory proporciona memoria persistente administrada a $0.25 por 1,000 eventos, $0.25 por 1,000 memorias almacenadas por mes y $0.50 por 1,000 recuperaciones.

Conclusión empresarial: La actualización del 22 de abril cierra las tres brechas de gobernanza que han estado bloqueando el despliegue empresarial de agents: el aislamiento ahora está en el límite del hipervisor, la identidad es de primera clase y automática, y el costo finalmente es predecible a cero cuando está inactivo. Si su estrategia de arquitectura de IA ha estado estancada en modo POC, este es el punto de inflexión de la plataforma que vale la pena reconsiderar.

Por qué el aislamiento de hipervisor cambia el modelo de amenaza

El enfoque de Microsoft es deliberado: “cada sesión de agente [obtiene] su propio sandbox aislado en VM” en lugar de aislamiento compartido de procesos o contenedores. Para cargas de trabajo reguladas, la diferencia con los runtimes solo de contenedores es significativa:

  • Escapes de contenedores (vulnerabilidades clase runc): mitigados por el límite de VM como defensa en profundidad.
  • Ataques de canal lateral y ejecución especulativa entre inquilinos: el límite de VM es la mitigación generalmente aceptada.
  • Fugas de estado entre sesiones: prevenidas — cada sesión tiene su propio $HOME y /files.

Para equipos de servicios financieros, el límite de VM por sesión combinado con Entra Agent ID + OBO por usuario facilita sustancialmente la construcción de la narrativa de auditoría que los reguladores solicitan: “Esta transacción fue procesada por este agente en esta sesión con los derechos delegados de este usuario, dentro de una VM dedicada.”

Sin embargo, las salvedades son importantes. Microsoft no ha publicado cobertura de HIPAA Business Associate Agreement específicamente para Hosted Agents durante la preview. No hay región Azure Government. Solo cuatro regiones comerciales admiten Hosted Agents hoy: Australia East, Canada Central, North Central US y Sweden Central. Y el límite de VM no impide que un agente exfiltre datos a través de una herramienta MCP o conexión OpenAPI — todavía necesita controles de salida, DLP y filtrado de contenido.

Conclusión empresarial: El límite de hipervisor es una mejora genuina de cumplimiento, pero es el límite de la plataforma. Las llamadas a herramientas salientes de su agente aún necesitan la misma gobernanza de IA que aplicaría en cualquier otro lugar — controles de salida de red, listas blancas de herramientas y auditoría de flujo de datos.

Identidad de agente Entra: La historia de gobernanza

Dos identidades están involucradas en cada despliegue de hosted agent:

  1. Identidad Entra del agente (por agente) — la identidad de runtime con la que se autentica el contenedor. Se utiliza para invocación de modelos, acceso a herramientas y servicios de Azure downstream.
  2. Identidad administrada del proyecto (para todo el proyecto, asignada por el sistema) — utilizada por la plataforma para operaciones de infraestructura como la extracción de la imagen del contenedor desde Azure Container Registry.

Cuando despliega con Azure Developer CLI (azd), el rol Azure AI User en el ámbito de la cuenta se asigna automáticamente a la identidad Entra del agente. Para cualquier recurso externo que posea — Cosmos DB, Blob Storage, Key Vault — asigna RBAC manualmente.

Los problemas prácticos que vale la pena señalar porque afectan a todos los adoptantes tempranos:

  • Conditional Access aún se aplica a los flujos OBO. Políticas como “Todos los usuarios deben usar MFA” afectarán a los contextos de agente. Si un usuario tiene una política CA solo de dispositivos compatibles, el token OBO será rechazado porque el agente no puede cumplir con controles interactivos. Solución: cree políticas CA específicas para agents con controles que los agents puedan cumplir realmente (managed identity + ubicación nombrada) y excluya las identidades de agents de las políticas MFA dirigidas a usuarios.
  • OBO solo funciona para usuarios principales. Si su agente es llamado por otro servicio con un token solo de aplicación, OBO no es una opción — necesita un flujo separado de adquisición de tokens agente a agente.
  • Los permisos delegados no son implícitos. La identidad Entra del agente debe tener permisos delegados explícitamente concedidos para cada recurso downstream, con consentimiento del administrador del inquilino. Si falta esto, aparecerá AADSTS65001 en tiempo de ejecución, a menudo horas después de comenzar las pruebas.
  • Sorpresas en el ámbito RBAC. La plataforma asigna automáticamente Azure AI User en el ámbito de la cuenta. Si necesita acceso a un contenedor Blob para su agente, aún debe asignarlo manualmente en el ámbito del contenedor. Confusamente, el rol asignado por la plataforma no es visible en el portal de Entra a menos que acceda directamente al objeto de identidad del agente.

Conclusión empresarial: Antes de pilotar Hosted Agents, haga que su equipo de identidad audite las políticas de Conditional Access existentes para detectar cualquier cosa que bloquee los flujos OBO de agents. Reserve 1-2 semanas para que su equipo de administración de Entra defina políticas específicas para agents y las pruebe en un inquilino piloto. Si omite este paso, su primer despliegue en producción fallará en la autenticación.

Precios en números reales

El cálculo para tres cargas de trabajo realistas a las tarifas publicadas de $0.0994/vCPU-hora + $0.0118/GiB-hora:

  • Asistente empresarial de uso ligero (200 sesiones/día × 1 vCPU × 2 GiB × 5 min de sesión promedio): ~16.7 vCPU-horas/día + 33.3 GiB-horas/día. Computación mensual: ~$62.
  • Orquestación multi-agente pesada (50 sesiones concurrentes × 1 vCPU × 2 GiB × 10 horas activas/día): ~500 vCPU-horas/día + 1,000 GiB-horas/día. Computación mensual: ~$1,845.
  • Agente orientado al consumidor con picos (ráfaga promocional de 500 sesiones durante 2 horas + línea base cercana a cero): aproximadamente $1-5/día con costo real de inactividad en cero.

La comparación competitiva es importante. Vertex AI Agent Engine de Google tiene un precio de $0.0864 por vCPU-hora y $0.0105 por GiB-hora — aproximadamente 13% más barato en computación, 11% más barato en memoria. AWS Bedrock AgentCore está disponible de forma general desde octubre de 2025 con precios medidos por funcionalidad en los componentes Runtime, Gateway, Memory, Identity, Observability, Browser, Code Interpreter y Policy.

Microsoft está cobrando una prima modesta por la combinación de aislamiento de hipervisor por sesión, integración de identidad Entra de primera clase y publicación con un clic en Teams y M365. Para empresas que ya usan Microsoft, esa prima es fácil de justificar. Para aplicaciones de consumo nuevas sin presencia de identidad Microsoft, Vertex es la respuesta más económica.

Conclusión empresarial: Los tokens de modelo dominarán sus costos de agents por 10-100× independientemente de la plataforma de hosting. La diferencia en costo de computación entre Foundry, Vertex y Bedrock rara vez mueve la factura total más del 2-3%. Optimice para la plataforma que coincida con sus inversiones en identidad, cumplimiento y herramientas existentes en lugar de perseguir diferencias de precio por vCPU-hora.

Lo que se rompe: Límites de preview, problemas conocidos y la brecha de migración

A dos días calendario de la preview, el panorama operativo aún es limitado. Lo que ha surgido hasta ahora:

  • 50 sesiones concurrentes activas por suscripción por región. Ajustable mediante solicitud de soporte, pero el proceso de cuota en sí es nuevo y los plazos de entrega durante la preview no están documentados.
  • Solo Python y C#. Si su equipo escribe lógica de agente en TypeScript o Java, está esperando. Los SDK de administración admiten JS y Java; el runtime no.
  • Azure Container Registry debe ser accesible públicamente. ACR protegido por Private Link aún no es compatible. Microsoft ha reconocido públicamente esta carencia y se ha comprometido a solucionarla.
  • “Hosted Agents not enabled in this region” (issue #316 en el repositorio microsoft-foundry-for-vscode) — los usuarios que seleccionan regiones no compatibles reciben un error 400 sin orientación útil.
  • Dependencias de cuota de modelo. El despliegue de hosted agent puede fallar incluso con la infraestructura de agente aprobada si la cuota del modelo Azure OpenAI requerido es cero en la región objetivo. Verifique ambas antes de desplegar.
  • Las herramientas clásicas de agent han desaparecido. La herramienta Azure Functions, Connected Agents y Deep Research como herramientas clásicas no tienen equivalencia directa. Reemplazos: Workflow + A2A, modelo Deep Research con herramienta Web Search.

La mayor brecha de documentación es una guía de migración específica para hosted agents para clientes de la preview de la era Ignite. Microsoft ha publicado una guía sólida de migración de superficie de API (threads → conversations, runs → responses, create_agent → create_version) con una herramienta automatizada en aka.ms/agent/migrate/tool. Pero el cambio de backend de computación — reempaquetado de contenedores, adopción de las nuevas bibliotecas de protocolo Responses e Invocations, redespliegue a través de azd ai agent init / provision / deploy — aún no tiene documentación paso a paso dedicada. Se espera que llegue antes de Microsoft Build 2026 en mayo.

Conclusión empresarial: Si su organización ejecutó hosted agents en la preview de Ignite, planifique un ciclo de reimplementación de uno a dos sprints. La herramienta de migración de API maneja la mecánica del código, pero no los cambios de empaquetado de contenedores, selección de región o bibliotecas de protocolo. Esto no es una actualización continua — es una migración completa.

Dónde encajan Foundry Hosted Agents frente a alternativas

La propia guía de campo de Microsoft posiciona Hosted Agents como el punto óptimo entre la simplicidad de plataforma administrada y la flexibilidad de código personalizado. Aquí está el marco de decisión práctico para el stack de agents de Microsoft:

  • Copilot Studio — puerta de entrada para copilots orientados al negocio; orquestación low-code con gobernanza incorporada. Elija cuando los usuarios de negocio son dueños del ciclo de vida y la velocidad de prototipado domina.
  • Agents de Microsoft 365 Copilot — agents de usuario de negocio dentro de la experiencia M365 con integración profunda con Graph y Teams.
  • Agents declarativos (prompt) en Foundry (GA desde marzo de 2026) — agents impulsados por esquemas, sin código de runtime personalizado.
  • Foundry Hosted Agents (preview, actualizado el 22 de abril de 2026) — su código contenerizado, aislado por hipervisor, runtime administrado, agnóstico al framework.
  • Agents SDK in-process (Microsoft Agent Framework v1.0) — agents que se ejecutan dentro de su propio proceso, servicio o contenedor. Latencia más baja, control total del runtime, usted opera la infraestructura.
  • Azure Container Apps con sesiones dinámicas — cargas de trabajo generales de agents contenerizados con sandboxing de intérprete de código. Más control, menos herramientas nativas de agent.
  • Azure Kubernetes Service — federación multi-clúster, máxima flexibilidad de redes, mayor costo operativo. La respuesta correcta cuando necesita un service mesh o marco de cumplimiento más allá de lo que Foundry certifica actualmente.

Para la mayoría de los equipos de TI empresarial que despliegan IA agéntica para operaciones de TI en 2026, la lista corta realista es Foundry Hosted Agents (para tiempo rápido de producción con identidad y aislamiento integrados), agents SDK in-process ejecutándose en Windows 365 Cloud PCs o VMs dedicadas (para control total del runtime) y Copilot Studio (para flujos de trabajo propiedad de usuarios de negocio). Su criterio de decisión suele ser: ¿quién es dueño del ciclo de vida del agente y cuánto control del runtime necesita?

Conclusión empresarial: Hosted Agents reemplaza la opción de “construir un runtime administrado nosotros mismos en ACA o AKS” para la mayoría de los casos de uso empresarial. No reemplaza a los agents SDK in-process para trabajos sensibles a la latencia, y no reemplaza a Copilot Studio para flujos propiedad de usuarios de negocio. Adapte la herramienta al dueño del ciclo de vida.

Qué hacer esta semana

Cinco acciones concretas para líderes de TI basadas en el lanzamiento de esta semana:

  1. Audite sus hosted agents de la preview Ignite. Si ejecutó hosted agents en el backend de preview anterior al 22 de abril, inventaríelos y planifique un sprint de migración. El backend antiguo se está retirando. No espere a la guía de migración para hacer el trabajo de inventario.
  2. Ejecute un piloto autorizado de Hosted Agents. Elija un flujo de trabajo de operaciones de TI bien definido — triaje de logs, auditoría de configuración, detección de desviación de políticas de Intune — y despliéguelo en North Central US o Canada Central con un sandbox de 1 vCPU / 2 GiB. La escala a cero significa que el costo de su piloto es efectivamente cero cuando está inactivo.
  3. Informe a su equipo de identidad. Haga que su administrador de Entra revise las políticas de Conditional Access existentes para detectar cualquier cosa que bloquee los flujos OBO de agents y redacte políticas CA específicas para agents utilizando controles de managed-identity + ubicación nombrada. Este es el bloqueante de producción más común.
  4. Decida su lealtad de framework. Microsoft Agent Framework v1.0 alcanzó disponibilidad general el 2 de abril de 2026. Si su equipo todavía está en Semantic Kernel o AutoGen, migre a Agent Framework ahora — las bases de código de SK y AutoGen están en modo de mantenimiento a largo plazo. Si ya está en LangGraph o CrewAI, Hosted Agents los admite de forma nativa; no se requiere migración.
  5. Actualice su matriz de comparación de proveedores. Actualice su matriz de plataforma de IA con las capacidades del 22 de abril: aislamiento de hipervisor, precio de $0.0994/vCPU-hora, límite de preview de 50 sesiones, disponibilidad en cuatro regiones. Utilice esto para reevaluar cualquier decisión de estrategia multi-cloud de agents que haya tomado antes del segundo trimestre de 2026.

La historia de gobernanza finalmente coincide con la historia de marketing en Hosted Agents. Para las organizaciones que han estado esperando que la identidad, el aislamiento y la auditabilidad alcancen nivel empresarial antes del despliegue en producción, la espera ha terminado en gran medida. Las brechas restantes — documentación de migración, ACR de red privada, lenguajes adicionales, cobertura regional más amplia — todas tienen señales activas en el roadmap de Microsoft y probablemente se resuelvan antes de la disponibilidad general.

Si su organización necesita ayuda para evaluar Microsoft Foundry Hosted Agents para una carga de trabajo de producción — incluyendo arquitectura de identidad, diseño de Conditional Access para flujos OBO de agents, migración desde la preview Ignite o selección de plataforma entre Foundry, Azure Container Apps y agents SDK in-process — Big Hat Group se especializa en consultoría de IA empresarial que conecta lo que Microsoft lanza con lo que su organización realmente necesita para operar de forma segura a escala. Contáctenos para definir el alcance de un piloto.

Kevin Kaminski es Arquitecto Principal en Big Hat Group, donde ayuda a empresas a desplegar soluciones de Azure AI, Windows 365 y Microsoft Intune que funcionan en el mundo real. Conéctese con Big Hat Group para consultoría Azure, consultoría Windows 365 y consultoría de agents de IA.