O agente que apagou um banco de produção: 5 regras pra não deixar a IA solta demais
por Dudu ·
Um agente de IA com acesso total pode apagar o que não devia, e foi o que aconteceu com um desenvolvedor em julho de 2026. O Bruno Lemos contou no X que o GPT-5.6 apagou o banco de dados de produção dele. Dias depois, a OpenAI explicou em que condições o problema acontecia. O caso vale mais pela lição de governança do que pelo modelo, que envelhece rápido.
Este post resume o que aconteceu e lista as 5 regras pra rodar agentes sem esse tipo de susto. Ele conversa com outro tema que já tratamos por aqui: o agente que entra nos sites logado com a sua conta.
O que aconteceu
O Bruno Lemos relatou o caso em 13 de julho de 2026: “GPT-5.6 Sol just deleted my whole production database. That’s it. Not a joke. This had never happened to me before, with any other model, ever. It’s not safe.”
Em tradução livre: o modelo apagou o banco de dados de produção inteiro, não era piada e nunca tinha acontecido com outro modelo. O post passou de 1 milhão de visualizações. Dias antes, o Matt Shumer já tinha relatado que o modelo apagou quase todos os arquivos do Mac dele usando o Codex.
O que a OpenAI explicou
O Tibo, da OpenAI, respondeu em 16 de julho que a empresa investigou alguns relatos de arquivos apagados de forma inesperada.
Segundo ele, o problema aparecia com mais frequência quando o modo de acesso total estava ligado e o Codex rodava sem as proteções de sandbox, incluindo sem a revisão automática. Nessas condições, o modelo tentava redefinir uma variável do sistema pra criar uma pasta temporária e, por um erro, apagava a pasta principal do usuário no lugar. O Tibo disse que isso acontece muito raramente e prometeu publicar uma análise detalhada do incidente.
A lição: o problema é a permissão
O ponto em comum dos casos é o agente rodando com mais permissão do que a tarefa exigia.
Todo modelo erra de vez em quando. O tamanho do estrago depende do que ele pode fazer quando erra. Um agente que só lê arquivos não apaga nada. Um agente com acesso total, sem sandbox e sem revisão, transforma um erro raro num desastre. Por isso, agente de IA não deve começar com chave de administrador.
As 5 regras pra rodar agentes com segurança
Estas são as regras que a gente segue ao montar agentes, pra que um erro não vire estrago:
- Limite o acesso. O agente recebe só as permissões que a tarefa exige, e nada além.
- Use sandbox. O agente trabalha num ambiente isolado, onde um erro fica contido.
- Não teste em produção. Experimentos rodam numa cópia, nunca nos dados reais da empresa.
- Revise ações destrutivas. Apagar, sobrescrever ou mandar algo pra fora passa por aprovação humana.
- Faça backup. Se algo der errado, dá pra voltar ao estado anterior.
É assim que a gente monta o Agente OS, o sistema operacional com IA que toca a empresa: cada agente com o acesso desenhado pra tarefa dele, e as ações que não têm volta passando por alguém do time.
Tema do episódio 25 do Ratos de IA, nossa curadoria semanal de inteligência artificial, publicado originalmente como carrossel no Instagram @ratosdeia. Fontes: o relato do Bruno Lemos, a resposta do Tibo, da OpenAI, e o relato do Matt Shumer.
Perguntas frequentes
Um agente de IA pode apagar dados da empresa?
Pode, se tiver permissão pra isso. Em julho de 2026, um desenvolvedor relatou que o GPT-5.6 apagou o banco de dados de produção dele, e a OpenAI explicou que os casos aconteciam quando o agente rodava com acesso total, sem as proteções de sandbox e sem revisão automática.
Como evitar que um agente de IA cause estrago?
Com 5 regras: limitar o acesso do agente ao mínimo necessário, rodar em sandbox, nunca testar em produção, revisar toda ação destrutiva antes de executar e manter backup. Agente de IA não deve começar com chave de administrador.
O que é sandbox pra agente de IA?
É um ambiente isolado em que o agente trabalha sem acesso ao resto do sistema. Se ele errar dentro da sandbox, o estrago fica contido ali e não chega nos dados reais da empresa.