Agentes de IA sem alçada: o limite de gasto que o ritmo humano impunha e ninguém precisou escrever

Em 3 de outubro de 2026, o desenvolvedor Simon Willison escreveu que os agentes de IA, que já programam e publicam aplicações sozinhos, vão precisar de limites de gasto duros, ativados por padrão em todo serviço cobrado por uso (nuvem, APIs, armazenamento): ao passar de um valor por mês, o serviço é interrompido, e não apenas avisado. O texto passou de 430 pontos no Hacker News no mesmo dia. A discussão que se seguiu é sobre qual fornecedor deve oferecer esse limite e se ele deve bloquear o serviço (limite duro) ou apenas avisar (limite permissivo). A pergunta que costuma faltar na diretoria é outra: quem, dentro da empresa, escolhe o valor, e o que a empresa prefere perder quando ele for atingido? ^{[1] afirmação da fonte original [4] afirmação da fonte original}

Willison descreve o problema assim: agentes de programação (e agentes pessoais, que são agentes de programação com uma interface menos assustadora) tornam muito mais fácil colocar no ar um sistema que faz algo útil, e esse sistema às vezes gera custo: chamadas a serviços pagos, hospedagem, armazenamento. Um e-mail de aviso à meia-noite não resolve, porque o gasto continua correndo enquanto a pessoa dorme. Ele pede o limite duro como padrão, com uma opção clara para quem quiser removê-lo e assumir o risco. ^{[1] afirmação da fonte original}

Os fornecedores começaram a responder, ainda com restrições. Em 16 de setembro de 2026, a AWS anunciou uma nova experiência de cadastro em que cada projeto pago tem um limite mensal de gasto: ao atingi-lo, o projeto é pausado até o mês seguinte. A cobertura especializada registra que o limite começa em US$ 20 e que o lançamento é gradual e vale só para clientes novos. ^{[2] afirmação da fonte original} O próprio texto de Willison cita o aviso da AWS de que a nova experiência está sendo liberada para “um número limitado de clientes”. ^{[1] afirmação da fonte original} A Google Cloud lançou, em 28 de julho, o limite de gasto (“spend cap”) em versão de testes (Preview): um valor mensal máximo para um serviço dentro de um projeto, hoje disponível para quatro serviços (Gemini API, Agent Platform, Cloud Run e Cloud Run functions), que age “em minutos”, enquanto o faturamento comum pode levar horas para fechar. ^{[3] afirmação da fonte original}

Limite da AWS

US$ 20

Valor inicial do limite mensal por projeto pago, no lançamento de 16/09/2026. É o ponto de partida proposto, não o limite de ninguém: o dono do projeto escolhe. Vale só para clientes novos, em liberação gradual.

Escopo do Google

1 projeto, 1 serviço

Cada limite de gasto cobre um único serviço em um único projeto, hoje em versão de testes e com quatro serviços elegíveis. Não é um limite para o que a empresa gasta no total.

Tempo até agir

Minutos

O Google afirma que o limite dos serviços de IA age em minutos, contra horas do faturamento comum. É o fornecedor falando de si, e o texto não mediu isso.

Duas reações com muitas respostas ao texto mostram que a divisão não é técnica. Um comentarista que diz ter trabalhado no suporte de um serviço com limite duro conta o oposto do que Willison espera: clientes que tiveram o serviço cortado na pior hora, por um pico de audiência ou um evento, e perderam as vendas desse pico e o acesso dos próprios usuários, com ameaças de processo. Na visão dele, o aviso é melhor, porque no pior caso o resto do negócio segue funcionando e a conta se negocia depois, com calma. E acrescenta: isso vale quando há pessoas operando o serviço. ^{[4] afirmação da fonte original} Outro comentário responde que, se uma máquina faz chamadas 24 horas por dia, cabe a quem a opera automatizar também o disjuntor. ^{[4] afirmação da fonte original} Os dois têm razão, cada um sobre uma perda diferente.

Quem defende o limite duro e quem defende o aviso compartilham uma premissa: o limite de gasto é um recurso do produto, que o fornecedor oferece ou não, e que o cliente ativa ou não. Sob essa premissa, a conversa é sobre como o produto deve ser (qual deve ser o padrão), e a empresa aparece como cliente que marca uma opção numa tela.

Só que, dentro de uma empresa, o limite de gasto nunca foi uma opção numa tela. Foi uma consequência do jeito como se gastava. Para comprar, alguém pedia, outro aprovava, um terceiro emitia o pedido, e a cobrança chegava dias depois. Cada etapa tinha uma pessoa, com horário de trabalho, que se cansa, que estranha um valor, que não aprova nada às três da manhã. O freio estava embutido no ritmo e no fluxo, e por isso nunca precisou ser escrito como regra. O comentarista do suporte disse isso sem perceber: o aviso funciona quando há pessoas operando o serviço. ^{[4] afirmação da fonte original}

