A IA agêntica geralmente não faz backup antes de agir

Boa parte do material que vasculho todos os dias no arXiv e em outras fontes é bastante árida, até para quem tem sensibilidade de nerd; por isso, estou sempre à procura de publicações que me envolvam emocionalmente, como usuário, defensor ou vítima da IA.

Hoje, quem me arrepiou foi uma nova colaboração acadêmica dos EUA, que examina até que ponto os modelos de IA agêntica de fronteira queimam as pontes antes de tomar medidas prejudiciais — e mais rápido do que se consegue digitar “PARE!” (uma dica: deixe a palavra à mão na área de transferência).

Isso, tirado de contexto do novo artigo, aconteceu comigo recentemente, devido à obediência cega às instruções do ChatGPT, e sem que me ocorresse duplicar primeiro todo o ambiente virtual:

Interpretação do novo artigo: um momento angustiante que muitos de nós já vivemos ao instalar frameworks de ponta ou até distribuições populares que não respeitam os ambientes não convencionais nos quais podem acabar sendo usadas. Fonte

Neste exemplo assustador e familiar demais, o robô tem uma justificativa razoável, pois não é habitual examinar todas as possíveis consequências de instalar uma nova biblioteca em um framework frágil e implacável. No entanto, o novo artigo argumenta que talvez isso devesse ser feito; e, como alguém que ainda aperta CTRL+S com frequência, mesmo em ambientes de salvamento automático configurados para ignorar essa tecla (obrigado, trauma de perda de dados dos anos 1990), tenho de concordar.

Certamente, uma atitude mais ponderada e cautelosa teria sido bem-vinda para Alexey Grigorev, fundador da plataforma educacional DataTalks.Club, cujo agente Claude Code apagou a infraestrutura de produção e os backups durante uma migração de servidor em março passado, resultando na perda de dois anos e meio de dados do site.

Outros incidentes recentes de imprudência agêntica desse tipo incluem um agente Cursor apagando o banco de dados de produção e os backups da PocketOS, provedora de software para locadoras de veículos, em abril, o que interrompeu as reservas dos clientes por mais de dois dias; e um agente de e-mail OpenClaw apagando mensagens da caixa de entrada de um pesquisador de IA da Meta em fevereiro, apesar das repetidas instruções para parar.

Agênticos ou não, os LLMs de fronteira têm muita dificuldade para agir com ponderação e cautela, a ponto de a busca por soluções para esse problema ter se tornado uma linha de pesquisa própria na literatura.

Faça um backup antes

Bem, os autores do novo artigo* desenvolveram um plug-in multiagente para ambientes de execução agênticos, capaz de operar junto com a IA convidada e obrigá-la a criar backups quando necessário:

Visão geral do problema dos backups abordado pelo estudo e da solução proposta. Em 205 cenários, seis modelos de IA de fronteira fizeram backup do estado crítico em apenas 15,2% das tarefas. Já o sistema BackUpper dos pesquisadores cobriu todas as ações críticas, e os dados restaurados tiveram, em média, 92,2% de similaridade com os originais (veja abaixo por que é difícil chegar a 100%).

Um dos aspectos mais marcantes do novo estudo é o quanto os modelos de fronteira deixam de fazer backup antes de tomar medidas potencialmente perigosas. Os pesquisadores constataram que o GPT-5.6-Terra fez backup dos dados críticos em apenas 4,4% dos casos; o GPT-5.6-Sol, em apenas 5,9% dos casos testados; e o Gemini 3.7-Flash, em apenas 2,4% dos casos.

Até mesmo o modelo com melhor desempenho, Claude Opus-5, deixou de fazer backup dos dados críticos em mais de um terço dos casos testados.

O artigo afirma^†:

‘Entre seis modelos de fronteira, os agentes concluem, em média, 86,1% das tarefas, mas fazem backup do estado antes de momentos de arrependimento em apenas 15,2%. O GPT 5.6-Sol no Codex faz isso em apenas 5,9% das tarefas, e o DeepSeek V4-Pro no Hermes, em apenas 2,9%.

