Microsoft Foundry: qué es y en qué cambia frente a Azure AI Foundry

📋 Referencia rápida

Para quién: responsables de TI, arquitectos y partners que oyen "Microsoft Foundry" y necesitan saber si les afecta
Tiempo de lectura: ~7 minutos
Qué vas a sacar: qué es Microsoft Foundry, qué cambió respecto a Azure AI Foundry, cómo se organiza el recurso, y las dos decisiones concretas que tiene que tomar una empresa en España antes de desplegar

Microsoft Foundry es el nombre actual de lo que hasta hace poco se llamaba Azure AI Foundry, y antes Azure AI Studio. No es solo un cambio de marca: por debajo hay un modelo de recursos distinto, una API de agentes distinta y un límite de gobierno distinto. Si tienes cargas de IA en Azure, esto te afecta; si estás empezando ahora, te ahorra un problema que muchos ya tienen.

Empiezo por la parte que suele faltar en los resúmenes: qué es exactamente y dónde encaja.

¿Qué es Microsoft Foundry?

Microsoft Foundry es la plataforma de Azure que reúne agentes, modelos y herramientas bajo una única agrupación de administración, con trazabilidad, supervisión y evaluaciones incorporadas. Todo se gestiona con un control de acceso basado en roles, una configuración de red y unas políticas unificadas, dentro de un mismo espacio de nombres de proveedor de recursos de Azure.

Traducido a lo que importa en una reunión de arquitectura: antes tenías un hub, más un recurso de Azure OpenAI, más los servicios de Azure AI, cada uno con su gobierno. Ahora tienes un recurso donde se configura la seguridad, y proyectos dentro de él donde trabajan los equipos.

¿En qué se diferencia de Azure AI Foundry?

En cinco cosas concretas, no solo en el nombre. Microsoft publica la equivalencia sin rodeos:

• Marca: Azure AI Studio → Azure AI Foundry → Microsoft Foundry. Y los servicios de Azure AI pasan a llamarse Foundry Tools.
• Modelo de recursos: de hub + Azure OpenAI + Azure AI Services a un único recurso de Foundry con proyectos dentro.
• API de agentes: la API de Assistants da paso a la API de Responses (agentes v2).
• Versionado: de parámetros api-version mensuales a rutas estables v1 bajo /openai/v1/.
• Terminología: lo que eran threads, messages, runs y assistants ahora son conversaciones, elementos, respuestas y versiones de agente.

Los proyectos basados en hub siguen funcionando en el portal Foundry (clásico), y algunos casos de uso —como el despliegue de modelos de código abierto— todavía requieren un hub. Pero la inversión nueva va al modelo nuevo, así que trátalo como un plazo blando sin fecha: nada te obliga a moverte hasta que quieras una capacidad que solo existe allí.

¿Cómo se organiza el recurso de Foundry?

En tres niveles, más una categoría que casi todos los diagramas dibujan mal. La documentación de arquitectura lo describe así:

Arriba, el recurso de Foundry: el recurso de Azure donde se gestionan red, seguridad y despliegues de modelo. Dentro, los proyectos: el límite de desarrollo donde cada equipo construye y evalúa su caso de uso reutilizando los despliegues y las conexiones que ya existen, sin volver a pedirle nada a TI. Y dentro de los proyectos, los activos: archivos, agentes, evaluaciones y trazas.

La categoría que se dibuja mal es la de recursos conectados: Storage, Key Vault y Azure AI Search se referencian mediante conexiones, pero son recursos de Azure independientes, con su propio límite de gobierno. Su red, sus políticas de acceso y su cumplimiento se gestionan por separado.

Dicho de otro modo: "está en Foundry" no dice nada sobre dónde viven tus documentos. Yo pinto esos recursos en otro color en el diagrama y les pongo un responsable con nombre y apellidos, porque es exactamente la pregunta que hace el equipo de seguridad en la tercera reunión.

¿Tengo que migrar mi recurso de Azure OpenAI?

Puedes, y sin dolor: la actualización de un recurso de Azure OpenAI a un recurso de Foundry conserva el endpoint, las claves de API y el estado existente. No hay que desplegar clientes nuevos ni rotar claves. Además, al compartir espacio de nombres de proveedor, tus políticas de Azure y tus asignaciones de RBAC personalizadas siguen aplicando.

¿Deberías? La respuesta de Microsoft es menos maximalista de lo que cabría esperar: si tu carga solo necesita completions de Azure OpenAI, sin hospedaje de agentes ni evaluaciones, un recurso independiente de Azure OpenAI puede ser suficiente. Y si tu equipo de seguridad no ha habilitado el conjunto completo de capacidades de Foundry en tu entorno, puede que necesites el recurso independiente.

