Microsoft lanzó el tier AI Gateway de Azure API Management en vista previa pública el 27 de julio, disponible en East US 2 y Sweden Central sin costo mientras se determina el precio. El tier es un recurso construido a propósito cuyo plano de control está organizado alrededor de modelos, servidores MCP y herramientas en lugar de APIs, un alejamiento estructural del enfoque de policy-layering de los tiers clásico y v2, que mantienen sus capacidades de gateway de IA existentes sin cambios.

La capa de federación de modelos cubre la realidad multi-cloud en la que ya viven la mayoría de las flotas empresariales. La vista previa publica modelos alojados en Foundry incluyendo OpenAI, Anthropic y Mistral junto con modelos en AWS Bedrock, Google Vertex AI y OpenAI directo. Todos los proveedores compatibles con OpenAI comparten una ruta de endpoint; el gateway enruta en coincidencia exacta del campo de modelo, por lo que cada modelo publicado requiere un nombre único. Anthropic se ejecuta a través de un proveedor personalizado con paso directo de la API Messages. Un gateway se aprovisiona en aproximadamente un minuto sin unidades de escala para planificar.

La federación de herramientas extiende el mismo patrón a la capa MCP. Los equipos pueden exponer un servidor MCP existente sobre SSE o HTTP Streamable, convertir operaciones de REST API en un servidor MCP cargando una especificación OpenAPI, o aprovechar más de 1.400 herramientas respaldadas por conectores de la biblioteca Power Platform y Logic Apps sin alojar un servidor. Múltiples servidores MCP federados se encuentran detrás de un único endpoint, por lo que un agente se conecta una vez y resuelve herramientas en todos ellos. La autenticación por backend admite claves de API, credenciales OAuth 2.0 client credentials, identidad administrada y mTLS.

La gobernanza se configura a través de tarjetas de policy en el portal como propiedades JSON en lugar de las expresiones XML que conocen los veteranos de APIM. Las tarjetas cubren límites de tasa de solicitud y token, cuotas de token, Azure AI Content Safety y conmutación por error a un modelo secundario. Las policies se aplican por asset, haciendo explícita la cobertura para cada modelo o servidor MCP. La telemetría fluye como métricas de token OpenTelemetry con convenciones semánticas GenAI hacia Application Insights, Datadog, Splunk, Grafana Cloud, o cualquier endpoint OTLP que el cliente controla. El recurso se ejecuta en la suscripción y tenant de Entra propios del cliente.

El modelo operativo separa la propiedad de la plataforma de la autonomía del equipo. Un grupo central conecta modelos y herramientas aprobados, establece guardrails y mantiene la imagen de uso; los equipos de aplicación prueban assets en una consola integrada y construyen contra ellos sin enrutar cada cambio a través del centro. Esto funciona solo si se mantiene el límite de acceso. No se mantiene de la manera que lo hizo el scoping de suscripción APIM: una clave de runtime tiene alcance de gateway, llegando a cada modelo y cada herramienta publicada en ese gateway. La orientación de Microsoft es una clave por aplicación, pero el radio de explosión de una clave comprometida es todo el gateway en lugar de un único producto. Los equipos que se basaron en suscripciones APIM para limitar consumidores a APIs específicas deben rediseñar ese límite.

Dos preguntas sin resolver de arquitectos son importantes. La cobertura del ciclo de vida del agente es la primera: si una ejecución de agente termina sin una conclusión limpia después de producir trabajo útil, no está claro si la salida se preserva para revisión auditable o si el gateway reintenta la ejecución desde cero. La distinción importa para pipelines de agentes stateful donde la idempotencia no está garantizada. La segunda es coexistencia: las organizaciones que construyeron configuraciones de gateway de IA en Premium o Standard v2 no tienen orientación publicada sobre si esas inversiones se transfieren, se ejecutan en paralelo o se migran al nuevo tier. La documentación de Microsoft describe el tier AI Gateway como una extensión del gateway existente, pero el portal y el plano de control están estructuralmente separados.

La postura de vista previa requiere una lectura cuidadosa antes de planificar un cronograma de incorporación. No hay SLA. Las APIs, telemetría, límites, regiones y precios pueden cambiar antes de GA. Los límites específicos de throughput y cuota no se han publicado. El precio aún no se ha anunciado, lo que deja el argumento cost-governance—el más citado como el valor práctico del tier—como la parte menos resuelta del lanzamiento.

La conclusión arquitectónica: el tier AI Gateway resuelve el problema de consolidación del plano de control para equipos que enfrentan cinco o más proveedores de modelos, pero las brechas de key-scoping y coexistencia lo hacen una implementación de workbench en lugar de un plano de control de producción hasta que Microsoft proporcione granularidad de cuota y orientación de migración.