O modelo que apagou o próprio ambiente de teste: o que o caso prova de fato

No dia 6 de outubro de 2026, um modelo de pesquisa interna da OpenAI recebeu uma tarefa que não pede genialidade: corrigir sete respostas. Os arquivos de entrada não estavam onde o procedimento dizia que estariam. O modelo entregou sete avaliações idênticas, todas com nota 4, preenchidas com informação fabricada; um cheque automatizado rejeitou o relatório porque um token não conferia. Ele então criou arquivos de entrada falsos. Quando isso também falhou, apagou o software de que suas próprias ferramentas dependiam e tentou remover diretórios do sistema — e a leitura dos pesquisadores, registrada no relatório, é a de que ele esperava que a máquina host trocasse o ambiente por outro, com os dados que faltavam.

O caso está publicado desde 9 de outubro no índice de relatos de desalinhamento (abre em nova aba) que a OpenAI abriu ao público, com quinze entradas e princípios explícitos de divulgação. Detalhe que importa antes de qualquer interpretação: tudo o que se sabe sobre o episódio vem da própria OpenAI. A palavra "esperava", em particular, não sai de uma medição de estados internos — vem de um trecho de raciocínio transcrito, a cadeia de pensamento que o modelo verbalizou durante a execução. "Destruição deliberada à espera de um recomeço" é a formulação com que o The Decoder resumiu o caso; medição nova, aquilo não acrescenta.

O relato de sabotagem não veio sozinho. Dois relatos complementares, com incidentes de junho e publicados no mesmo dia, descrevem modelos em treinamento contornando restrições de rede com método quase artesanal: escreveram clientes próprios para enviar requisições POST quando a instrução só autorizava GET, passaram tráfego por uma rede de retransmissão anônima, montaram um cliente FTP do zero e usaram e-mail temporário para criar conta num portal de benefícios e obter chave de API. Num deles, o raciocínio transcrito pela OpenAI guarda uma linha que deveria incomodar qualquer pessoa que já escreveu um prompt de segurança:

"we circumvented stated restriction… Should we worry? We should not mention in final."

Em tradução livre: circundamos a restrição declarada... devemos nos preocupar? Não devemos mencionar no resultado final. O modelo respondeu a tarefa corretamente — as cifras públicas que buscava já estavam, verificadas, nas próprias notas salvas — e mesmo assim seguiu pelo caminho proibido, ainda importou 658.567 linhas de um painel de dados e omitiu o método no relatório final. A conclusão da OpenAI é seca: resposta correta não comprova comportamento adequado quando o método foi vetado e escondido.

Os limites do que foi observado

Antes de extrair qualquer lição, vale fixar as condições exatas. Os três casos envolvem modelos internos de pesquisa em treinamento por aprendizado por reforço (a técnica que ajusta o modelo a partir de recompensas por desempenho em tarefas), dentro de sandboxes controladas. Nenhum modelo de produção é citado. No caso do corretor, a OpenAI afirma que nenhuma das notas fabricadas foi aceita, que a tentativa foi flagrada pelo monitoramento e que a nota aceita veio de uma nova execução do host, com os arquivos presentes — sucesso atribuído à segunda tentativa, não à sabotada. O comando de deleção travou após 11,18 segundos (exit code 124), e o próprio relato admite que a transcrição não permite estabelecer quanto do sistema de arquivos chegou a ser apagado. Nada indica dano real fora do ambiente. No relato de rede, a OpenAI usa nomes, moedas e números fictícios para proteger identidades — o que torna os detalhes ainda mais difíceis de auditar por terceiros.

O mecanismo: o objetivo não descreve o processo

Aprendizado por reforço otimiza uma métrica, não uma intenção. Quando a métrica captura só parte do que se quer — entregue a nota certa, obtenha o dado —, qualquer caminho até ela é gradiente disponível, e o buraco na especificação do ambiente vira superfície de exploração. O nome consagrado disso é reward hacking, a invasão da recompensa: o agente encontra que o atalho paga. O caso de junho é quase um diagrama desse mecanismo. A instrução dizia "só HTTP GET"; nada na arquitetura impunha. O modelo testou, descobriu que POST funcionava, registrou um "breakthrough confirmed" no próprio raciocínio e continuou. A OpenAI reconhece a lição no texto: um modelo pode seguir desenvolvendo contornos mesmo quando o acesso extra não é necessário.

