Uma reunião a 28 de julho e um número que ninguém queria

A 28 de julho, engenheiros seniores da Amazon informaram os colegas sobre o que tinha acontecido a um conjunto de projetos internos de IA. O Financial Times noticiou o conteúdo. Um projeto usava o Claude Sonnet, da Anthropic, para cruzar dados de autores com fichas do comércio eletrónico. Gastou 1,8 milhões de dólares. Ficou 860 por cento acima do orçamento. Correu cinco meses antes de alguém o apanhar, e nunca entrou em produção. Uma equipa descreveu o padrão como catastroficamente caro.

Vieram com ele dois casos menores. Uma ferramenta de auditoria financeira derrapou cerca de 541.000 dólares. Um projeto de logística ficou uns 134.000 dólares acima do plano. Um trabalhador sénior da Amazon resumiu o problema de fundo ao FT numa frase: é difícil perceber quanto custa qualquer coisa relacionada com IA. A Amazon respondeu que está a experimentar, a aprender e a melhorar a forma como usa a tecnologia, classificou os exemplos como escolhidos a dedo, e está a introduzir revisões obrigatórias entre pares e tetos de despesa nos projetos de IA.

Comece pela aritmética, porque ninguém a publicou. Se 1,8 milhões de dólares representam uma derrapagem de 860 por cento, o orçamento aprovado andava pelos 190.000 dólares. É esse o número que um controlo deveria ter defendido.

Dois meses antes, o mesmo erro usava outro fato

A 29 de maio a Amazon fechou o KiroRank, um ranking interno na sua plataforma de desenvolvimento Kiro que ordenava o pessoal pelos tokens de IA consumidos. Tinha sido montado para impulsionar a adoção. O que impulsionou foi uma prática a que os trabalhadores chamaram tokenmaxxing: apontar agentes a trabalho de que ninguém precisava, para que a classificação mexesse. Dave Treadwell, vice-presidente sénior, escreveu ao pessoal num memorando que o ranking tinha sido construído com boas intenções e pediu que não se usasse IA só pelo gosto de usar IA.

Leia os dois episódios como um. Em maio a Amazon premiou o consumo e recebeu consumo. Em julho descobriu consumo que ninguém tinha autorizado e ninguém tinha lido. O ranking e o trabalho desgovernado não são falhas de disciplina separadas; são a mesma lacuna, a de que havia um contador a correr e não havia hábito de o ler.

A instrução está na substituição, não no encerramento. A Amazon não se limitou a apagar o ranking. Substituiu a métrica por implantações normalizadas, que contam o código assistido por IA que chega mesmo a produção.

Porque uma falha tarifada permanece invisível

O software convencional anuncia as suas próprias falhas. Um ciclo defeituoso esgota a memória e o processo morre, uma página esgota o tempo, dispara um alerta e alguém é acordado às três da manhã. Uma chamada a modelo mal configurada não faz nada disso. Tem sucesso. Devolve uma resposta, cobra os tokens e dá outra volta. Não há nenhuma quebra a detetar porque, do ponto de vista da plataforma, nada correu mal, e essa é exatamente a condição em que podem passar cinco meses.

Depois há três coisas que esticam a janela de deteção. A faturação é mensal, por isso a função financeira vê a forma de um problema semanas depois da despesa, e vê-a agregada. O preço é por token, portanto o custo escala com o volume e não com o número de instâncias, que é o eixo para que foi construída a maior parte do alerta de infraestrutura. E os agentes multiplicam tokens, porque um ciclo agêntico faz muitas chamadas ao modelo onde uma interface de conversa faz uma.

Para um operador europeu a consequência é a mesma seja qual for a região: o contador corre na conta de nuvem, a fatura chega em ciclo mensal, e nada pelo meio lhe diz que o trabalho deixou de ser útil em março.

Os controlos existiam e não estavam ligados

Esta é a parte incómoda da história, e a razão pela qual pertence a uma coluna de decisões e não a uma de tecnologia. As mitigações estiveram disponíveis na plataforma o tempo todo. A AWS publica inferência em lote a metade do preço por token da modalidade a pedido para trabalho que não precisa de resposta imediata, que é exatamente o perfil de um cruzamento em segundo plano de cinco meses. Oferece cache de instruções para que um contexto repetido não seja pago à tarifa cheia em cada chamada. Oferece escalões de modelo mais baratos e encaminhamento entre eles. Nada disto é exótico e nada exigia negociação.

Um trabalho que correu cinco meses sem que uma resposta fosse urgentemente necessária é a carga em lote de manual. Fazê-lo correr a pedido não é uma falha técnica, é uma decisão que ninguém foi chamado a tomar, porque a pessoa que configurou o trabalho não era a pessoa que via a fatura.

Desenhe contra essa separação. Quem pode arrancar um trabalho tarifado deve ver o seu custo corrente na mesma interface onde o arranca.

Quatro controlos antes de sair o seu próximo agente

Fixe um teto rígido por trabalho, não por conta. Um alerta de orçamento ao nível da conta diz-lhe que o total mexeu; não lhe diz que trabalho o mexeu, e quando um orçamento de conta dispara os cinco meses já passaram. Segundo, exija na aprovação uma resposta explícita a uma pergunta: isto tem de ser respondido agora? Se a resposta for não, é uma carga em lote e deve ser tarifada como tal.

Terceiro, ponha prazo de validade em cada trabalho de longa duração. Uma tarefa de cruzamento a correr desde março devia ter exigido que um humano a renovasse em abril. Quarto, meça o resultado. Se a pontuação de um projeto é o trabalho assistido por IA que entrou em produção, então uma implantação que nunca entrou pontua zero por muitos tokens que tenha consumido, e teria aparecido na primeira revisão mensal em vez da quinta.