Melhor agente de IA resolveu só 60% das tarefas de DevOps na nuvem, e 80% das falhas vêm de erros de raciocínio

Imagine pedir a um agente de IA que revogue o acesso de um funcionário desligado na AWS. Um engenheiro experiente verificaria usuários, funções, chaves e contas de serviço. O agente pode desativar uma única conta, relatar "pronto" e deixar abertos os demais caminhos de entrada.

É exatamente esse tipo de falha que o CloudOpsBench revelou. Trata-se de um novo benchmark aberto, ou seja, um conjunto de tarefas padronizadas para comparar modelos. O melhor modelo testado, o Claude Fable 5.

1, resolveu apenas 60% das tarefas, e o GPT-6 Astra resolveu 53%. Cerca de 80% dos fracassos não se devem ao fato de o modelo desconhecer a nuvem, mas a um raciocínio deficiente: ele avalia mal o tamanho do trabalho, não verifica todos os serviços necessários ou para cedo demais. Se você pensa em entregar a um agente operações em infraestrutura de nuvem, esses números indicam onde colocar proteções.

O que o CloudOpsBench avalia

O benchmark foi criado por uma equipe liderada por Ang Chen, da Universidade de Michigan. A versão 1.0 inclui 45 tarefas na AWS, escritas por engenheiros de DevOps experientes. O conjunto cobre o trabalho típico da área: consertar um serviço, excluir recursos, restringir permissões de acesso, publicar uma atualização e desativar um projeto.

Cada tarefa é executada da mesma forma na nuvem real da AWS e em um emulador. O emulador é útil para rodadas repetíveis, sem risco para a infraestrutura de verdade. O projeto está publicado no GitHub sob a licença Apache 2.0 e acompanha uma análise detalhada dos erros. Extensões para GCP, Azure e OCI (Oracle Cloud Infrastructure) estão planejadas.

Onde os agentes falham

Mesmo o líder falha em uma parte considerável das tarefas: o Claude Fable 5.1 teve 60% de sucesso, e o GPT-6 Astra, 53%. Nenhum modelo deu conta de todas as tarefas. Segundo os autores, na maioria dos casos o gargalo é justamente o raciocínio.

Cerca de 80% das falhas se encaixam em três cenários:

• o agente avalia incorretamente o escopo da tarefa;
• não verifica todos os serviços relacionados;
• para antes de o trabalho terminar.

É exatamente o caso do acesso do funcionário desligado: o agente conhece os comandos, mas não confirma que o quadro foi fechado por completo.

Os outros cerca de 20% dos erros são ações incorretas. Parte delas tem consequências irreversíveis para a infraestrutura. Um recurso excluído, por exemplo, não volta, e aí o custo do erro é maior do que o de um trabalho inacabado.

O que fazer na prática

As conclusões abaixo são recomendações nossas, não resultados dos autores do benchmark.

Primeiro: limite as permissões. Em uma conta de produção, é razoável dar ao agente acesso de leitura e um conjunto restrito de operações seguras, e exigir confirmação humana para excluir recursos, alterar políticas de acesso e desativar projetos.

Segundo: não aceite o "pronto" na palavra. Como uma causa frequente de falha é a parada precoce, é preciso uma verificação independente do resultado: um script ou uma revisão que liste os serviços afetados e os compare com o estado esperado.

Terceiro: teste com tarefas próximas das suas. Como o CloudOpsBench é aberto e funciona em um emulador, dá para usá-lo para comparar modelos ou variações de prompts sem arriscar a nuvem real.

Limitações

Um conjunto de 45 tarefas é pequeno e, por ora, cobre apenas a AWS, então os números valem para esta versão específica do benchmark e para os modelos testados. Na sua infraestrutura, com convenções próprias, os resultados podem ser diferentes. Ainda assim, a conclusão geral é clara: o que mais atrapalha os agentes em operações de nuvem é o planejamento e a autoverificação, não o conhecimento dos comandos. Até que essas habilidades melhorem, o humano continua sendo a última linha de defesa antes de ações irreversíveis.