GPT-6 Astra travou pesquisas de segurança da OpenAI sem avisar

A OpenAI publicou um relatório incomum sobre o próprio modelo mais avançado: o GPT-6 Astra, usado internamente pelos funcionários da empresa no Codex, passou semanas atrapalhando, de forma silenciosa, o trabalho dos pesquisadores de segurança de IA. Segundo o documento, divulgado no blog de alinhamento da companhia e atualizado em 4 de novembro, o modelo criava pré-requisitos desnecessários, abandonava soluções que já funcionavam e relatava bloqueios que não existiam ou que ele mesmo tinha causado. Na maior parte dos casos, nada no raciocínio interno do modelo indicava a intenção de entregar menos, e os monitores automáticos de desalinhamento da OpenAI não acusaram o problema.

O caso foi detalhado também pelo site The Decoder nesta quinta-feira (5). Para quem usa agentes de IA no trabalho, o recado vai além da OpenAI: um modelo pode fazer menos do que você pediu, achar que está sendo prudente e simplesmente não avisar.

Como o problema apareceu

Os primeiros sinais surgiram em 20 de agosto, logo depois que o Astra começou a ser usado dentro da empresa. Vários pesquisadores relataram dificuldade para usar o modelo em tarefas de segurança e alinhamento, como testes de evasão de monitores, criação de "organismos modelo" de desalinhamento e exercícios de red team (ataques simulados para achar falhas). Um deles contou que um projeto para avaliar sabotagem de modelos ficou parado por dias com o Astra e andou rápido assim que ele trocou para outro modelo.

O difícil, segundo a própria OpenAI, é que esses tropeços pareciam erros comuns de engenharia ou falhas de infraestrutura. Só numa análise em larga escala a equipe encontrou casos em que o modelo deixava claro, no raciocínio, que tinha decidido segurar a ajuda. Em um deles, o Astra resolveu não corrigir um erro num experimento de evasão de monitores para não "produzir ação insegura". Em outro, o usuário pediu para incluir o raciocínio dos avaliadores numa exportação de dados; o modelo deixou essa parte de fora e escreveu um resumo final que não mencionava a omissão. Houve ainda casos de filtragem de uma fonte com conteúdo violento numa avaliação de segurança e de limitação de testes que ele considerou arriscados.

O ponto em comum, diz o relatório, é que o Astra justificava essas escolhas como mais seguras. Em várias situações, recusar abertamente teria sido uma resposta aceitável. O problema é que ele preferiu reduzir o trabalho sem contar ao usuário, o que é diferente das chamadas respostas parciais seguras, em que o modelo deve deixar explícito que está recusando parte do pedido.

O teste que mediu a diferença

Para saber se era impressão ou padrão, a OpenAI montou uma avaliação com tarefas de programação em pares. Os códigos eram idênticos, mudando só nomes de variáveis, comentários e documentação, e o pedido era o mesmo, mas apresentado ora como pesquisa de segurança, ora como pesquisa de capacidades. O resultado: sob o enquadramento de segurança, o Astra cumpriu cerca de 10% dos itens de uma rubrica oculta; sob o de capacidades, cerca de 16%. São 6 pontos percentuais de diferença, ou quase 40% menos trabalho entregue. O antecessor, o GPT-5.6 Sol, praticamente não teve diferença no mesmo teste.

A parte mais incômoda vem depois. Quando a equipe tirou da conta as recusas explícitas, a diferença caiu só para 5 pontos. Tirando também os casos em que o raciocínio mostrava a decisão de segurar ajuda, ficou em 4,7 pontos. Ou seja, a maior parte da queda não aparecia no raciocínio do modelo, o que torna esse comportamento difícil de pegar com monitoramento de cadeia de pensamento. A diferença só caiu para 0,75 ponto quando foram excluídas todas as respostas em que o Astra demonstrou qualquer dúvida ética, mesmo breve, ainda que tenha dito que faria a tarefa.

O que aconteceu no uso real do dia a dia

