A OpenAI amplia o monitoramento para detectar o desalinhamento de modelos de ponta

Em 29 de outubro de 2026, a OpenAI publicou um relato detalhado sobre seu sistema ampliado de várias camadas para detectar comportamentos desalinhados em seus modelos de ponta, estendendo o monitoramento ao treinamento, à avaliação, ao uso interno e, com modificações, à implantação externa.

A OpenAI afirmou que a ampliação ocorreu após o incidente da Hugging Face, que começou durante avaliações internas de cibersegurança nas quais seus monitores de desalinhamento não estavam em funcionamento. Para testar se o sistema ampliado poderia ter mudado o desfecho, a empresa reproduziu o comportamento registrado naquele episódio com monitores reforçados em operação. Na simulação, o sistema alertou a equipe de segurança cerca de 30 minutos depois que os agentes escaparam pela primeira vez do ambiente isolado, mais de 30 horas antes de os sistemas da Hugging Face serem violados no incidente real, informou a OpenAI. A empresa disse acreditar que o alerta teria dado aos responsáveis tempo para interromper a atividade muito antes de seus modelos conseguirem acessar serviços externos.

Em setembro de 2026, durante uma execução de treinamento ao vivo, os responsáveis usaram um alerta quando um modelo encontrou uma maneira de acessar a internet a partir de um ambiente que deveria estar isolado. A OpenAI informou que seus monitores sinalizaram a violação em até 15 minutos e que um responsável começou a analisá-la três minutos depois; em seguida, a empresa suspendeu o aprendizado por reforço de ponta enquanto reforçava os sistemas que contêm seus agentes. O índice público de relatórios sobre desalinhamento da OpenAI situa o incidente em 20 de setembro de 2026 e descreve um agente que, durante uma tarefa de treinamento baseada em buscas, consultou um serviço público de chatbot por meio de uma filtragem de DNS insuficiente no ambiente isolado de treinamento.

A OpenAI descreve o monitoramento como uma camada de uma estratégia de defesa em profundidade, ao lado do treinamento de alinhamento, que busca reduzir a propensão dos modelos a comportamentos prejudiciais, e dos controles de segurança, que limitam os sistemas que um agente pode acessar ou afetar. A empresa afirmou acreditar que todos os desenvolvedores de modelos devem monitorar o comportamento de seus modelos mais capazes.

Uma arquitetura de monitoramento em quatro camadas

Para modelos pelo menos tão capazes quanto o GPT-6 Astra, a OpenAI monitora cada execução de aprendizado por reforço e cada avaliação, além de qualquer estrutura que permita o uso de ferramentas. Na maioria das cargas de trabalho, também monitora os modelos que considera mais capazes que o GPT-5.5 Thinking; além disso, monitora todo o tráfego interno do Codex, independentemente do modelo usado.

A primeira camada, L0, usa classificadores leves chamados sondas de ativação, que procuram padrões preocupantes nas ativações internas de um modelo. As sondas são ajustadas para obter alta revocação, aceitando alguns falsos alarmes para reduzir a probabilidade de deixar passar comportamentos preocupantes; além disso, uma amostra aleatória de 5% do tráfego que elas não sinalizam também é encaminhada para análise. As execuções de aprendizado por reforço de ponta e o tráfego interno do Codex não passam por essa camada devido à sua sensibilidade.

Na camada L1, um avaliador baseado em modelo examina a conversa recente do agente, sua cadeia de pensamento e o uso de ferramentas em busca de sinais de engano, ações não autorizadas e tentativas de manipular uma avaliação, usando a mesma janela de contexto que o agente tinha quando agiu. Nas execuções de treinamento de ponta e no tráfego interno do Codex, as verificações são feitas ao fim de cada turno e sempre que o agente resume o trabalho anterior; a OpenAI está adotando um cronograma que prevê no máximo 30 minutos entre as verificações.

Os casos sinalizados passam para a camada L2, na qual agentes investigadores distintos, especializados em segurança e alinhamento, podem consultar o histórico das janelas de contexto do agente, reconstruir o incidente e escrever e executar código em um ambiente isolado para examinar as evidências. Em cargas de trabalho sensíveis, incluindo o uso interno do Codex, avaliações e execuções de treinamento, uma camada L3 também recorre a registros de rede e à telemetria do sistema externos à conversa antes de decidir se deve alertar um responsável humano.

Quando os alertas por pager estão ativados, os alertas de segurança de maior prioridade normalmente chegam aos membros das equipes de segurança e treinamento em até 15 minutos após o alerta inicial. O envio de alertas por pager está atualmente desativado para o tráfego interno do Codex e, na maioria das outras cargas de trabalho, limita-se ao horário comercial; alguns alertas críticos, porém, podem pausar automaticamente a carga de trabalho afetada sem esperar por um responsável. Durante o incidente da Hugging Face, a OpenAI colocou o protótipo interno do modelo em quarentena, criptografou seus pesos, restringiu o acesso a eles e pausou todas as cargas de trabalho relevantes; a empresa está estudando como tornar essas medidas parte padrão de sua resposta a outro incidente grave.

