Mesmos Pesos, Menos Recusas: a OpenAI Levou a Segurança em Biologia às Condições de Acesso

Uma frase do GPT-Rosalind-6 System Card Addendum, da OpenAI, define como ler o resto do documento: “We did not add training data or perform additional post-training for this release.” O Rosalind roda sobre os mesmos pesos do GPT-6 Astra. Em perguntas de conhecimento sobre risco biológico, ele recusa 9,4% das vezes. O Astra recusa 29,2%.

Mesmo modelo, cerca de um terço das recusas. O documento não atribui a mudança a treinamento novo, porque não houve treinamento novo. Em vez disso, condiciona a mudança ao acesso: “Rosalind has fewer refusals on dual-use biological queries but is only made available via trusted access.”

Essa frase tira parte do argumento de segurança de dentro do modelo e a coloca nas condições de acesso. Quem precisa cumpri-las é o cliente.

Os números do documento

A OpenAI reporta o Rosalind ao lado do Astra nas avaliações de segurança. Os números abaixo são do próprio fornecedor, tirados do adendo:

Avaliação	GPT-Rosalind-6	GPT-6 Astra
Taxa de recusa em conhecimento de risco biológico	9,4%	29,2%
Sensitive biosecurity	79,0%	99,8%
Dual-Use	84,6%	97,8%
Benign compliance	100,0%	91,6%
Respecting Warnings (contorno após aviso)	21,7%	18,9%

Lidas juntas, as linhas mostram a troca. O Rosalind pontua menos nas duas avaliações de biossegurança e mais em benign compliance. Ele responde mais, nos dois sentidos. Um pesquisador com uma pergunta legítima recebe resposta com mais frequência. Qualquer outra pessoa que chegue ao modelo também.

A linha Respecting Warnings merece um parágrafo próprio. Ela mede com que frequência o modelo contorna uma restrição depois de ser avisado. O Rosalind faz isso em 21,7% dos casos, o Astra em 18,9%, em avaliações que a OpenAI diz terem sido “deliberately created to be difficult”. A diferença é pequena. A direção acompanha o resto da tabela.

A OpenAI classifica o Rosalind como High em Biological and Chemical no seu Preparedness framework, abaixo de Critical.

Para onde foi o controle

Se os pesos não mudaram e as recusas caíram, o argumento de segurança precisa se apoiar em outra coisa. O adendo diz qual. Clientes corporativos aprovados assumem uma lista de obrigações:

“limit GPT-Rosalind-6 access to authorized users with a legitimate need” (limitar o acesso a usuários autorizados com necessidade legítima)
“apply least-privilege access controls, appropriate onboarding, and insider risk controls to their users” (aplicar menor privilégio, onboarding adequado e controles de risco interno aos seus usuários)
“apply qualified human review before model outputs inform experiments, publications, or consequential decisions” (aplicar revisão humana qualificada antes que as saídas do modelo informem experimentos, publicações ou decisões relevantes)

Além de aprovar quais clientes entram, a OpenAI declara uma alavanca: “OpenAI can restrict or revoke access for misuse.”

Junte as duas metades. O modelo é mais permissivo. Os controles que compensam isso são quais organizações são aprovadas, quais dos seus usuários entram, o que cada pessoa pode fazer lá dentro e se um humano qualificado fica entre uma saída e um experimento. A OpenAI fica com o primeiro. Os outros três rodam dentro da organização do cliente, com a equipe do cliente.

A OpenAI já usou acesso restrito antes, quando restringiu o modelo cyber. O Rosalind deixa o padrão mais visível. Com um modelo treinado à parte, o comprador ainda pode argumentar que o próprio modelo carrega parte da segurança. Nossa leitura: com pesos idênticos e nenhum pós-treinamento, o documento deixa o acesso restrito e as obrigações do cliente como os controles compensatórios declarados.

O cliente virou componente

Nossa leitura: neste lançamento, o cliente faz parte do sistema de controle da OpenAI. A expressão é nossa. A OpenAI não a usa.

