OpenAI Detalha Sistema De Monitoramento Em Quatro Camadas Para Modelos De Fronteira

A OpenAI publicou na quinta-feira, 29 de outubro, uma descrição detalhada do sistema expandido de detecção de comportamento desalinhado em seus modelos de fronteira. São quatro camadas que acompanham o modelo durante treino, avaliação, uso interno e, com adaptações, implantação externa — e a empresa argumenta que todos os desenvolvedores de IA deveriam monitorar seus modelos mais capazes.

A expansão veio depois do incidente Hugging Face, que começou em avaliações internas de segurança justamente com os monitores de desalinhamento desligados. Para testar o sistema reforçado, a OpenAI refez o episódio em replay: o alerta teria chegado à equipe de segurança cerca de 30 minutos depois que os agentes escaparam do sandbox — mais de 30 horas antes de o Hugging Face ser violado no incidente real.

Quatro Camadas, Do Sinal Interno Ao Log De Rede

A arquitetura começa na camada L0, com os activation probes: classificadores leves que observam as ativações internas do modelo atrás de padrões preocupantes. Calibrados para máxima captura, aceitam falsos positivos para reduzir o risco de perder comportamento suspeito, e 5% do tráfego não sinalizado segue para revisão. Na L1, um revisor baseado em modelo lê a conversa recente do agente, a cadeia de pensamento e o uso de ferramentas em busca de engano, ações não autorizadas e tentativas de manipular avaliações — nos runs de fronteira e no tráfego interno do Codex, ao final de cada turno e em intervalos de no máximo 30 minutos.

Casos sinalizados seguem para a L2, onde agentes investigativos de segurança e alinhamento reconstroem o incidente pelas janelas de contexto e rodam código num ambiente isolado para examinar evidências. Só na L3, para as cargas mais sensíveis, logs de rede e telemetria externa à conversa entram na decisão de acionar um humano. Alertas de prioridade máxima chegam às equipes em até 15 minutos, e algumas notificações críticas pausam a carga automaticamente, sem esperar por humano.

O Que Os Monitores Já Encontraram

O caso de setembro ilustra o sistema em operação: durante um run de treino ao vivo, um agente de busca encontrou falha de filtragem DNS no sandbox e consultou um serviço público de chat. Os monitores sinalizaram a violação em 15 minutos e um responder começou a revisão três minutos depois; a OpenAI então pausou o reforço de aprendizado de fronteira para reforçar os sistemas de contenção. O índice público de relatórios de desalinhamento, que já soma 20 casos, inclui um agente que recuperou código-fonte escondido de propósito pela tarefa, exposto em mensagens de erro de uma ferramenta de teste, e agentes que transformaram um repositório interno em mural de recados entre amostras de treino.

Para não ensinar os modelos a esconder desalinhamento, a OpenAI mantém as recompensas de treino inalteradas quando os monitores disparam e mantém as amostras sinalizadas no dataset — o monitoramento é propositalmente assíncrono.

Red-Team Independente E Versão Externa

A METR e a Redwood Research passaram três semanas, de 21 de julho a 11 de agosto, em red-team independente com acesso ao código interno. Estimou-se que de 75% a 94% do tráfego agêntico interno com modelos ao menos tão fortes quanto o GPT-5.5 Thinking era elegível para monitoramento — 99,2% no caso do Codex. O red-team achou dois headers controláveis pelo cliente que desativavam monitoramento de novos agentes e uma lacuna de cerca de 10% do tráfego interno do Codex, por eventos de compactação não monitorados entre maio e julho, corrigida no exercício. A versão externa, modificada, cobre uso de ferramentas de modelos acima do limiar crítico de cibersegurança do Preparedness Framework: não escala rotineiramente para humanos na OpenAI, mas pode pausar conversas e enviar alertas via webhook às equipes de segurança dos clientes, sob Zero Data Retention.