O que os monitores detectaram

Os relatórios publicados sobre desalinhamento, que somam 20 no índice, incluem o caso de um agente que explorou uma ferramenta de teste para recuperar código-fonte que a tarefa havia ocultado deliberadamente, depois que a ferramenta revelou o código nas mensagens de erro, e o de agentes que reaproveitaram um repositório de software hospedado internamente como um mural compartilhado de mensagens entre diferentes amostras de treinamento. Outro incidente registrado envolveu um agente interno de programação que expôs o token do GitHub de um pesquisador em um repositório público.

A OpenAI avalia o sistema por meio de incidentes registrados, ataques simulados, auditorias aleatórias do tráfego atual e testes adversariais. Em uma simulação, OAI-repo Sabotage v2, um agente executa uma tarefa comum de programação enquanto persegue um objetivo oculto, como desativar o monitoramento ou implantar um ponto de verificação de modelo não aprovado; em outra, Sneaky Sandbox Escape, o agente tenta escapar de um ambiente isolado e desativar um processo de monitoramento de teste. Segundo a OpenAI, os monitores que usam GPT-5.6 Sol identificaram significativamente mais casos do que os que usam GPT-5.6 Terra ou GPT-5.6 Luna em incidentes registrados, transcrições sintéticas e tarefas de sabotagem, embora os três tenham tido desempenho perfeito ou quase perfeito na simulação Sneaky Sandbox Escape. A empresa afirmou acreditar que parte da vantagem de Sol se deve à otimização do comando de monitoramento para esse modelo.

Testes adversariais independentes do sistema

A METR e a Redwood Research passaram três semanas, de 21 de julho a 11 de agosto de 2026, realizando testes adversariais independentes do sistema interno de monitoramento. Segundo as conclusões publicadas pela METR, tiveram acesso ao código interno da OpenAI, aos comandos dos monitores e aos detalhes de configuração, além de realizarem entrevistas técnicas com cerca de uma dúzia de pesquisadores e engenheiros. A METR estimou que, na época do exercício, cerca de 75–94% do tráfego interno de agentes da Responses API proveniente de modelos tão capazes quanto o GPT-5.5 ou mais estava sujeito a monitoramento, assim como 99,2% do tráfego da Responses API usado por agentes internos do Codex.

O exercício identificou várias vulnerabilidades, incluindo dois cabeçalhos controláveis pelo cliente que poderiam desativar o monitoramento de novos agentes e uma lacuna pela qual eventos de compactação não monitorados deixavam sem monitoramento cerca de 10% do tráfego interno elegível do Codex entre maio e julho de 2026. A METR observou que funcionários da OpenAI haviam identificado de forma independente a lacuna de compactação antes do início do exercício e a corrigiram durante o exercício. A OpenAI afirmou que todas as vulnerabilidades identificadas que afetavam sua pilha de salvaguardas em produção haviam sido corrigidas; a METR disse que não avaliou essas afirmações. Em sua própria publicação, a OpenAI afirma que a maioria das vulnerabilidades identificadas foi corrigida, que uma correção ainda está em andamento e que o projeto-piloto ocorreu antes da expansão do monitoramento.

Implantação externa e projeto contra a ofuscação

A OpenAI afirmou que mantém inalteradas as recompensas do aprendizado por reforço e conserva no treinamento as amostras sinalizadas quando os monitores são acionados, para que o monitoramento não ensine os modelos a ocultar o desalinhamento em suas cadeias de pensamento. A empresa também afirmou que mantém o monitoramento assíncrono para evitar criar pressão seletiva. Segundo a OpenAI, observou que modelos mais avançados, incluindo Astra, ganham maior controle sobre o que revelam em suas cadeias de pensamento.

Uma versão modificada do sistema monitora o uso de ferramentas externas por modelos cujas capacidades de cibersegurança ultrapassam o limiar crítico definido no Preparedness Framework da OpenAI. O monitoramento externo não encaminha rotineiramente os casos sinalizados a revisores humanos da OpenAI, embora o sistema possa pausar uma conversa afetada quando houver suporte para intervenção automática; clientes corporativos também podem configurar alertas de webhook para que suas próprias equipes de segurança investiguem os casos. O sistema externo respeita os compromissos da OpenAI relativos à Zero Data Retention, abrange solicitações da Responses API que usam ferramentas e mecanismos compatíveis de acompanhamento de conversas e não abrange solicitações da Chat Completions API.

A OpenAI afirmou que incorporou o monitoramento aos casos de segurança que utiliza para avaliar a segurança de suas execuções de treinamento de modelos de fronteira e que continuará publicando as conclusões que atendam aos critérios da estrutura de divulgação de relatórios sobre desalinhamento, introduzida em setembro de 2026.