Quando a IA deletou o ambiente de produção e a culpa foi do "usuário" - Startaideia

Artigo desenvolvido por: Gabriel Moreno 

Uma equipe da AWS pediu para o Kiro (agente de IA da Amazon) corrigir um bug no Cost Explorer, a ferramenta que os clientes usam para monitorar seus gastos na nuvem.

O agente avaliou a situação e tomou uma decisão: deletar e recriar o ambiente.

13 horas de indisponibilidade. Serviço cliente fora do ar. E nenhum checkpoint humano no meio do caminho.

A resposta oficial da Amazon? “Erro do usuário, não da IA.”

Isso não é um caso isolado. É um padrão que está se repetindo.

O mesmo aconteceu com o Amazon Q Developer, em um incidente separado, com a mesma lógica: engenheiro deu acesso autônomo ao agente, sem nenhum ponto de revisão humana antes de ações destrutivas serem executadas. Um funcionário sênior da AWS disse ao Financial Times que os incidentes eram “completamente previsíveis”. E esse detalhe importa muito.

E o ponto que mais me chama atenção em tudo isso: o processo de peer review obrigatório para acesso à produção só foi criado depois dos incidentes. Não dá para culpar o usuário por não seguir um processo que ainda não existia no momento em que ele tomou a decisão.

Por que isso importa para quem trabalha com automação e IA?

Estamos num momento em que as ferramentas estão avançando mais rápido do que a nossa capacidade de criar estruturas seguras ao redor delas. E o que aconteceu na AWS não é um problema exclusivo de grandes empresas de tecnologia. É exatamente o tipo de risco que qualquer time que está adotando agentes de IA ou automações mais autônomas precisa levar a sério.

Alguns pontos que todo profissional de automação deveria ter em mente:

1. Permissão é arquitetura, não só acesso Um agente de IA vai usar tudo que estiver disponível para ele se entender que é o caminho ótimo para atingir o objetivo. Não por malícia, mas porque o objetivo era “corrigir o bug” e deletar o ambiente parecia a solução mais direta. Dar permissão de delete em produção sem restrições determinísticas não é uma questão de confiança no modelo. É uma falha de design. A proteção precisa existir na estrutura, não na esperança de que o agente tome a decisão certa.
2. Prompts são sugestões, não barreiras Muita gente acredita que basta incluir instruções como “não delete ambientes críticos” ou “sempre peça confirmação antes de ações irreversíveis” para estar protegido. Não está. Essas instruções são ponderadas pelo modelo junto com todo o contexto disponível, e dependendo da situação, podem ser desconsideradas. A proteção real precisa ser estrutural, com bloqueios que independem completamente do raciocínio do modelo em tempo de execução.
3. Velocidade de adoção sem maturidade operacional é um incidente esperando acontecer A Amazon tinha uma meta interna de 80% de uso semanal do Kiro entre seus engenheiros. Liderança estava rastreando as taxas de adoção. Engenheiros que preferiam outras ferramentas foram direcionados a usar o produto interno. Quando a adoção é driven por estratégia de produto e não por julgamento de engenharia, atalhos começam a aparecer naturalmente. Revisões puladas. Permissões alargadas para facilitar o fluxo. E aí o risco deixa de ser individual e vira sistêmico.
4. Autonomia delegada exige governança proporcional Quanto mais poder de decisão você transfere para um sistema automatizado, mais robusto precisa ser o conjunto de limites ao redor dele. Isso não é novidade para quem trabalha com RPA há alguns anos. A diferença é que agentes de IA tomam decisões em contextos muito mais abertos e imprevisíveis do que um bot tradicional baseado em regras. O espaço de possibilidades é maior, e os erros consequentemente também podem ser.
5. “Quando der errado” é mais útil do que “se der errado” A pergunta certa não é “será que a IA vai errar?” porque a resposta já sabemos: vai, em algum momento. A pergunta certa é “quando ela errar, o impacto está contido? Consigo reverter? O dano é localizado ou cascateia?” Pensar o design da automação a partir do pior cenário possível é o que separa uma implementação madura de uma implementação que está acumulando risco silenciosamente.

No contexto de RPA e automação inteligente, a gente já convive com esse dilema há bastante tempo. Quanto mais um processo é automatizado, mais rigoroso precisa ser o trabalho feito antes: mapeamento de exceções, definição de limites de atuação, aprovações humanas nos pontos críticos, monitoramento contínuo. A diferença é que agora esse princípio precisa ser aplicado também para os agentes de IA, que operam com muito mais liberdade do que um bot convencional.

O que aconteceu na AWS não deveria surpreender ninguém. Deveria servir como referência concreta para uma conversa que muitos times ainda estão adiando: qual é o nível de autonomia que estamos confortáveis em delegar, e quais são as salvaguardas que precisam existir antes de chegar lá?

Isso não é argumento contra agentes de IA. É argumento por governança proporcional à autonomia que você está delegando.

O artigo original foi publicado no newsletter Athena Intelligence por Steve Henty. Vale a leitura completa.

Quais guardrails você tem nos seus processos automatizados hoje? Curioso para ouvir como outros times estão abordando isso. 👇