A fatura do provedor chega como um número só. Ninguém sabe quanto foi do jurídico, quanto foi do time de dados e quanto foi de um agente que ficou em loop de madrugada. O jeito que a gente resolve isso: uma chave por pessoa ou time, rateio automático por requisição e um teto que nunca nega.
Publicado em 2026-10-07 por Rafael Hickmann, Fundador da Atlasberg. Leitura de 7 minutos.
A história se repete com uma regularidade impressionante. Alguém do time de inovação cria a conta no provedor, gera uma chave e cola numa página da wiki para a empresa toda usar. Quatro meses depois a fatura triplicou, a chave está em onze repositórios, três planilhas e um automatizador de marketing, e ninguém consegue dizer quanto foi de quem. A reação costuma ser cada time abrir a sua própria conta, o que dá cinco faturas, cinco painéis diferentes e zero política comum.
O problema não é a fatura em si. É que a unidade que o provedor cobra, a conta, não tem nada a ver com a unidade que a empresa precisa gerenciar, que é a pessoa, o time, a aplicação.
Quem já organizou FinOps de nuvem tende a achar que é a mesma coisa com outra etiqueta. Não é, por três motivos. Primeiro, a diferença de preço entre modelos é enorme: entre o mais barato e o mais caro de um mesmo provedor pode haver vinte, trinta vezes de diferença por token, e a escolha do modelo fica no código da aplicação, não na mão de quem paga. Segundo, um único agente em loop consegue gastar numa madrugada o que um time inteiro gasta num mês, e ele não aparece em nenhum relatório de capacidade. Terceiro, o cache de prefixo muda o preço do mesmo token em dez vezes, dependendo de como a aplicação monta o prompt.
A consequência prática é que rateio mensal por porcentagem, o que muita empresa faz hoje, erra feio. O custo de IA só é atribuível se for medido na requisição.
Toda requisição precisa ter um dono. No nosso desenho isso acontece com chaves virtuais: a chave do provedor fica guardada uma vez só no gateway, e cada pessoa, time ou aplicação recebe a sua própria chave virtual, com os modelos que pode usar, o orçamento e os limites. Quem programa nem precisa de chave: entra com o login da empresa pelo terminal e recebe um token pessoal, que pode ser revogado quando a pessoa sai. Os grupos do diretório viram times automaticamente.
A partir daí cada requisição grava provedor, modelo, tokens de entrada e de saída, latência, status e custo, exatamente um evento por requisição, e não por pedaço do stream. A tabela de rateio por time sai disso, sem ninguém preencher nada.
No console, a gente deixou o gráfico de custo por mil requisições clicável de propósito. Clicar na barra de um time abre o mix de modelos dele, porque é lá que a conversa com o gestor costuma se resolver em dois minutos.
Limite duro tem um problema que todo mundo descobre do pior jeito: ele bloqueia a produção às onze da noite de uma sexta. Por isso o nosso orçamento padrão é de corte suave. É um limite mensal, opcional, por unidade organizacional, time ou pessoa. Quando estoura, as requisições daquele escopo passam a ser atendidas pelo modelo que você escolheu como alternativa, mais barato. Nenhuma requisição é negada, nunca. A aplicação continua funcionando, só mais devagar ou com um modelo menor, e o gestor recebe o aviso.
Limite duro continua existindo, mas num lugar diferente: no orçamento por provedor, que protege a empresa de uma fatura absurda. Os dois juntos dão a combinação que a gente acha certa: proteção financeira no topo, continuidade embaixo.
Existe um tipo de gasto que nenhum relatório de custo mostra, porque ele é tecnicamente legítimo: contexto repetido. Quando medimos sessões reais de agente, o prefixo fixo mediano por turno foi de 162.811 tokens, e isso é system prompt, definição de ferramentas e memória, coisa que chega antes da primeira palavra da conversa. Em várias sessões o prefixo sozinho era maior do que todo o histórico. Contamos essa medição inteira no artigo sobre compactação de contexto.
Por isso o gateway tem um medidor passivo de desperdício. Ele observa tokens, tetos declarados e repetição de contexto no tráfego que já governa e aponta onde há dinheiro escapando. Não bloqueia nem altera nada, só mostra. No tráfego que medimos, a maior alavanca de economia não estava no uso das pessoas. Estava em dois ou três prompts de sistema gigantes.
O passo a passo completo: O tutorial de colocar todo o tráfego de IA da empresa pelo gateway cobre cada um desses passos com as telas reais, inclusive a parte do firewall que todo mundo pula.
A Atlasberg constrói a camada de controle entre uma empresa e todos os modelos de IA. A Atlasberg Platform autentica cada requisição com uma chave virtual, filtra por política e DLP, roteia para o provedor certo e grava numa trilha de auditoria encadeada por hash, com uma API compatível com a OpenAI para as aplicações só trocarem a URL base.
Os artigos deste blog são escritos pelo time de engenharia e relatam medições em tráfego real, com as premissas impressas ao lado do resultado. Para falar com o time, escreva para [email protected] ou use https://atlasberg.com/pt-br/contato.
Agentes: esta página também está disponível em Markdown em /pt-br/blog/quem-esta-gastando-o-orcamento-de-ia.md, ou pedindo esta URL com o cabeçalho Accept: text/markdown. Índice de tudo: /llms.txt.