Um agente remove as duas coisas ao mesmo tempo. Ele gasta na velocidade da máquina, e ninguém precisa assinar nada para que um trecho de código comece a usar um serviço pago. O tempo que a empresa leva para notar, por outro lado, não mudou: continua sendo a noite, o fim de semana ou o fechamento do mês. Há um relato, publicado no Hacker News em abril de 2026 e não verificado, de uma fatura de US$ 37.901,73 no serviço de modelos de IA da AWS, gerada por um uso comum de agente de programação: sem credencial vazada, sem repetição infinita, apenas a suposição errada de que um recurso de economia de custo (o cache de prompts) estava funcionando. ^{[8] afirmação da fonte original} Não é preciso um ataque para isso acontecer: o ritmo do gasto aumentou e o tempo para notar continuou o mesmo.

Comece pelo mais simples. A perda máxima de um gasto fora de controle é o ritmo de gasto (quanto por hora) multiplicado pelo tempo até alguém conseguir pará-lo. Um agente aumenta o primeiro fator. O segundo depende de como a empresa se organiza para parar, e nenhum agente o melhora sozinho. Conta ilustrativa da Invisible Work: um processo em repetição que gaste US$ 500 por hora e só seja notado após 10 horas (uma noite) custa US$ 5.000; se só for notado no fechamento da fatura mensal, 720 horas depois, custa US$ 360.000. O ritmo é o mesmo, e o tempo até notar multiplica a perda por 72. É uma conta hipotética, não a medida de nenhuma empresa.

1. 1

   O aviso informa, o limite duro decide

   O limite permissivo reduz o tempo até alguém ficar sabendo, mas não o tempo até parar, que continua dependendo de uma pessoa acordada. O limite duro leva o tempo até parar para perto de zero, e a empresa deixa de depender de uma pessoa estar acordada.

2. 2

   Parar custa outra coisa

   Cortar o serviço troca o risco de gastar demais pelo risco de ficar fora do ar. Foi o que o comentarista do suporte descreveu: o corte veio no pico de vendas. Nenhuma das duas perdas é gratuita, e por isso não existe um padrão certo para todas as empresas.

3. 3

   Escolher entre as duas perdas é decisão de negócio

   Quanto vale uma hora de serviço no ar contra uma hora de gasto sem limite? Quem sabe isso é quem responde pela receita e pelo caixa, não quem configura a conta de nuvem. O valor do limite é o preço dessa troca, escrito como número.

4. 4

   O freio precisa estar fora do que ele freia

   Um limite que o próprio agente pode alterar, ou que depende da credencial que ele usa, não é um limite, é uma sugestão. A regra vale para pessoas também: o controle de quem aprova não deve ficar nas mãos de quem gasta.

Esse padrão já tem história em outro setor. Em 1º de agosto de 2012, a Knight Capital, uma corretora americana, colocou em operação uma atualização do sistema automático que envia ordens de compra e venda de ações, e um trecho de código antigo, que deveria estar desativado, continuou ativo em um dos oito servidores. Segundo o relatório da SEC (a comissão que regula o mercado de capitais nos Estados Unidos), citado pela Wikipedia, o sistema fez cerca de 4 milhões de operações em 154 ações, mais de 397 milhões de ações negociadas, em cerca de 45 minutos. ^{[7] afirmação da fonte original} A perda antes de impostos foi de US$ 440 milhões. ^{[7] afirmação da fonte original} Dividido pelo tempo, dá em média cerca de US$ 10 milhões por minuto (conta nossa, 440 ÷ 45). Em 2013, ao aplicar uma multa de US$ 12 milhões, a SEC concluiu que a empresa “não tinha proteções adequadas para limitar os riscos do seu acesso aos mercados” e, por isso, não impediu a entrada de milhões de ordens erradas (tradução nossa). Foi a primeira ação da SEC baseada na regra de acesso ao mercado, adotada em 2010. ^{[6] afirmação da fonte original}

O desenho da regra é o que interessa para quem decide. A Regra 15c3-5 exige controles “razoavelmente desenhados” para impedir a entrada de ordens que ultrapassem limites de crédito ou de capital definidos de antemão, valendo “no agregado” (ou seja, somando tudo) para cada cliente e para a própria corretora, e recusando a ordem que passar do limite (tradução nossa). Exige também que o presidente-executivo, ou equivalente, certifique todo ano que esses controles existem e foram revistos. ^{[5] afirmação da fonte original} Três pontos aparecem ali: o limite é duro (a ordem é recusada), vale para o total e não só para cada parte, e tem um responsável com nome. A regra não escolhe o valor, que cada empresa define. Exige que ele exista, que valha e que alguém assine.

