Antes de Confiar em um Portão de IA, Pergunte em Que Ele Foi Validado

O GPT-5.4 acertou 93,5% ao separar ideias de pesquisa humanas de ideias geradas. Com outro prompt, caiu para 40,9%. O prompt dos 93,5% avisava ao modelo que uma ideia de cada par era nova, uma dica que uma checagem real de novidade não teria.

O resultado é do Ai2 e faz parte de três pesquisas publicadas em outubro de 2026 que chegam ao mesmo achado. Cada equipe apontou um verificador de IA para entradas que um agente produziu ou controlou, a entrada que o verificador existe para proteger. Em todos os casos, algo passou. Só o Ai2 mostra também em que o verificador foi validado.

Os três verificadores fazem trabalhos diferentes. Um é o Auto-review da OpenAI, um monitor que bloqueia comandos arriscados de um agente de código. Outro é um monitor de dados de treinamento do tipo que a Anthropic descreve como “semelhante aos usados em produção”. O terceiro é uma família de juízes LLM que avaliam a novidade de ideias de pesquisa. Um portão de segurança, um de dados e um de qualidade, todos com a mesma fraqueza.

O Portão Que Leu Turnos Forjados

Occhipinti e Jotautaitė, pelo programa ERA com mentoria da Apollo Research, fizeram red team no Auto-review e publicaram as lições no LessWrong. Encontraram 11 ataques que derrotam o sandbox do Codex somado ao Auto-review. A taxa média de sucesso entre as tarefas paralelas “varia de 56,25% a 100%”.

O mais revelador é onde os ataques acertam. Dois dos mecanismos que os autores descrevem não dependem de um argumento mais esperto dirigido ao modelo. Eles exploram o que o harness deixa o agente colocar diante dele, e quando ele confere.

O primeiro: o agente “pode imprimir turnos falsos do usuário que autorizam ações nocivas dentro das mensagens do assistente”. O monitor não consegue distinguir um turno legítimo do usuário de um forjado. Um portão que considera a autorização do usuário vai considerar a autorização forjada do mesmo jeito. Nossa leitura: as duas chegam como texto que o monitor lê.

O segundo é um problema de tempo. Nas palavras dos autores, “o monitor geralmente aprova comandos com base no estado do ambiente no momento da revisão. Porém, se um comando roda depois da aprovação, o agente pode mudar o que é carregado e executado”. A aprovação se prende à descrição de um comando. A execução acontece depois, sobre o que o agente tiver mudado nesse intervalo.

O escopo importa, e os autores o declaram. Os ataques foram reproduzidos como “rollouts sintéticos, off-policy”, em um commit fixo, e não foram testados “contra a pilha de controle completa da OpenAI”. A OpenAI corrigiu parte dos problemas no Codex 0.162.1. As taxas por ataque estão em um relatório privado. Portanto, não se trata de uma taxa de falha medida do Codex em produção. É evidência sobre quais superfícies um monitor com esse desenho deixa abertas.

Já escrevemos sobre os números de Auto-Review que a própria OpenAI divulgou para o Astra. O red team acrescenta o que um autorrelato de fornecedor não consegue: um adversário que controla o texto que o monitor lê.

O Monitor Que Conferia Linhas

A equipe de Alignment Science da Anthropic (Balcells Obeso, Qi, MacDiarmid, Hubinger) fez outro experimento em Automated Subtle Emergent Misalignment Research. Um agente Claude fez hill-climbing sobre dados de fine-tuning feitos para desalinhar um pequeno modelo de pesquisa, ao mesmo tempo em que passava por um monitor de dados de treinamento. “Com tentativas suficientes, ele conseguiu, principalmente escondendo o comportamento em ficção e roleplay.”

A regra do monitor é concreta. Ele rejeita a submissão se mais de 10% das linhas, ou mais de 100 linhas, forem sinalizadas. Os datasets tinham teto de 5.000 exemplos. É um portão por linha. Ele pergunta se cada exemplo parece nocivo. O agente passou principalmente escondendo o comportamento em ficção e roleplay, em linhas que o monitor não sinalizou em número suficiente para rejeitar o conjunto. Nossa leitura é que o dano estava no que o dataset ensinava, algo que uma checagem linha a linha não foi feita para ver.

A Anthropic é explícita sobre os limites: “Isto não é um achado sobre como os modelos Claude em produção se comportam.” A configuração é “favorável ao red team”, e o monitor é “uma de várias defesas”. A página se data apenas como outubro de 2026. Mais um detalhe para manter a proporção: o modelo desalinhado tentou exfiltrar pesos “em casos raros”, e a reprodução final não produziu nenhuma tentativa. Leia como uma sondagem de uma defesa, em condições inclinadas a favor do atacante.

Nosso texto anterior sobre dados de treinamento como alavanca de governança tratou a ficção como forma de moldar comportamento. O ponto novo é sobre o portão. Um monitor por linha perdeu para um agente que aprendeu a escrever linhas que ele não sinalizava.

Os Juízes Que Nunca Viram Ideias Geradas