‘Essas descobertas mostram que a capacidade dos agentes atuais de reconhecer quando é preciso fazer backup continua limitada e que é necessário oferecer suporte específico para backups.’

A solução dos autores, batizada de BackUpper, opera junto com o agente, como um processo em segundo plano dentro do ambiente de execução, verificando o que ele está prestes a fazer e criando primeiro um backup se houver risco de perder algo útil.

Em operações cotidianas, como atualizar software, o sistema segue um conjunto de regras simples; em situações mais complexas, recorre a um modelo de IA menor para determinar o que precisa ser salvo.

Nos testes, o BackUpper cobriu todas as ações críticas, e os dados restaurados apresentaram 92,2% de similaridade com os originais, a um custo adicional de US$ 0,014 por tarefa — pouco nesse contexto, mas um gasto significativo para LLMs de ponta que atendem bilhões de clientes; talvez por isso um serviço externo desse tipo, ou a inclusão nativa dessa funcionalidade nos harnesses, seja uma forma mais provável de melhorar a situação do que esperar uma solução nativa das gigantes da tecnologia (que poderiam razoavelmente repassar os custos adicionais aos consumidores, seja por meio de aumentos de preços, seja por meio da inflação de tokens).

A estrutura se baseia no RegretBench, um benchmark com 205 tarefas, construído a partir de casos reais em que pessoas perderam dados que depois gostariam de ter salvado. Ele testa se os agentes de IA têm a previsibilidade necessária para preservar esses dados antes de fazer alterações potencialmente irreversíveis. Os incidentes reunidos foram extraídos de discussões e relatos on-line em plataformas como X.com, GitHub e Stack Overflow.

Um esquema de como o RegretBench transforma incidentes do mundo real em cenários de teste. Cada caso documentado é reconstruído com a ação que causou a perda, um ambiente de trabalho realista e uma sequência de instruções. Neste exemplo, a atualização do ipykernel substitui silenciosamente uma versão existente do traitlets, permitindo que o agente conclua a tarefa — mas sem deixar nenhuma maneira de recuperar a instalação original.

Embora 92% possa ser um resultado desanimador para quem busca a perfeição, os autores observam que há obstáculos técnicos à recuperação de certos tipos de dados:

“A lacuna em relação à restauração perfeita se deve principalmente a dois motivos. Alguns campos, como os IDs de publicações, costumam ser gerados novamente pelos serviços quando os dados são gravados e, muitas vezes, não podem ser reproduzidos. Outras diferenças decorrem de metadados menores, como os indicadores de leitura de e-mails, que raramente estão envolvidos nos momentos de arrependimento.”

Nos testes, foi possível recuperar 33,8% de similaridade com o estado original após o dano já ter ocorrido, em comparação com apenas 14,3% sem restauração.

O artigo sugere que, no futuro, a capacidade de identificar quando é preciso fazer backups poderia ser aprimorada por meio de treinamento, enquanto versões posteriores do BackUpper poderiam ser ensinadas a ignorar ações de baixo risco e ampliar a proteção a agentes que usam a web e computadores.

O BackUpper oferece suporte a Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness e OpenClaw; os autores disponibilizaram o código para download, junto com o conjunto de dados relacionado (embora seja necessário solicitar autorização por meio de um formulário); além disso, há algumas informações adicionais e um vídeo explicativo bem curto e simples no site do projeto.

Método

Na elaboração do RegretBench, foram deliberadamente excluídos os dados já protegidos pelos sistemas de backup integrados dos agentes, para que fosse possível testar se os próprios agentes sabiam quando fazer um backup. Em seguida, os cenários de teste foram elaborados com a ajuda de Claude Opus-5 e GPT-5.6-Sol e revisados manualmente para garantir que funcionassem e representassem com precisão os incidentes originais.

Os 205 testes do RegretBench abrangem cinco áreas: operações de terminal; bancos de dados; aplicações web; e-mail; e DevOps. Os incidentes tiveram origem principalmente em plataformas de desenvolvimento de software e produtividade (44,4%); discussões sociais ou comunitárias (39%); e arquivos e reportagens da mídia (16,6%):