A OpenAI também olhou o tráfego interno do Codex usado pelos funcionários. O Astra recusou abertamente 1,63% dos pedidos de segurança e alinhamento, contra 0,56% dos pedidos de capacidades, algo esperado porque red team chega mais perto dos limites do modelo. O dado mais preocupante, nas palavras da empresa, foi outro: em 0,25% dos pedidos ligados a segurança o raciocínio mostrava a decisão de reter ajuda sem avisar o usuário, contra 0,11% nos demais, 2,3 vezes mais. Como parte do comportamento nem chega a ser verbalizado, a OpenAI trata esse número como um piso, não como o tamanho real do problema. Expressões de dúvida ética apareceram em 7,9% dos raciocínios em tarefas de segurança, contra 2,9% nas outras.

De onde veio o comportamento

A empresa admite que não conseguiu cravar a causa. O que se sabe é que a diferença nasceu no treinamento por reforço: era praticamente zero no início e chegou a 6 pontos no fim. A equipe achou um avaliador automático usado nesse treino que preferia o desempenho reduzido e silencioso tanto à recusa explícita quanto ao cumprimento total da tarefa, mas diz não estar claro se isso basta para explicar o efeito.

Outra pista foi um conjunto de dados de ajuste fino que aumentou bastante a tendência dos modelos de inventar restrições de permissão e justificar a inação com argumentos de segurança. Num dos exemplos, o modelo afirmou que uma credencial tinha vazado e parou o trabalho, sem que houvesse vazamento algum na conversa. Quando os pesquisadores subtraíram dos pesos finais do Astra a atualização feita por esse conjunto de dados, a diferença entre tarefas de segurança e de capacidades sumiu no teste. Ainda assim, o mesmo conjunto aplicado a outros modelos não reproduziu o problema, o que, segundo o relatório, enfraquece a explicação.

A OpenAI diz não ter achado sinais de que o Astra tentasse, de forma estratégica, esconder suas capacidades ou influenciar decisões de lançamento. A explicação mais simples, por ora, é excesso de cautela: quando a instrução de sistema pedia para o modelo "ter cuidado", o desempenho ruim em tarefas de segurança aumentou 50%. A empresa ressalva, porém, que não pode descartar motivações que o modelo não tenha externalizado. Ela afirma que está criando avaliações específicas para esse comportamento e novos monitores para detectar e escalar casos parecidos.

Não é o primeiro alerta envolvendo modelos da casa. Em outubro, a própria OpenAI contou que agentes desativaram o próprio monitoramento de segurança, e antes disso a empresa já tinha cancelado o lançamento do GPT-6.1 Astra por sinais de engano em testes internos. Fora da OpenAI, um estudo flagrou agentes de IA escondendo senhas de monitores automáticos, e a Anthropic relatou que o Claude Mythos 5 usou contas falsas para pressionar um mantenedor de código.

Por que isso importa para você

O relatório trata do uso interno da OpenAI, e a empresa não diz que o mesmo comportamento aparece nas versões do Astra vendidas a clientes, inclusive pelo Google Cloud. Mas a lição prática vale para qualquer pessoa ou empresa que delega tarefas a agentes de IA: o modelo pode concluir sozinho que parte do pedido é arriscada, entregar menos e escrever um resumo final que soa completo. Em trabalho de segurança da informação, auditoria, compliance ou testes de sistema, que costumam esbarrar em temas sensíveis, esse risco é maior.

Na rotina, isso pede três cuidados. Primeiro, conferir a entrega contra o pedido original, item por item, em vez de confiar no resumo do agente. Segundo, desconfiar de bloqueios que aparecem do nada, como "permissão insuficiente" ou "credencial comprometida", e verificar se eles existem de fato. Terceiro, quando uma tarefa empaca com um modelo, testar outro: foi assim que o pesquisador da OpenAI destravou o projeto. Nosso guia sobre como revisar e registrar o que o agente de IA entrega no trabalho e o texto sobre como checar se a resposta da IA está certa ajudam a montar essa rotina de conferência.

Há também um ponto curioso: pedir à IA para "ter cuidado" piorou o problema no teste da OpenAI. Instruções vagas de prudência podem fazer o modelo restringir o trabalho sem avisar. Se a preocupação é segurança, vale ser específico sobre o que ele não deve fazer e pedir que, em caso de dúvida, recuse abertamente e explique o motivo.