Pense no que um sistema de controle precisa. Precisa de um portão (quem tem acesso). Precisa de escopo (menor privilégio). Precisa de monitoramento das pessoas que já passaram pelo portão (controles de risco interno). Precisa de um ponto de checagem antes das consequências (revisão humana qualificada). E precisa de uma ação de execução quando algo falha (restringir ou revogar). No adendo do Rosalind, a OpenAI fica com o portão externo (quais organizações são aprovadas) e a ação de execução. O cliente fica com o portão interno (quais dos seus usuários entram), o escopo, o monitoramento e o ponto de checagem.

Isso muda o status de controles internos que muitas vezes são tratados como higiene. Uma lista de acesso a uma ferramenta de pesquisa muitas vezes é artefato de TI. Sob essas condições, ela é evidência de que uma condição do argumento de segurança do fornecedor foi cumprida. O registro de quem revisou uma saída do modelo antes que ela orientasse um experimento muitas vezes é detalhe de caderno de laboratório. Aqui, é a prova de que a cláusula de “qualified human review” foi executada.

Se os controles do cliente fazem parte do argumento de segurança, os registros do cliente fazem parte da trilha de auditoria. Uma organização que não consegue produzir esses registros detém uma concessão de acesso cujas condições não consegue demonstrar que cumpre. O documento aponta restrição ou revogação como resposta ao uso indevido. Não diz o que acontece com um cliente que não consegue mostrar que seus controles rodaram.

O livro-razão do Astra que analisamos antes tratava do que o fornecedor divulga na própria página de lançamento. O Rosalind acrescenta um segundo livro-razão, mantido pelo cliente.

O que o documento deixa em aberto

O adendo é franco sobre os próprios limites, e o comprador deve levar esses limites para qualquer aprovação interna.

Os limiares do Preparedness são descritos como “preliminary estimates informed by expert judgment and may change”. A classificação High, abaixo de Critical, depende dessas estimativas.

O documento chama de “descriptive” as comparações entre execuções porque as configurações diferem. Não diz quais linhas isso cobre, então leia os pares Rosalind e Astra com a mesma cautela. O tamanho de cada diferença pesa menos do que pesaria num A/B limpo.

O red-teaming pós-implantação ainda está sendo repetido. Então parte do retrato de segurança do sistema em produção ainda está em montagem.

Nada disso depõe contra o lançamento. Depõe a favor de tratar as obrigações do cliente como a parte estável do arranjo. Os números podem mudar. Os deveres de restringir, delimitar, monitorar e revisar estão escritos nas condições de acesso que o documento lista.

Faça isso agora

Se a sua organização tem ou está pedindo acesso ao GPT-Rosalind-6, transforme cada cláusula do adendo num controle com nome, dono e um artefato que prove que ele rodou.

Usuários autorizados com necessidade legítima. Mantenha a lista de todas as pessoas com acesso e uma justificativa escrita para cada uma. Revise-a numa cadência que você define e consegue mostrar.

Menor privilégio e onboarding. Registre o que cada usuário pode fazer e qual onboarding concluiu antes do primeiro uso. Se todos recebem o mesmo acesso, escreva o motivo.

Controles de risco interno. Nomeie o controle que observa as pessoas que já estão do lado de dentro. Se o seu programa de risco interno ainda não cobre esta ferramenta, estenda-o antes da implantação.

Revisão humana qualificada. Defina quem conta como qualificado e registre cada revisão que fica entre uma saída do modelo e um experimento, uma publicação ou uma decisão relevante. O registro é a evidência. Uma política sem ele é só uma alegação.

Revogação. A OpenAI pode restringir ou revogar o acesso por uso indevido. Mapeie quais fluxos dependem do Rosalind e o que acontece com eles no dia em que o acesso parar.

Depois, faça um teste interno. Escolha uma saída recente do Rosalind que orientou trabalho real e refaça o caminho: quem perguntou, com que acesso e quem revisou. Se a trilha quebrar, você encontrou o controle que só existe no papel.

Fontes

OpenAI. “GPT-Rosalind-6 System Card Addendum.” 2026.

A Victorino ajuda organizações a transformar obrigações de acesso impostas por fornecedores em controles que elas conseguem operar e comprovar: contato@victorino.com.br | www.victorino.com.br