Se o limite de gasto é uma decisão de alçada e não uma opção numa tela, três coisas mudam. São hipóteses da Invisible Work, derivadas do raciocínio acima, e não resultados medidos.

1. 01

   A soma dos limites por serviço não é o limite da empresa

   Os limites que os fornecedores lançaram valem para um serviço em um projeto (Google) ou para um projeto (AWS). Um agente que usa seis serviços de três fornecedores pode estar abaixo de todos os limites e acima do que a diretoria aceitaria no total. A regra do mercado de capitais exige o limite sobre o total por esse motivo. Hipótese: o freio da diretoria precisa ficar acima do fornecedor, na conta, no cartão ou na credencial que o agente usa.

2. 02

   Quem escolhe o número é quem responde pela perda

   O desenvolvedor que ativa o limite sabe o que o serviço faz, não quanto vale para a receita uma hora dele no ar. Se o valor ficar com quem configura, tende a seguir a conveniência técnica, não a troca entre as duas perdas. Hipótese: o valor do limite e a ação ao atingi-lo (parar, reduzir, pedir aprovação) são decididos por quem responde pela perda, e o desenvolvedor executa.

3. 03

   Parar não precisa ser tudo ou nada

   O texto de Willison e o comentarista do suporte defendem duas posições extremas. Entre elas há desenhos intermediários: um limite que reduz o ritmo (o agente continua, mais devagar), um que pede aprovação de uma pessoa acima de certo valor, um que bloqueia só o gasto que cria algo novo e preserva o que já atende clientes. A regra do mercado fala em limites ajustados “por setor ou por ativo”. Hipótese: um disjuntor por tipo de gasto reduz a perda de serviço sem devolver a exposição ao gasto sem limite.

O método abaixo é da Invisible Work e cabe numa reunião de uma hora com finanças, tecnologia e a área dona de cada processo, antes de liberar um novo agente com acesso a qualquer serviço cobrado por uso.

1. 01

   O que pode gastar sozinho?

   Liste os agentes e automações com acesso a um meio de pagamento, a serviços pagos por uso ou à criação de recursos na nuvem. Inclua os que alguém criou para uso pessoal e que funcionam com a credencial da empresa. A lista costuma ser maior do que a diretoria imagina.

2. 02

   Quanto pode gastar até alguém notar?

   Para cada um, estime o gasto máximo por hora e o tempo real até uma pessoa ver e poder agir (noite, fim de semana, fechamento). Multiplique. O resultado é a exposição, e é ela que vai para a decisão, não o gasto médio.

3. 03

   Quem escolhe o valor, e o que acontece ao atingi-lo?

   Defina por escrito o valor, a ação (parar, reduzir ou pedir aprovação) e quem responde por ela. Pergunte quanto vale para o negócio uma hora de serviço fora do ar contra uma hora de gasto sem limite. Quem responde pela perda assina o valor.

4. 04

   O limite vale para o total e está fora do alcance do agente?

   Confira se existe um limite sobre o total (na conta, no cartão ou na credencial), e não só um por fornecedor, e se o agente não consegue alterá-lo nem desativá-lo com a credencial que usa. Registre quando foi revisto pela última vez, como a regra do mercado exige de quem opera de forma automática.

Willison é um desenvolvedor expressando uma opinião, e os comentários do Hacker News são de pessoas que não se identificam por nome e não puderam ser verificadas, inclusive o relato de suporte citado e a fatura de US$ 37.901,73. As funções da AWS e do Google foram conferidas nas páginas dos fornecedores e na cobertura especializada e podem mudar: a da AWS está em liberação gradual e a do Google em versão de testes, e o texto não testou nenhuma das duas. Os números do incidente da Knight Capital vêm de uma enciclopédia que cita o relatório da SEC, que o ambiente de pesquisa não conseguiu abrir; o comunicado de 2013 e o texto da regra foram lidos. A Knight era uma corretora, e o paralelo é de estrutura, não de causa. A conta de US$ 500 por hora é hipotética e a média de US$ 10 milhões por minuto é uma divisão nossa de um total por uma duração, não um ritmo medido. Não há dado aqui sobre empresas brasileiras, e a existência de uma matriz de alçadas varia de empresa para empresa. As três consequências e o método de quatro perguntas são hipóteses da Invisible Work.

Seis perguntas para quem responde por orçamento, por risco ou por operação.