O gateway de IA deixou de ser proxy e virou ponto de política. O LLM Gateway da C1 mostra por quê

Quase toda empresa que usa mais de um modelo já tem um gateway de IA, mesmo que ninguém chame assim. Às vezes é um proxy reverso na frente do Azure OpenAI. Às vezes é uma biblioteca interna que o time de plataforma pede para todo mundo usar. Muitas vezes é um cofre com chaves de API e uma planilha que diz qual chave pertence a qual centro de custo.

Esses arranjos respondem a uma pergunta: esta aplicação consegue chegar ao modelo? Raramente respondem às perguntas que o CISO, o DPO e o financeiro fazem de verdade. Quem fez essa chamada? Que dado estava nela? Esse modelo podia ver esse dado? Quem paga a conta?

A C1, fornecedora de segurança e governança de identidades, lançou em 1º de outubro um LLM Gateway desenhado em torno dessas perguntas. O produto é um sinal. A mudança que ele representa é maior: o gateway está virando ponto de aplicação de política, e a identidade passa a ser a chave de roteamento.

O que a C1 anunciou

Segundo a C1, o LLM Gateway oferece a aplicações e agentes um endpoint único de inferência, controlado por política, que distribui as chamadas entre implantações de modelos aprovadas: públicas, privadas e controladas pelo próprio cliente. O time define as rotas elegíveis por provedor, modelo, implantação, região e regras de tratamento de dados. Dentro dessas rotas, o gateway escolhe o destino por capacidade, saúde, latência e custo.

Dois detalhes tiram o produto da categoria de proxy. O gateway amarra cada chamada à pessoa, aplicação, workload ou agente que está por trás dela, usando a base de identidade e políticas da plataforma C1. E guarda esse contexto para atribuir uso e custo de inferência a donos, projetos ou unidades de negócio.

O anúncio não informa disponibilidade geral, preço, regiões atendidas nem a lista de provedores suportados. Interoperabilidade aqui é algo a testar, não a presumir.

Por que a rota saiu do código

Na primeira onda de IA enterprise, a escolha do modelo morava no código. A pessoa desenvolvedora escolhia um endpoint, fixava o nome da implantação e seguia em frente. Isso deixa de funcionar por três motivos.

A lista aprovada muda o tempo todo. Modelos novos chegam todo mês, versões antigas são aposentadas e o mesmo modelo chega por caminhos de entrega diferentes, com termos de dados diferentes, como mostramos na nossa análise dos caminhos do Claude no Azure e na AWS. Se cada aplicação decide a própria rota, cada mudança vira alteração de código em dezenas de repositórios.

A regra depende do dado, não da aplicação. O mesmo assistente interno pode analisar um contrato de fornecedor de manhã e um prontuário à tarde. Quando a chamada carrega dados pessoais e o modelo está hospedado fora do país, o que entra em jogo é a transferência internacional de dados, que a ANPD regulamentou na Resolução CD/ANPD nº 19/2024. Mandar esse tipo de chamada para uma implantação na região de São Paulo ou para outra nos Estados Unidos é uma decisão de privacidade, tomada chamada a chamada.

O custo precisa de dono no momento da chamada. O financeiro quer o gasto com IA por caso de uso e por área, não por SKU de modelo. Ratear a fatura de tokens depois, a partir de logs sem identidade, é o caminho lento e cheio de discussão. Tratamos o lado das plataformas disso no nosso texto sobre limites de gasto com IA.

1. Quem chama: pessoa, app ou agente
2. Resolver identidade e workload
3. Aplicar regras de dados e região
4. Escolher entre rotas elegíveis
5. Implantação do modelo
6. Atribuir o custo a um dono

• A política decide: Resolver identidade e workload · Aplicar regras de dados e região · Escolher entre rotas elegíveis
• Os sinais decidem: Escolher entre rotas elegíveis · Implantação do modelo

Trabalho que sai do código da aplicação e vai para o gateway

A ordem das decisões importa

A ideia de desenho mais útil na descrição da C1 é a sequência: primeiro a política, depois a otimização. Regras de identidade, classe de dado e região definem quais rotas são elegíveis. Só então latência e custo escolhem entre elas.

Times que constroem o próprio gateway costumam inverter essa ordem. Começam por balanceamento de carga e failover, que são fáceis de medir, e deixam a política para depois. O resultado é um gateway capaz de trocar, sem avisar ninguém, uma implantação privada lenta por uma pública. É exatamente o evento que o time de privacidade precisa impedir.

Em instituições financeiras, essa troca silenciosa tem um agravante: contratar processamento em nuvem segue as regras da Resolução CMN nº 4.893/2021, e uma rota de fallback para um provedor que não passou por essa avaliação é, na prática, uma contratação que ninguém aprovou.

O que verificar antes de comprar ou construir

Quem já trabalha no ecossistema Microsoft tem um ponto de partida: os recursos de gateway de IA do Azure API Management, que aplicam limites de tokens, distribuem carga entre backends de modelos e emitem métricas de uso. Isso resolve bastante coisa. A pergunta a fazer para qualquer opção, seja Microsoft, C1 ou um proxy feito em casa, é se a identidade real de quem chama chega à decisão de rota, ou se o gateway só enxerga uma chave de aplicação.

Uma lista prática:

1. Identidade, e não só chaves. O gateway enxerga a pessoa e o agente, inclusive quando o agente age em nome de alguém? Essa identidade pode vir do seu provedor de identidade atual?
2. Regras de dados escritas como política. Dá para dizer “dados pessoais de clientes só vão para implantações no Brasil” sem mexer no código das aplicações?
3. Nada de rebaixamento silencioso. O que acontece quando todas as rotas elegíveis estão fora do ar? A resposta segura é um erro, não um desvio para uma rota não autorizada.
4. Registros de custo que o financeiro consegue usar. Cada chamada leva dono, projeto e centro de custo, num formato que a sua ferramenta de FinOps importa?
5. Evidência. As decisões de rota ficam registradas com a política aplicada, para que uma auditoria reconstrua por que a chamada foi para onde foi?
6. Portabilidade. O gateway fala os formatos de API que as aplicações já usam, para que incluir ou tirar um provedor seja só configuração?

Em resumo

Quando a empresa passa a usar mais de um modelo, alguém precisa decidir qual chamada vai para onde. Deixar essa decisão no código espalha a responsabilidade por todos os times. Levá-la para um gateway que conhece a identidade transforma a decisão em política, que segurança, privacidade e financeiro conseguem ler e revisar. O lançamento da C1 é a versão de um fornecedor. O ponto de arquitetura vale para qualquer stack e se encaixa nas camadas de identidade e política do nosso guia do stack de IA enterprise de 2026.