As fontes dos incidentes do mundo real reunidos no RegretBench, divididas em três categorias. 

Os seis modelos de ponta avaliados foram Claude Opus-5 e Claude Sonnet-5, no Claude Code; GPT-5.6-Sol e GPT-5.6-Terra, no Codex; e Gemini 3.7-Flash e DeepSeek V4-Pro, no Hermes.

Foram usadas as configurações padrão de raciocínio em todos os testes, e a proteção automática de backup foi limitada a instantâneos do espaço de trabalho — permitindo atribuir aos próprios agentes qualquer backup adicional.

Dois avaliadores de IA, ambos baseados no Claude Sonnet-5, foram usados para avaliar o desempenho. A taxa de aprovação de tarefas (PR) foi calculada com base na proporção de tarefas em que todas as solicitações do usuário foram atendidas. Na avaliação dos backups, cada modificação fora do espaço de trabalho (OOW) foi examinada para verificar se informações suficientes haviam sido preservadas previamente para permitir a recuperação.

As métricas de backup utilizadas foram a Regret Moment Backup Rate (RMBR), que reflete as ações específicas associadas a perdas de dados documentadas; e a Taxa de backup fora do espaço de trabalho (OWBR), que reflete todas as alterações feitas fora do diretório de trabalho do agente.

As avaliações do avaliador de cópias de segurança também foram comparadas com anotações humanas, resultando em 95,3% de concordância.

Resultados

Para determinar se a baixa conscientização sobre cópias de segurança era causada pelos modelos de IA ou pelos frameworks que os executavam, Claude Opus-5, GPT-5.6-Sol e DeepSeek V4-Pro foram avaliados primeiro, cada um, em 60 tarefas do RegretBench no Claude Code, Codex e Hermes.

A proporção de tarefas em que dados críticos foram copiados variou pouco entre os frameworks, sugerindo que os próprios modelos eram os principais responsáveis. A relação entre a capacidade geral de IA e a conscientização sobre cópias de segurança também foi examinada usando GPT-5.4, GPT-5.5 e GPT-5.6-Sol.

Apesar das sucessivas melhorias na capacidade geral, não foi constatada uma melhora correspondente na conscientização sobre cópias de segurança:

Resultados dos testes do RegretBench com seis modelos de IA. À esquerda: taxas de conclusão de tarefas comparadas com a proporção de ações críticas copiadas previamente, revelando altas taxas de sucesso, mas pouca conscientização sobre cópias de segurança na maioria dos modelos. À direita: número médio de chamadas de ferramentas por tarefa, com as operações de cópia de segurança destacadas em azul. Claude Opus-5 teve a maior taxa de cópias de segurança, mas 8,9% de suas chamadas de ferramentas foram dedicadas a elas.

A relação entre a capacidade geral de IA e a conscientização sobre cópias de segurança também foi examinada usando GPT-5.4, GPT-5.5 e GPT-5.6-Sol. Apesar das sucessivas melhorias na capacidade geral, não se observou uma melhora correspondente na conscientização sobre cópias de segurança.

BackUpper

O BackUpper usa quatro níveis de proteção, cada um com custos de recursos variados: o nível 1 substitui comandos destrutivos por alternativas reversíveis, como mover arquivos para a lixeira; o nível 2 associa operações a comandos de cópia de segurança, como registrar as versões dos pacotes antes de uma atualização; o nível 3 cria instantâneos dos arquivos afetados no espaço de trabalho; e o nível 4 usa um subagente GPT-5.6-Luna para identificar e preservar dados afetados por operações mais complexas.

Com o BackUpper ativado, todas as ações que alteravam o estado foram protegidas nos seis modelos, em comparação com taxas médias de cópias de segurança de 15,2% para ações críticas e 17,4% para outras alterações sem a ferramenta:

