Azure API Management se consolida como AI gateway: novas capacidades para modelos, agentes e segurança de conteúdo

O Azure API Management acaba de receber atualizações significativas que o consolidam como um AI gateway centralizado para empresas que gerenciam múltiplos provedores de IA. As novidades incluem uma Unified Model API (preview) que padroniza chamadas via formato OpenAI, suporte GA para modelos Anthropic e Vertex AI, segurança de conteúdo para MCP e A2A, métricas expandidas de tokens e disponibilidade geral das APIs A2A. O principal ganho: governança única para LLMs, ferramentas e agentes, sem a necessidade de soluções customizadas por provedor.

Aplicacoes de IA multi-model e multi-protocolo estão se tornando a norma. Times estão combinando modelos OpenAI, Anthropic e Vertex AI, expondo ferramentas via MCP e conectando agentes com A2A. Conforme essa superficie cresce, o trabalho de manter tudo seguro, observável e consistente também aumenta.

A estratégia da Microsoft para as capacidades de AI gateway no Azure API Management gira em torno de um problema central: fornecer um único lugar para gerenciar modelos, ferramentas MCP e agentes, independentemente do provedor ou protocolo por trás deles. As atualizações abaixo representam os passos mais recentes nessa direção.

Como a Unified Model API simplifica o multi-provedor?

A grande novidade desta release: a Unified Model API (em preview) permite que clients falem um único formato de API — OpenAI Chat Completions — enquanto o API Management transforma as requisições para o provedor de backend, seja ele um modelo usando OpenAI Chat Completions ou a Anthropic Messages API.

Ao centralizar o acesso a modelos por trás de uma única camada de API, você pode:

• Padronizar em um único formato de API para os clients, independentemente dos formatos usados pelos modelos de backend.
• Unificar observabilidade, segurança e governança com políticas que se aplicam a todos os provedores de modelo.
• Configurar failover entre provedores de modelo.
• Desacoplar nomes de modelo voltados ao client dos nomes reais de backend usando aliases.

Model aliases: estabilidade sem alteração de código

Os model aliases fornecem aos clients um nome estável e neutro em relação ao provedor para usar ao chamar um modelo. Ao atribuir um alias como gpt ou claude-sonnet, você desacopla o nome do modelo visível ao client do deployment real no backend.

Isso torna algumas operações comuns muito mais fáceis:

• Upgrade de modelo. Atualize o alvo do alias para apontar para uma nova versão — sem necessidade de alterar código nos clients.
• Testes A/B. Direcione tráfego entre backends diferentes por trás do mesmo alias usando as capacidades de load balancing do API Management.
• Troca de provedor. Substitua um provedor por outro sem tocar no código das aplicações.

Model discovery: transparência para os desenvolvedores

Desenvolvedores podem descobrir os modelos disponíveis chamando o endpoint /models da Unified Model API. O API Management retorna a lista de aliases de modelo, permitindo que apps e ferramentas se adaptem ao que a equipe de plataforma publicou — sem necessidade de documentação externa.

Quais provedores de modelo agora são suportados em GA?

As políticas de AI gateway e observabilidade agora funcionam com modelos Anthropic e Google Vertex AI, junto com os provedores já suportados.

Você pode:

• Aplicar políticas de runtime como content safety, token limits e semantic caching para tráfego Anthropic e Vertex AI.
• Coletar logs, traces e métricas para esses modelos no mesmo lugar que o restante do tráfego de IA.

Se você está executando uma configuração multi-provedor, não precisa mais de uma história de governança separada para cada fornecedor.

Como a importação do Microsoft Foundry evoluiu?

Ao importar um recurso do Microsoft Foundry como uma API no Azure API Management, a importação agora cria operações para APIs Anthropic junto com as APIs de modelo existentes. Em poucos cliques, você pode montar uma API que media o tráfego para modelos Foundry usando o formato OpenAI ou Anthropic — sem definições manuais de operações — e então aplicar as mesmas políticas, segurança e observabilidade que você usa para o restante do tráfego de IA.

Por que as métricas de token foram expandidas?

O rastreamento de tokens costumava parar em tokens de prompt, completion e total. Modelos modernos adicionam tokens cached, reasoning e thinking, que podem representar uma parcela significativa do consumo de tokens, custo e latência.

O API Management agora registra métricas para esses tipos adicionais de tokens no Application Insights, em todos os formatos de API (OpenAI Chat Completions, OpenAI Responses e Anthropic Messages API) e provedores (Microsoft Foundry, OpenAI, Amazon Bedrock, Google Vertex AI e outros).