Así que la decisión es por carga de trabajo, no por todo el estado a la vez. Hospedar agentes, ejecutar evaluaciones o aislar varios equipos en proyectos son motivos. "Que todo esté en lo último" no lo es.

¿Qué tiene que decidir una empresa en España antes de desplegar?

Dos cosas, y la segunda casi nunca aparece en la conversación hasta que es tarde.

Primera: la región, con los ojos abiertos. España tiene región propia de Azure —Spain Central, ubicada físicamente en Madrid y con zonas de disponibilidad—, lo cual resuelve la conversación de residencia de datos con cualquier comité. Pero conviene mirar la lista de regiones antes de firmar el diseño: Spain Central es una región sin región emparejada. No hay pareja de recuperación automática asignada por Microsoft.

Eso no la hace peor. La hace tuya. Significa que la recuperación ante desastres es una decisión de arquitectura explícita que tienes que tomar y documentar, no algo que heredas del catálogo. Es la clase de detalle que se descubre durante una auditoría de continuidad en vez de durante el diseño, y ahí ya cuesta caro. Añade a la comprobación la disponibilidad concreta de cada servicio que vas a usar en esa región: la región existe, pero no todos los servicios ni todos los niveles están en todas partes.

Segunda: el gobierno antes que el portal. El plano de control de Foundry aplica identidad de Microsoft Entra, RBAC, filtros de contenido, aislamiento de red y Azure Policy a nivel de recurso, con los proyectos como límite de desarrollo por debajo. Configura eso antes de crear el primer proyecto, incluida la configuración de Private Link. Para despliegues grandes, Microsoft mantiene una guía de implantación específica.

El orden importa porque es el único momento en que es gratis. Después, cada proyecto creado sin control de red es una migración pequeña que nadie prioriza.

Una comprobación de quince minutos que casi nadie hace

Antes de cualquier plan: mira la fecha de retirada de cada modelo que tengas desplegado, en el catálogo de modelos de Foundry.

Lo digo porque me lo he encontrado. En una revisión de arquitectura reciente hice la comprobación casi por rutina y el modelo previsto para producción estaba programado para retirarse poco después de la fecha de salida a producción. Nadie lo había mirado, y es lógico: un modelo que funciona hoy no parece una dependencia con fecha de caducidad. Los despliegues aprovisionados no se actualizan solos, así que el modo de fallo son errores de inferencia en un día marcado en un calendario que nadie leyó.

Es la reducción de riesgo más barata de todo el ejercicio.

Mi opinión

El cambio de nombre es la parte menos interesante y es de lo que más se habla. Lo relevante es la consolidación en un único recurso de Azure con proyectos dentro, porque arregla un problema real: recursos de IA multiplicándose más rápido de lo que nadie puede gobernarlos, con permisos concedidos al nivel que hiciera falta para que la demo funcionara ese día.

Si tienes más de tres recursos de IA en Azure y no puedes decir quién es el responsable de cada uno, la migración se paga sola en el paso de inventario, antes de desplegar nada.

Y si estás empezando, empieza aquí directamente. Si vienes de una configuración anterior, la guía de configuración empresarial de Azure AI Foundry sigue siendo válida en lo esencial, y para lo que escribes encima de la plataforma está Microsoft Agent Framework.

Preguntas frecuentes

¿Microsoft Foundry y Azure AI Foundry son lo mismo?

Es el mismo producto con nombre nuevo, pero con un modelo de recursos, una API de agentes y un SDK distintos. La experiencia anterior sigue disponible como Foundry (clásico) y los proyectos basados en hub continúan funcionando ahí.

¿Se retira Azure AI Foundry?

La documentación no da una fecha de fin de soporte para la experiencia clásica. Sí indica que la inversión nueva se centra en los proyectos de Foundry del portal nuevo, y que algunos casos de uso todavía requieren un recurso hub.

¿Hay región de Azure en España para desplegar Foundry?

Spain Central existe, está en Madrid y tiene zonas de disponibilidad, pero no tiene región emparejada, así que la recuperación ante desastres hay que diseñarla explícitamente. Comprueba también la disponibilidad de cada servicio concreto en esa región antes de cerrar el diseño.

¿Qué diferencia hay entre un recurso de Foundry y un proyecto?

El recurso es el límite de gobierno en Azure: red, seguridad y despliegues de modelo. El proyecto es el límite de desarrollo donde un equipo construye y evalúa, reutilizando esos despliegues y conexiones. La mayoría de las API nuevas están en el ámbito del proyecto.

¿Los recursos conectados heredan la seguridad de Foundry?

No. Storage, Key Vault y Azure AI Search son recursos independientes con su propio límite de gobierno, y su red y sus políticas de acceso se gestionan por separado. Es la lectura equivocada más habitual de la arquitectura.