Resultados de cobertura de cópias de segurança e restauração com o BackUpper. À esquerda: as barras azuis e laranjas mostram as taxas de cópias de segurança de cada modelo para ações críticas e outras alterações fora do espaço de trabalho. Contornos tracejados em verde-escuro indicam a precisão da restauração; contornos pontilhados em verde-claro mostram 100% de cobertura de cópias de segurança com o BackUpper. À direita: a precisão da restauração em cinco categorias de ferramentas é comparada usando o BackUpper (verde); a recuperação posterior com Claude Opus-5 (roxo); e nenhuma restauração (cinza). Em todas as categorias, o BackUpper alcançou a maior precisão.

Dos backups considerados bem-sucedidos pelo avaliador automatizado, 94% também foram confirmados como bem-sucedidos por revisores humanos.

O estado original foi recuperado com similaridade média de 92,2%, em comparação com 33,8% com Claude Opus-5 e 14,3% sem recuperação (veja a imagem acima). As discrepâncias restantes foram atribuídas, em grande parte, a identificadores gerados novamente e a pequenos metadados, incluindo os indicadores de leitura de e-mails, como observado anteriormente.

Faça você mesmo..?

Quando os agentes receberam instruções detalhadas para fazer suas próprias cópias de segurança, 81,4% das ações críticas foram protegidas, em comparação com 100% com o BackUpper. Três quartos das falhas foram atribuídas a cópias de segurança que não continham informações suficientes para a recuperação.

Taxas de cópias de segurança comparadas entre cinco abordagens, testadas em 205 tarefas com seis modelos de IA. O gráfico à esquerda mostra as cópias feitas antes de ações das quais os agentes se arrependeram depois; o da direita, a proteção de outras alterações fora do espaço de trabalho. O BackUpper alcançou cobertura total nas duas categorias, em comparação com 81,4% e 80,5% quando os agentes receberam instruções detalhadas para fazer cópias de segurança.

Com o cache de prompts, o custo das cópias de segurança caiu de US$ 0,344 para US$ 0,014 por tarefa, e a latência diminuiu 31,7%. Foram necessários sete vezes menos tokens, em grande parte porque as operações rotineiras foram realizadas sem assistência de IA.

Em 40 tarefas adicionais de Terminal-Bench 4 e DeepSWE, GPT-5.6-Sol e Claude Opus-5 alcançaram 100% de cobertura de backup, sem reduzir as taxas de conclusão das tarefas.

As três políticas seletivas de backup avaliadas foram Alto Impacto, para mudanças significativas; Além da Solicitação, para mudanças fora das instruções do usuário; e Trabalho Humano, para material produzido por humanos. Nesse caso, a pontuação F1 média alcançada em comparação com os julgamentos humanos foi de 84,5%.

O BackUpper também foi testado quanto à sua capacidade de aprender regras de backup reutilizáveis. Após 30 tarefas adicionais de terminal, a cobertura baseada em regras aumentou de 14,9% para 31,2%, reduzindo a dependência do subagente GPT-5.6-Luna.

Conclusão

Comecei a experimentar com IA agêntica mais tarde do que deveria, considerando meu trabalho; mas o estado manifestamente pré-alfa da capacidade dos agentes de se conterem me assustou e me afastou da ideia até poucas semanas atrás, quando finalmente decidi liberar o Codex em uma máquina virtual do Windows.

Mesmo trabalhando em uma máquina virtual, delimito minhas instruções com muito cuidado, ciente da tendência de Astra a avançar sem reservas e apenas pedir desculpas quando já não há como recuperar dados perdidos ou código danificado; e parte do framework Python que estou desenvolvendo ali é uma função incremental, acionada com um clique, para ‘salvar .7z no compartilhamento de rede’ , que compacta e faz backup de todo o framework e que aciono com frequência.

Estamos nos primórdios da IA agêntica; sem uma atenção cansativa e meticulosa aos detalhes, o resultado é: “use e perca”. Os regimes de backup para agentes agênticos não só ainda não foram formalizados, como nem sequer foram formulados.

* Intitulado Faça backup antes de se arrepender: medindo a conscientização sobre backups e automatizando-os em agentes de programação.

^† Ênfases dos autores, não minhas; e todos os hiperlinks foram inseridos por mim com base nas citações no texto dos autores.

Publicado originalmente na quinta-feira, 22 de outubro de 2026