De acordo com relatos, um projeto interno da Amazon que utilizava o Claude Sonnet, da Anthropic, acumulou uma conta de US$ 1,8 milhão, ultra...
Relata-se que um projeto interno da Amazon que utilizava o Claude Sonnet, da Anthropic, acumulou uma conta de US$ 1,8 milhão, excedendo o orçamento planejado em 860%, permanecendo despercebido por cinco meses e, por fim, não chegando a ser lançado.
A tarefa em si parece bastante comum: corresponder informações de autores a listagens de produtos na plataforma de comércio eletrônico da Amazon.
O caso foi noticiado pelo Financial Times depois que um engenheiro sênior da Amazon discutiu vários casos de excedente de custos relacionados a IA em uma reunião interna de funcionários. Ele serve como um alerta útil para qualquer organização que esteja fazendo a transição do uso ocasional de chatbots para fluxos de trabalho automatizados, que podem gerar milhares ou milhões de chamadas pagas a modelos todos os dias.
Defeitos de software tradicionais geralmente desperdiçam horas de engenharia ou produzem saídas incorretas. Já defeitos em fluxos de trabalho de IA metrificados podem causar ambos os problemas e continuar gerando custos de tokens, ferramentas, armazenamento e computação a cada minuto em que permanecem ativos.
A lição não é que as empresas devam parar de usar IA, mas sim que processos de IA autônomos ou de alto volume precisam de controles financeiros tão claros quanto seus controles de segurança e qualidade.
De acordo com pessoas familiarizadas com o assunto, a Amazon usou o Claude Sonnet em um projeto destinado a corresponder informações de autores a listagens de produtos em sua plataforma de varejo.
Segundo os relatos, a implantação:
Engenheiros seniores descreveram alguns erros de codificação relacionados a IA como "catastroficamente caros".
A Amazon respondeu que está experimentando, aprendendo e melhorando sua forma de usar a tecnologia, inclusive como gerenciar a eficiência de custos. A empresa também afirmou que apresentar alguns casos isolados como prática comum não reflete com precisão o uso de IA em maior escala na organização.
Ambas as afirmações podem ser verdadeiras.
Esses incidentes podem envolver apenas uma pequena parcela das equipes da Amazon, mas também revelam um problema de controle que outras organizações deveriam levar a sério.
A reportagem inicial em chinês atribuiu o excedente a um programa sem limite de frequência de chamadas, que continuamente enviava requisições em um loop.
Essa explicação é plausível, mas ainda não foi confirmada pelos relatos públicos atuais.
O Financial Times descreveu erros de codificação, controles de gastos frágeis e atraso na detecção. Não publicou uma análise pós-incidente técnica mostrando:
A conclusão mais segura é mais cautelosa: uma implantação malsucedida do Claude Sonnet gerou uma conta enorme, e os sistemas de controle da Amazon não detectaram o problema em cinco meses.
A menos que a Amazon publique um relatório técnico do incidente, qualquer explicação mais detalhada deve ser tratada como especulação.
Excedentes
De acordo com informações, o mesmo relatório interno também discutiu pelo menos outros dois casos.
| Projeto | Custos não planejados relatados |
|---|---|
| Ferramenta de auditoria financeira | Aproximadamente US$ 541.000 |
| Projeto logístico para melhorar a velocidade de entrega | Aproximadamente US$ 134.000 |
Segundo relatos, o excedente logístico levou mais de duas semanas para ser descoberto.
Esses casos são menores do que o projeto de correspondência de autores de US$ 1,8 milhão, mas apontam para o mesmo padrão: quando nenhuma falha técnica força a interrupção do processo, sistemas de IA baseados em uso podem continuar acumulando custos.
Trabalhos em lote tradicionais podem falhar, esgotar a memória ou não passar nos testes.
Já processos de IA podem permanecer tecnicamente saudáveis enquanto entram em colapso financeiro.
Mesmo quando o projeto não produz mais resultados úteis, ele pode continuar recebendo respostas de API bem-sucedidas, gravando logs, chamando ferramentas, repetindo tarefas ou processando registros de baixo valor.
Os custos de aplicações tradicionais geralmente estão atrelados a unidades relativamente conhecidas:
Já os fluxos de trabalho de IA podem acumular simultaneamente múltiplas camadas de cobrança por uso:
Isso gera um efeito multiplicador.
Suponha que uma tarefa envie um prompt muito longo, gere uma grande quantidade de respostas, chame duas ferramentas, apresente erro e tente novamente, e passe o histórico completo para a próxima rodada. Se a aplicação processar milhões de registros, um pequeno erro de design pode se tornar extremamente caro.
Do ponto de vista operacional, a aplicação pode parecer normal. As requisições ainda retornam 200 OK. Os processos de trabalho permanecem ativos. As filas continuam diminuindo. A conta costuma ser o primeiro lugar onde o problema aparece.
Antes de iniciar um processo de IA automatizado, estime o custo por tarefa de negócio concluída.
Um modelo simplificado é o seguinte:
| Componente de custo | Como calcular |
|---|---|
| Custo de entrada | Tokens de entrada × preço de entrada do modelo |
| Custo de saída | Tokens de saída × preço de saída do modelo |
| Custo de ferramentas | Número de chamadas de ferramentas × preço da ferramenta |
| Custo de repetições | Número de tentativas falhas ou repetidas × custo médio por tentativa |
| Custo de infraestrutura | Computação, armazenamento, banco de dados, rede e logs |
| Custo de revisão humana | Tempo de revisão × taxa integrada com custo de mão de obra |
O indicador-chave não é apenas o custo por token.
Mas sim:
Custo total por resultado de negócio concluído com sucesso
Requisições mais baratas, se tiverem maior taxa de falhas, exigirem chamadas repetidas ou gerarem mais revisão humana, podem ainda assim resultar em um fluxo de trabalho mais caro.
Da mesma forma, um modelo mais forte, se concluir a tarefa em menos etapas, pode acabar tendo um custo total menor.
Cada fluxo de trabalho de IA em produção deve ter um responsável nomeado, que responda tanto pelo comportamento técnico quanto pelos gastos.
Esse responsável deve saber:
Quando um único processo de trabalho pode continuar enviando requisições indefinidamente, orçamentos vagos em nível de projeto não são suficientes.
Os orçamentos devem existir em múltiplos níveis:
| Nível | Exemplo |
|---|---|
| Organização | Limite mensal de gastos com IA |
| Equipe | Cota mensal de uma unidade de negócios |
| Aplicação | Orçamento de um produto ou fluxo de trabalho |
| Ambiente | Limites separados para desenvolvimento, pré-produção e produção |
| Tarefa | Custo máximo de um lote |
| Usuário ou locatário | Cota de uso por cliente |
| Sessão de agente | Máximo de tokens, etapas, ferramentas e tempo |
Os níveis mais baixos oferecem o mecanismo de freio mais rápido e eficaz.
Alertas de cobrança em nuvem são importantes, mas não substituem controles em nível de aplicação.
A aplicação deve parar ou exigir aprovação ao atingir os limites definidos.
Limites úteis incluem:
Esses controles devem ser desativados por padrão.
Se o serviço de rastreamento de custos não estiver disponível, ou se a aplicação não puder determinar o orçamento restante, o comportamento mais seguro é pausar em vez de continuar indefinidamente.
Agentes autônomos não devem controlar a autoridade final de gastos de si mesmos.
Um serviço independente deve ser capaz de:
Mesmo que o agente entre em um loop de repetições ou produza mensagens de status enganosas, o interruptor de emergência deve permanecer acessível.
Teste antes do ambiente de produção.
Controles que nunca foram usados são apenas teoria.
Organizações que usam o Amazon Bedrock podem ativar o registro de chamadas ao modelo para invocações suportadas do bedrock-runtime.
A AWS afirma que esses logs podem incluir dados de requisição e resposta, metadados, identificadores de modelo, identificadores de requisição, informações de identidade e uso de tokens. Os destinos de log podem incluir o Amazon CloudWatch Logs e o Amazon S3.
O registro de chamadas está desativado por padrão.
A equipe deve habilitar apenas os dados necessários para a observabilidade e aplicar controles adequados de privacidade, segurança, retenção e mascaramento. Prompts e saídas podem conter informações sensíveis da empresa ou de clientes.
No mínimo, os registros de monitoramento de custos devem conter:
Isso permite associar a fatura a tarefas específicas, em vez de descobrir um total enorme apenas na revisão financeira mensal.
O AWS Budgets pode rastrear custos ou uso em relação a limites definidos e enviar notificações. As ações de orçamento também podem aplicar controles, como políticas IAM ou políticas de controle de serviço, quando os limites são excedidos. Dependendo da configuração, as ações podem ser executadas automaticamente ou aguardar aprovação humana.
Um detalhe importante específico da AWS pode facilmente passar despercebido.
A documentação do AWS Cost Anomaly Detection afirma que esse serviço não monitora produtos de terceiros vendidos por meio do AWS Marketplace, incluindo modelos de linguagem de terceiros oferecidos por meio do Amazon Bedrock, como o Anthropic Claude.
Esses custos ainda aparecem no Cost Explorer e na fatura, mas a AWS recomenda usar o AWS Budgets para alertar sobre esses gastos.
Os orçamentos podem usar filtros de entidade de cobrança para rastrear com mais precisão os custos do Marketplace.
Esse é exatamente o tipo de detalhe de configuração que pode gerar uma falsa sensação de segurança. A empresa pode ter habilitado a detecção de anomalias e acreditar que todos os custos de modelo estão cobertos, mas uma categoria específica de cobrança não está incluída.
A documentação da AWS afirma que o status do orçamento é atualizado várias vezes ao dia.
A documentação também alerta que os custos podem continuar aumentando antes ou depois de a notificação ser entregue.
Isso significa que o AWS Budgets é útil para a governança financeira, mas, isoladamente, pode não interromper com rapidez suficiente um agente de alto throughput.
A pilha de controles deve incluir:
Quanto mais rápido o fluxo de trabalho gasta dinheiro, mais próximos do ponto de chamada os controles precisam estar.
O AWS Cost Anomaly Detection usa modelos de aprendizado de máquina para identificar padrões de gastos anormais e ajudar a localizar possíveis causas raiz.
A AWS afirma que o serviço avalia os dados de cobrança processados aproximadamente três vezes ao dia.
Ele pode detectar com eficácia crescimentos inesperados em serviços AWS, contas, regiões, tipos de uso e tags de alocação de custos.
Para sistemas de IA, ele pode identificar anomalias em custos de infraestrutura de suporte envolvendo computação, armazenamento, banco de dados ou rede.
No entanto, as equipes devem lembrar da limitação do Marketplace mencionada acima e criar AWS Budgets separados para custos de modelos de terceiros quando necessário.
O Amazon Bedrock aplica cotas de serviço à inferência de modelos, incluindo limites baseados em tokens para modelos e endpoints suportados.
Descreva sua ideia uma vez e o We0 AI pode gerar um site de apresentacao, paginas e CMS, alem de ajudar a atrair clientes e trafego apos o lancamento.
Uma geração completa de projetos para registro gratuito
Melhor para experimentar um fluxo de geração completo e ver rapidamente um primeiro rascunho do projeto.
As cotas podem impedir throughput ilimitado, mas não foram projetadas como orçamentos financeiros precisos.
As cotas ainda podem permitir gastos muito além dos limites projetados do projeto. Por outro lado, aumentar cotas para resolver problemas de capacidade de produção pode remover inadvertidamente um limite de segurança útil.
Portanto, alterações de cotas devem exigir:
Limites de taxa e tokens devem ser tratados como parte do design de risco do sistema, e não apenas como obstáculos à escalabilidade.
Para aplicações que chamam a Anthropic diretamente, o console da Anthropic oferece relatórios de custo e uso.
Os limites da API da Anthropic podem incluir solicitações por minuto, tokens de entrada por minuto, tokens de saída por minuto e limites de gastos associados ao nível de uso.
Esses limites podem reduzir o throughput não controlado, mas ainda devem ser complementados com controles no nível da aplicação.
Organizações com múltiplas equipes também podem implantar um gateway de LLM entre as aplicações e o provedor de modelos. O gateway pode centralizar autenticação, rastreamento de uso, orçamentos, limites de taxa, roteamento de modelos e logs de auditoria.
O gateway se torna um componente crítico de segurança e, portanto, deve ser operado e revisado com o mesmo rigor de qualquer outra camada de acesso de produção.
Relatos indicam que um projeto da Amazon tentou executar uma tarefa de correspondência de dados em larga escala.
Um padrão de implantação mais seguro é:
Não extrapole com base apenas na média dos registros.
Os documentos mais longos, registros com falha de correspondência, casos ambíguos, tentativas e loops de agentes tendem a dominar o custo total.
Use estimativas por percentil, como custo P50, P95 e P99 por tarefa.
O fluxo de trabalho deve parar quando chamadas adicionais ao modelo não forem mais economicamente justificáveis.
Para um sistema de correspondência de autores, métricas úteis podem incluir:
Um processo que custa US$ 0,02 por solicitação pode parecer barato.
Se ele exigir 50 chamadas, metade dos registros falhar e o restante for para revisão manual, a economia real pode ser muito ruim.
Nem todo registro exige um modelo de ponta.
Um pipeline consciente dos custos pode usar:
Para projetos de correspondência de dados, software tradicional pode resolver a maioria dos casos de forma mais barata e determinística.
O LLM deve ser usado apenas quando a ambiguidade linguística realmente exigir, e não aplicado automaticamente a todas as linhas.
O próprio guia de preços da Anthropic recomenda escolher o modelo certo, usar cache de prompts para contextos repetidos, adoção de processamento em lote para trabalhos não urgentes e monitoramento dos padrões de uso.
As tentativas são uma fonte comum de gastos ocultos.
Uma solicitação com falha pode ser repetida pelo aplicativo, sistema de filas, SDK, gateway, gerenciador de workers, agente ou orquestrador do fluxo de trabalho.
Quando várias camadas tentam novamente de forma independente, uma única tarefa lógica pode gerar múltiplas solicitações pagas.
Defina uma política de tentativas unificada, contendo:
o número de tentativas
Erros não devem criar loops econômicos infinitos.
Scripts de teste não devem herdar limites de nível de produção.
Use contas ou workspaces separados, chaves de API, papéis IAM, orçamentos, cotas, logs, fontes de dados e permissões de rede.
Os ambientes de desenvolvimento devem ter limites de gastos deliberadamente baixos.
Um protótipo que entra em loop acidentalmente deve falhar com uma fatura pequena, e não obter cotas de produção de nível empresarial.
O incidente envolveu um projeto auxiliado por IA, mas a questão central não é se o código foi gerado por um modelo.
A questão importante é se o código pode gastar dinheiro.
Qualquer componente capaz de iniciar solicitações pagas a modelos deve passar por revisão de:
Os testes unitários devem incluir cenários de falha econômica.
Exemplos incluem: o modelo nunca retorna uma resposta válida, entrega repetida de tarefas, falha do worker após chamada paga, erros repetidos de limite de taxa, crescimento do contexto a cada turno devido a saídas de ferramentas e indisponibilidade do serviço de estimativa de custos.
Um caminho normal funcionalmente correto está longe de ser suficiente.
Um responsável técnico designado responde pelos gastos.
O uso esperado e o custo por resultado bem-sucedido estão documentados.
[ ] Os ambientes de desenvolvimento, pré-produção e produção possuem orçamentos independentes.
Cada tarefa tem limites máximos de número de solicitações, tokens, etapas, tentativas e tempo de execução.
Cada sessão de agente tem um orçamento em dólares americanos.
Serviços não relacionados a agentes podem interromper fluxos de trabalho.
As tarefas são pausadas quando não é possível ler o orçamento restante.
O trabalho duplicado é evitado por meio de idempotência.
Cada chamada de modelo é atribuída a equipe, projeto, usuário e tarefa.
O uso de entradas, saídas, cache, ferramentas e tentativas é registrado.
Alertas são definidos tanto para a taxa de gastos quanto para o gasto total.
Uma revisão diária é habilitada durante o lançamento inicial em produção.
As equipes estão cientes dos itens de custo não cobertos pela detecção de anomalias.
O custo é medido por resultado de negócio bem-sucedido.
Código comum e modelos menores são usados quando apropriado.
Os custos de pior caso e de alto percentil foram testados.
Os custos de revisão humana estão incluídos.
O fluxo de trabalho é interrompido quando chamadas adicionais não agregam mais valor.
O código gerado por IA passa por revisão humana.
Aumentos de orçamento e cotas exigem aprovação.
O interruptor de emergência foi testado.
A resposta a incidentes inclui partes interessadas financeiras e técnicas.
As equipes revisam os gastos após cada mudança significativa de modelo ou prompt.
Segundo relatos, engenheiros da Amazon estão construindo salvaguardas automatizadas para futuros projetos de IA.
Essa é a direção certa.
Mas a automação precisa existir em múltiplas camadas.
Um sistema de controle maduro deve combinar limites rígidos no nível do aplicativo, limites de modelo e gateway, orçamentos em nuvem, ações automatizadas, registros de uso, painéis financeiros, aprovações humanas e revisões periódicas.
A empresa também removeu um ranking interno que incentivava os funcionários a maximizar o uso de sua ferramenta de desenvolvimento Kiro. Segundo o Financial Times, o ranking incentivava o “tokenmaxxing”, no qual os funcionários aumentavam o consumo de tokens para subir no ranking.
Isso é um lembrete útil: incentivos podem minar o controle de custos.
Se os funcionários são recompensados por usar mais IA, em vez de criar valor comercial mensurável, o uso aumentará mesmo que a produção não melhore.
As organizações devem recompensar problemas resolvidos, melhorias de qualidade, tempo economizado, receita gerada, risco reduzido e redução do custo por unidade de produção.
A contagem de tokens é uma métrica de entrada, não uma métrica de produtividade.
O Financial Times noticiou que um projeto interno da Amazon que usava o Claude Sonnet gerou uma conta acumulada de US$ 1,8 milhão. O projeto, que visava combinar informações de autores com listagens de e-commerce, estourou o orçamento em 860% e não foi lançado.
De acordo com relatos públicos, a Amazon não tinha controles de gastos adequados, e erros de codificação foram um dos fatores que contribuíram para o problema. A Amazon ainda não publicou uma análise post-mortem técnica para identificar as falhas específicas ou falhas de monitoramento.
Essa explicação apareceu em algumas reportagens secundárias, mas ainda não foi confirmada nas principais reportagens. O número exato de solicitações, a lógica de tentativas, o volume de tokens e os defeitos no código-fonte não foram divulgados.
Sim. Aparentemente, a mesma apresentação interna também incluía custos inesperados de aproximadamente US$ 541 mil em um projeto de auditoria financeira e US$ 134 mil em um projeto de logística.
A documentação da AWS indica que o Cost Anomaly Detection não monitora produtos de terceiros no AWS Marketplace, incluindo os modelos Anthropic Claude no Bedrock. A AWS recomenda o uso do AWS Budgets para gerenciar esses custos e, quando aplicável, filtros de entidade de cobrança.
Somente ele não. A AWS afirma que as informações de orçamento são atualizadas várias vezes ao dia e que os custos podem continuar aumentando antes e depois do período de notificação. Aplicações de alto tráfego precisam de limites rígidos no nível de solicitação e um interruptor de emergência independente.
Não. Limites de taxa controlam a taxa de transferência, enquanto controles de orçamento gerenciam o custo aceitável. Um fluxo de trabalho pode operar dentro dos limites de taxa e ainda assim exceder drasticamente o orçamento planejado ao longo de semanas ou meses.
Definir um orçamento rígido para cada sessão de agente incluindo solicitações, tokens, ferramentas, tentativas e tempo. Aplicar esse orçamento fora do agente e ter uma forma testada de interromper imediatamente o fluxo de trabalho.
com/bedrock/latest/userguide/model-invocation-logging.html): Guia oficial de configuração e tratamento de dados para registro de invocações do Bedrock.
Segundo relatos, um projeto interno da Amazon usando Claude Sonnet custou 1,8 milhão de dólares, excedendo o orçamento em 860%, passou cinco meses sem ser detectado e nunca chegou a ser colocado em produção. Outros projetos de IA teriam gerado despesas inesperadas de centenas de milhares de dólares.
Os registros públicos não confirmam que o evento principal foi causado por um loop infinito de solicitações. O que os registros confirmam é a lacuna entre a velocidade dos gastos dos fluxos de trabalho de IA e a velocidade com que as organizações detectam problemas.
As empresas devem combinar rastreamento de solicitações individuais, orçamentos em nível de tarefa, limites de tokens e ferramentas, novas tentativas controladas, roteamento de modelos, orçamentos de nuvem, ações automatizadas e interruptores de emergência que agentes não possam desativar.
**
A regra mais segura é simples: nenhum processo de IA deve operar por cinco meses sem provar repetidamente que ainda é útil, está dentro do orçamento e foi autorizado a continuar.
Comece com uma frase e tenha um site completo em minutos.