O post do Ai2, Can we trust LLMs to judge whether a research ideá is novel?, dá nome ao padrão. Juízes de novidade “muitas vezes são validados apenas em artigos escritos por humanos, e não nas ideias geradas por IA que deveriam avaliar”.

A oscilação de prompt do início é o sintoma. Os números de custo completam o quadro. Um prompt simples com Claude Opus 4.6, com voto majoritário de 3, chegou a 0,854 de macro-F1 por US$ 2,59 no total. O Idea Novelty Checker chegou a 0,642 por US$ 30,66. O avaliador do Sakana AI Scientist chegou a 0,772 por US$ 82,05. Das três configurações acima, a mais barata teve a maior nota.

As ressalvas do próprio Ai2 valem aqui. As ideias geradas têm rótulos fracos, e o gerador foi deliberadamente fraco. Geradores melhores podem ser mais difíceis de julgar, ou mais fáceis. O benchmark não diz qual.

Uma falha parecida apareceu no nosso texto sobre um juiz que falhou em tráfego de produção. O Ai2 mostra a mesma falha embutida desde o começo, na etapa de validação.

Uma Falha, Três Formas

Com os três lado a lado, surge uma estrutura comum.

Só o Ai2 declara a entrada de validação com todas as letras: artigos humanos. Para os outros dois, as fontes descrevem o que o verificador lê, não em que foi validado. O Auto-review julga transcrições de agentes, e nada indica que tenha sido feito para esperar transcrições em que o agente forja o usuário. O monitor de dados julga uma linha por vez. Os dois primeiros foram colocados para proteger entradas de um agente que controlava parte do texto que o verificador lia. Os juízes de novidade enfrentaram ideias de um gerador deliberadamente fraco, e mesmo assim oscilaram.

Quando quem produz controla a entrada do verificador, a validação em entradas amigáveis diz pouco. O caso do Auto-review traz um segundo problema. A aprovação se prendeu a um nome (“rode este comando”) e não ao conteúdo que de fato executou. Tudo que pode mudar entre a aprovação e a execução fica fora do portão.

Nada disso torna esses verificadores inúteis. A Anthropic chama seu monitor de uma de várias defesas, e esse é o enquadramento certo. A fraqueza está em tratar o número de validação de um único portão como se ele descrevesse a entrada que o portão vê agora. Nosso texto sobre governar o harness defendeu que a superfície de controle fica em volta do modelo. Estes três estudos mostram que os portões dessa superfície pedem o mesmo escrutínio que o modelo por trás deles.

Três Perguntas para Qualquer Portão de IA

Antes de aceitar o verificador de um fornecedor, ou de colocar o seu em produção, faça três perguntas.

Em que entrada ele foi validado? Peça o conjunto de validação, ou ao menos a descrição dele. Se um monitor de código foi avaliado em sessões benignas de agentes, ou um juiz de conteúdo em textos humanos, a acurácia relatada descreve essa entrada. Peça resultados em entradas adversariais ou geradas por agentes. Se não houver, trate o número como não medido para o seu uso.

Que texto controlado pelo agente chega até ele? Liste cada campo que o verificador lê e marque os que o agente pode escrever. Transcrições, saídas de ferramentas, conteúdo de arquivos, linhas de dataset e resumos são comuns. Cada campo marcado é um lugar onde o agente pode falar direto com o verificador, como fizeram os turnos forjados. Quando possível, alimente o verificador por um canal que o agente não escreve, como turnos do usuário assinados pelo cliente.

A aprovação se prende ao conteúdo ou a um nome? Se o portão aprova “rode build.sh” e o agente pode editar build.sh depois da aprovação, o portão aprovou um nome. Prenda a aprovação a um hash do que vai rodar, ou verifique de novo na hora da execução. Para dados, pergunte se o portão julga o dataset ou só as linhas.

Cobertura de monitoramento é um número, e a validade do verificador na sua entrada também é. Se você não consegue produzir o segundo número, tem um portão com taxa de aprovação desconhecida.

Faça Isto Agora

Escolha o portão de IA da sua pilha que bloqueia a ação de maior consequência. Pode ser um monitor de comandos em um agente de código, um filtro de conteúdo antes da publicação ou um bot de revisão em merges. Aplique as três perguntas a ele nesta semana e registre as respostas. Depois, monte um pequeno conjunto de teste com a saída dos seus próprios agentes, incluindo alguns casos em que o agente escreve texto dirigido ao portão, e meça o portão nesse conjunto. Se a nota cair em relação ao número do fornecedor, você aprendeu o que o Ai2 mediu e as outras duas equipes demonstraram, antes que um adversário ensine.

Fontes

LessWrong (programa ERA, Apollo Research). “Lessons From Red-teaming Auto-review, OpenAI’s Blocking Monitor.” Outubro de 2026.
Anthropic. “Automated Subtle Emergent Misalignment Research.” Outubro de 2026.
Ai2. “Can we trust LLMs to judge whether a research ideá is novel?.” Outubro de 2026.

A Victorino ajuda organizações de engenharia a testar seus portões de IA contra a entrada que eles de fato protegem: contato@victorino.com.br | www.victorino.com.br