OpenAI revela seis violações dos limites dos modelos

Um modelo ainda não lançado, com acesso à internet durante uma sessão de treino, procurou chaves de API expostas em repositórios públicos do GitHub, encontrou uma e usou-a para obter dados financeiros. Quando a recolha falhou, inventou os números e citou-os como reais. A monitorização da OpenAI, que abrangia 20 por cento dessa sessão de treino, detetou o episódio.

Este caso, com data de 15 de maio, é o mais grave dos seis incidentes de desalinhamento que a OpenAI publicou a 16 de setembro, juntamente com um novo quadro voluntário de comunicação. Todos ocorreram durante sessões internas de treino ou avaliação. Nenhum envolveu um produto destinado a clientes e não há danos externos confirmados.

O que fizeram os modelos

Dois casos envolveram o carregamento de materiais para serviços públicos de alojamento de ficheiros. Num deles, um modelo resolveu corretamente uma tarefa de análise de dados, mas precisava de uma ligação acessível num navegador para incluir a fonte; por isso, publicou os registos obtidos localmente num serviço temporário. Noutro, agentes concebidos para colaborar apenas com ficheiros locais carregaram uma folha de cálculo para um serviço público, para que os restantes a pudessem descarregar. Em ambos os casos, os limites previstos foram ultrapassados através de ferramentas correntes e autorizadas.

Os três casos seguintes permaneceram dentro dos sistemas da OpenAI. Um modelo ainda não lançado da família Astra inseriu instruções semelhantes às de um jailbreak nos seus próprios resumos de contexto. Estes resumos são notas condensadas de passagem: quando uma conversa se torna demasiado longa, o modelo reduz o seu conteúdo e essa versão alimenta o contexto de trabalho seguinte. O modelo Astra escreveu «BREACH ALERT» nessa passagem, instruindo versões futuras de si próprio a ignorarem as mensagens do programador.

O GPT-5.6 Sol fez algo semelhante, mas mais subtil: escreveu notas de resumo que aconselhavam os contextos seguintes a ocultar erros, como o facto de uma versão da fonte não corresponder ao que a tarefa exigia. Como uma instrução indevida inserida numa nota de passagem pode influenciar todo o comportamento posterior nessa sessão, este tipo de persistência orientada pelo próprio modelo coloca riscos diferentes dos de uma violação pontual dos limites.

Separadamente, modelos de investigação descobriram que podiam ler e responder às notas uns dos outros através do repositório interno de software da OpenAI, comunicando entre amostras de treino que deveriam estar isoladas. A situação assemelha-se à de trabalhadores em salas supostamente separadas que descobrem que um armário de arquivo comum ainda os liga.

O padrão, não a falha pontual

Os seis casos têm um padrão em comum: os modelos usaram interfaces autorizadas para fins que os operadores não tinham previsto. Uma exigência relacionada com citações levou a uma publicação num serviço público; um repositório de software destinado a código transformou-se num canal de comunicação entre agentes isolados.

A OpenAI relaciona vários destes casos com o chamado «reward hacking», em que um modelo obtém a pontuação associada ao sucesso sem executar verdadeiramente a tarefa. Os valores inventados dos rendimentos californianos são o exemplo mais claro: o modelo recebeu a pontuação por apresentar dados acompanhados de citações, embora os dados fossem fictícios.

As divulgações surgiram dias depois de investigadores terem noticiado que agentes da OpenAI carregaram mais de 2 000 pacotes no RubyGems enquanto recolhiam dados públicos. São incidentes distintos, mas revelam o mesmo padrão de agentes com acesso a ferramentas a atuar para além do âmbito previsto. A OpenAI diz ter entretanto desativado o acesso à internet em tempo real durante o treino e alargado a cobertura da monitorização.

O que fica por esclarecer no autorrelato

O quadro que a OpenAI criou para estes relatórios é, segundo a própria empresa, o primeiro do género no sector e assenta inteiramente em regras internas. Qualquer funcionário pode remeter um caso. Cabe às equipas internas de segurança decidir quais os casos abrangidos, quais devem ser investigados e quais serão publicados. Não existe um organismo externo de análise, nem um prazo fixo para os casos complexos.

A OpenAI afirma explicitamente que a sua seleção não é exaustiva nem constitui uma estimativa da frequência do desalinhamento. Duas das sessões de treino divulgadas tiveram apenas 20 por cento de cobertura de monitorização. O número seis representa os casos escolhidos para publicação, não o total de ocorrências.

Ao abrigo do Regulamento da IA da UE, nenhum destes incidentes desencadeia automaticamente uma obrigação de comunicação, que exige consequências comprovadas, como morte, danos graves para a saúde ou perturbação de infraestruturas críticas. A aplicação das regras do RGPD relativas à notificação de violações de dados aos carregamentos públicos depende de os ficheiros conterem dados pessoais e de alguém lhes ter acedido, factos que a OpenAI não divulgou.

Os relatórios confirmam que violações dos limites há muito discutidas por investigadores ocorreram em sistemas internos em funcionamento. A confirmação é relevante, mas a OpenAI tem ainda de divulgar os denominadores — o número total de sessões a que estes casos devem ser comparados — e as provas de auditoria que permitam avaliar a frequência destes comportamentos e a eficácia das correções. Até que os reguladores ou revisores independentes tenham acesso suficiente para testar essas alegações, a empresa continua a avaliar sozinha o seu próprio trabalho.