AI Gateway no Microsoft Foundry: como ratear o custo de IA generativa por área da sua empresa

A conta de IA generativa da sua empresa chegou no fim do mês e ninguém sabe dizer qual área consumiu o quê. Um projeto piloto do time de atendimento pode ter usado a mesma capacidade de modelo que sustenta o produto em produção, e o time de TI só descobre quando o cliente reclama ou quando o financeiro pergunta por que o gasto dobrou. Essa cena está se repetindo em cada empresa que colocou dois ou mais projetos de IA para rodar em Azure.

O que mudou

A Microsoft publicou uma novidade no ecossistema Foundry que ataca exatamente esse ponto. Agora existe uma tela de administração no Foundry que conecta um gateway de IA baseado no Azure API Management e associa cada projeto ao gateway com um teto próprio de consumo de tokens. Antes, montar essa arquitetura exigia um projeto de infraestrutura à parte, com políticas escritas à mão, chaves distribuídas e sem inventário unificado. A rota do dado continua a mesma, do aplicativo ao gateway e do gateway ao modelo, mas quem configura e governa passou a ter um caminho de primeira classe dentro do Foundry.

Impacto prático nas empresas

O ganho mais evidente é a previsibilidade da fatura. Cada projeto passa a ter um contador próprio de uso, e quando o limite é atingido a chamada para com um erro claro, sem contaminar os outros projetos que dividem o mesmo gateway. Isso significa que um teste do time de marketing não derruba o assistente que atende o cliente final.

O segundo ganho é a base de dados para rateio. Os logs do gateway registram qual projeto fez cada requisição, quantos tokens consumiu e quando. Esse rastro auditável é o insumo que o financeiro pede para dividir o custo de IA entre centros de custo, algo que hoje é feito com estimativa, na base do achismo. Com esse dado, a conversa sobre orçamento de IA no ano seguinte passa a ser sustentada por número, não por percepção.

O terceiro ganho é o inventário. Agentes que já rodam em App Service e ferramentas suportadas do padrão MCP entram no mesmo modelo de governança sem exigir reescrita da aplicação. Para quem já tem uma arquitetura de IA rodando, isso é fundamental: o ganho de controle não vem ao custo de refazer o que está em produção.

Cenários reais de aplicação

Uma empresa média com quatro áreas testando IA em Azure, RH, financeiro, atendimento e operações, sente esse problema rápido. Cada área liga seu próprio piloto, o gasto sobe e o fechamento mensal vira uma discussão sobre quem consumiu quanto. Com limite por projeto, o RH sabe que tem, por exemplo, uma cota mensal de tokens e opera dentro dela. Se o piloto do RH consome tudo antes do fim do mês, é o RH que precisa decidir se pede mais verba ou reduz o escopo, e essa decisão passa a ser tomada com dado, não com achismo.

Em outro cenário, uma empresa que escala um assistente do atendimento para produção precisa garantir que os testes internos não engasguem o serviço que fala com o cliente final. Separar o projeto de produção do projeto de laboratório, cada um com seu teto, é a forma prática de blindar a experiência do cliente.

Pontos de atenção

Há um pré-requisito técnico que costuma pegar times desprevenidos. A integração exige o Azure API Management em tier v2, seja Basic v2, Standard v2 ou Premium v2. Instâncias em tier Developer, comuns em laboratórios, ou em tiers clássicos não aparecem na lista do Foundry e demandam uma migração planejada, não uma simples troca de configuração.

Outro ponto de atenção é a coexistência de três camadas de limite. Passa a existir um limite por projeto Foundry, um limite de policy do próprio APIM, geralmente por aplicação ou consumidor, e a quota do deployment do modelo, que é o teto do endpoint. Cada camada responde a uma pergunta diferente e deve ser usada com propósito claro. Sem esse desenho, o time de operação vai receber erros de limite excedido sem saber qual camada disparou, e a governança que deveria simplificar vira ruído.

Há também recursos ainda em preview, como o registro de agentes externos e a governança de ferramentas MCP. Vale acompanhar e planejar, sem apostar a operação neles antes do amadurecimento.

Como a Memory apoia

A Memory faz o assessment da landing zone de IA no Azure e mapeia se o ambiente atual está apto a receber essa arquitetura. Cuidamos da implementação do APIM AI Gateway no tier correto, do desenho dos limites por projeto alinhados aos centros de custo do cliente e da configuração da coleta de logs que vira relatório de rateio para o financeiro. Também apoiamos a entrada dos agentes existentes em App Service e das ferramentas MCP nesse modelo de governança, sem exigir reescrita da aplicação.

Conclusão

A composição de Foundry, APIM e App Service já era o desenho arquitetural certo para IA generativa corporativa. O que mudou é que agora existe um caminho de operação mais direto para o time de plataforma. Para o decisor, a pergunta prática é simples: sua empresa consegue dizer hoje, com número, quanto cada área gastou em IA no último mês? Se a resposta é não, é hora de colocar esse controle no roteiro, antes do próximo fechamento surpreender.