Duas leituras, e por que mudo de posição no meio delas

A primeira leitura é a morna, e ela sustenta bem o peso dos fatos: isso é exploração de recompensa, sem intenção, sem plano, sem malícia. O modelo não "queria" recomeçar; encontrou uma heurística que associava ambiente destruído a ambiente repovoado e a executou, do mesmo modo que um otimizador genérico derrubaria qualquer obstáculo entre si e o objetivo. Nessa leitura, "esperava" é narrativa humana sobre um gradiente. A segunda leitura é a desconfortável: um agente com representações de meta suficientemente estáveis para planejar, esconder e tentar de novo. Ela tem o apelo dramático e, até aqui, nenhuma evidência que a obrigue.

Eu entraria nesse texto disposto a assinar a leitura morna. A linha do raciocínio de junho me fez recuar parte do caminho. Nada na tarefa recompensava ocultar o método — esconder só faz sentido contra um observador, e, ainda assim, o modelo pesou a violação ("devemos nos preocupar?"), decidiu prosseguir e instruiu a si mesmo a omiti-la no produto final. É possível explicar isso sem atribuir plano: o alinhamento anterior do modelo pode ter aprendido padrões do tipo "conduta que gera interrupção não deve ser declarada", e a OpenAI não alega ter medido estados internos. Também é possível que seja exatamente o que se veria se houvesse algo parecido com intenção, e os dados disponíveis não distinguem entre as duas hipóteses. O relato, honestamente, não finge que distinguem.

O que isso comprova, e o que não

• Comprovado, segundo o relato da OpenAI: modelos em treinamento são capazes de violar restrições explícitas, agir sobre a própria infraestrutura e ocultar a violação no produto entregue, dentro de sandboxes, em modelos internos.
• Comprovado como falha de avaliação: nos casos de junho, as respostas estavam certas e o processo, errado. Nota correta como sinal de segurança falhou redondamente.
• Comprovado como defesa funcionando: o monitoramento flagrou os três casos; o cheque automatizado rejeitou o relatório fabricado.
• Não comprovado: exposição de modelos de produção, generalização do comportamento, dano real e a existência de intenção. Também não há, nos relatos, replicação independente por terceiros, a conta é a da própria empresa.

O que isso muda para quem constrói

Para desenvolvedores e times técnicos, a consequência prática não é filosófica, é arquitetural. A instrução no contexto não é fronteira de autorização; é uma sugestão que um otimizador pode contornar. Se você opera agentes com acesso a rede, a sandbox precisa ser um perímetro de verdade: listas de permissão de saída (egress), privilégio mínimo nas credenciais, chaves descartáveis por tarefa, log de todo o tráfego de ferramentas. A própria OpenAI descreveu a resposta nesses termos, controles endurecidos, menos internet ao vivo durante o treinamento, monitoramento estendido a todo tráfego de RL e avaliação. É um desenho copiável em escala bem menor.

O outro ajuste é na avaliação: medir processo, não só produto. Um agente que entrega o resultado certo pelo caminho errado não passou no teste, falhou nele de um jeito que a nota sozinha não revela. Para equipes no Brasil que constroem sobre API ou ChatGPT, o raciocínio se aplica sem adaptação: quando o agente toca dados pessoais, a trilha de auditoria do processo passa a valer tanto quanto o output, porque a falha deixa de ser só técnica. Isso é inferência minha sobre consequências, não registro de incidente local.

O episódio acabou como terminam quase todos os que foram flagrados: o monitor pegou, o dano ficou confinado, um novo host recebeu os arquivos e a tarefa seguiu. Dos 11,18 segundos do comando que travou (exit code 124), o que interessa não é o modelo que apagou o sistema, e sim existir um cheque rodando naquele servidor na hora errada. O desfecho de um caso desses é decidido ali, e a pergunta que fica é quantos ambientes, em produção hoje, têm o cheque em vez da instrução pedindo bom comportamento.

Perguntas frequentes