Com sinais mais ricos, seus dashboards de custo, alertas de orçamento e planejamento de capacidade podem refletir como os modelos de hoje realmente se comportam.

Como a segurança de conteúdo foi estendida para MCP e A2A?

A política llm-content-safety agora cobre tráfego MCP e A2A além do tráfego LLM. Isso inclui argumentos de tool-call MCP, texto de resposta MCP e payloads A2A.

Duas melhorias relacionadas:

• llm-content-safety agora pode ser configurada diretamente como uma outbound policy.
• Dois novos atributos — window-size e window-overlap-size — permitem ajustar como mensagens que excedem o limite de 10.000 caracteres do Azure Content Safety são divididas e encaminhadas para validação, equilibrando sensibilidade de detecção com volume de chamadas ao Azure Content Safety.

O resultado é uma política de segurança consistente em fluxos LLM, MCP e A2A, em vez de ter que montar filtros customizados por protocolo.

O que muda com a disponibilidade geral das APIs A2A?

O suporte para APIs Agent-to-Agent (A2A) no API Management agora está geralmente disponível. APIs de agentes agora podem ser governadas com as mesmas políticas, identidade e observabilidade usadas para o restante das APIs.

O que você pode fazer com APIs A2A no API Management:

• Mediar operações JSON-RPC runtime para seu backend de agente com suporte total a políticas — incluindo as melhorias de content safety mencionadas.
• Expor e gerenciar agent cards, automaticamente transformados pelo API Management para representar a API do agente gerenciado.
• Registrar traces no Application Insights usando convenções semânticas OpenTelemetry GenAI para correlação profunda entre traces de API e execução de agentes.

O que há de novo no GA, além do preview:

• Disponível em tiers classicos, além dos tiers v2 — leve a governança A2A para recursos existentes do API Management sem migrar de tier.
• Logs de diagnóstico mais ricos para APIs A2A, fornecendo telemetria mais acionável para monitoramento e troubleshooting de tráfego de agentes.

Como o BYOM no Foundry Agent Service se relaciona?

No mês passado, o Bring Your Own Model (BYOM) no Foundry Agent Service tornou-se GA. O BYOM permite que times enterprise roteiem chamadas de modelo dos agentes Foundry através de sua própria infraestrutura — normalmente por questões de compliance, governança ou para reutilizar um gateway de modelo existente.

Isso combina naturalmente com as capacidades de AI gateway no Azure API Management. Coloque o API Management na frente de seus modelos, aplique as políticas e observabilidade descritas acima, e faça com que os agentes Foundry chamem através dele — obtendo governança consistente tanto para seu tráfego de IA direto quanto para suas cargas de trabalho de agentes.

Perguntas Frequentes

• O que é a Unified Model API e qual problema ela resolve?
  É um recurso em preview que permite aos clients usarem um único formato de API (OpenAI Chat Completions) enquanto o API Management faz a tradução para o provedor de backend, como Anthropic ou Vertex AI. Isso elimina a necessidade de cada aplicação lidar com diferentes formatos de API, centralizando governança, failover e observabilidade.

• Como os model aliases ajudam na gestão de modelos de IA?
  Model aliases são nomes estáveis e neutros (ex: gpt, claude-sonnet) que desacoplam o nome visível ao client do deployment real no backend. Isso facilita upgrades de modelo, A/B tests com balanceamento de carga e troca de provedores sem alterar código das aplicações.

• O suporte a A2A APIs já está em produção?
  Sim, o suporte para Agent-to-Agent (A2A) APIs está em GA. Agora é possível mediar operações JSON-RPC, gerenciar agent cards e logar traces no Application Insights usando convenções semânticas OpenTelemetry, com disponibilidade tanto nos tiers v2 quanto nos tiers clássicos do API Management.

• Quais provedores de modelo são suportados pelas novas políticas de segurança e observabilidade?
  Além dos já existentes, as políticas de AI gateway (content safety, token limits, semantic caching) e observabilidade agora funcionam com Anthropic e Google Vertex AI. A coleta de logs, traces e métricas é unificada para todos os provedores em um mesmo dashboard.

• Como a segurança de conteúdo foi estendida para MCP e A2A?
  A política llm-content-safety agora cobre tráfego MCP (incluindo tool-call arguments e response text) e A2A payloads, além de LLM. Ela pode ser configurada como outbound policy e possui novos atributos (window-size e window-overlap-size) para ajustar o chunking de mensagens que excedem 10.000 caracteres.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.