OpenAI lança o gpt-oss sob Apache 2.0 e chama-lhe model card, não system card

O que a OpenAI lançou, na prática

A OpenAI publicou dois modelos de raciocínio com pesos abertos, o gpt-oss-120b e o gpt-oss-20b, sob a licença Apache 2.0, acompanhados de uma política de utilização do gpt-oss. Ambos são apenas de texto e compatíveis com a Responses API da OpenAI.

O enquadramento é agentic. Os modelos foram construídos para seguir instruções, usar ferramentas como pesquisa na web e execução de código Python, e para raciocinar. Um detalhe relevante: os desenvolvedores podem ajustar o esforço de raciocínio, reduzindo-o em tarefas que não exigem raciocínio profundo. Os modelos são personalizáveis, expõem a cadeia de raciocínio completa e suportam Structured Outputs.

Para equipas que já integraram modelos fechados através da Responses API, essa compatibilidade é relevante. Significa que o gpt-oss pode encaixar num fluxo de trabalho existente de chamadas a ferramentas e saídas estruturadas, sem exigir uma nova camada de integração.

A cadeia de raciocínio é totalmente exposta

A OpenAI afirma que os modelos disponibilizam a cadeia de raciocínio completa. Para equipas de engenharia aplicada, um registo de raciocínio visível é útil para depurar o comportamento de agents, auditar chamadas a ferramentas e construir sistemas de avaliação que analisam os passos intermédios, e não apenas as respostas finais.

Essa transparência é consequência directa dos pesos abertos: não existe uma camada do lado do servidor a esconder o raciocínio. Isso tem duas faces: dá a quem constrói mais visibilidade, mas dá a qualquer outra pessoa essa mesma visibilidade sobre como o modelo chega às suas respostas.

Porque lhe chamam model card e não system card

A OpenAI é explícita quanto a esta escolha de nomenclatura. Como o gpt-oss será integrado em sistemas construídos e mantidos por muitos intervenientes diferentes, o documento descreve o modelo, não um sistema. A segurança de qualquer sistema implementado fica a cargo de quem o constrói.

Embora os modelos sejam concebidos para seguir, por defeito, as políticas de segurança da OpenAI, outros intervenientes tomarão e aplicarão também as suas próprias decisões sobre como manter esses sistemas seguros.Montana Labs

A empresa afirma também que o perfil de risco difere dos modelos proprietários: uma vez lançado, um atacante determinado pode fazer fine-tuning dos pesos para contornar recusas ou optimizar para causar dano, sem que a OpenAI tenha depois qualquer forma de adicionar mitigações ou revogar o acesso. Desenvolvedores e empresas são avisados de que poderão precisar de salvaguardas adicionais para replicar as protecções ao nível do sistema que acompanham os modelos servidos por API.

O teste de fine-tuning adversarial e o seu limite declarado

A OpenAI realizou avaliações de capacidade escaláveis sobre o gpt-oss-120b e relata que o modelo por defeito não atinge os limiares indicativos de Alta capacidade em nenhuma das três Categorias Monitorizadas da sua Preparedness Framework: Biológica e Química, Cibersegurança e Auto-melhoria de AI (mantém-se o acrónimo em inglês).

Depois, simulou um atacante fazendo fine-tuning adversarial do modelo para as categorias biológica/química e cibersegurança, recorrendo àquilo que descreve como a sua stack de treino de referência no sector. O Safety Advisory Group analisou os resultados e concluiu que o modelo continuava a não atingir Alta capacidade em nenhum dos dois domínios.

Sobre se este lançamento faz avançar a fronteira dos modelos abertos, a OpenAI diz que não: na maioria das avaliações, um ou mais modelos abertos já existentes têm desempenho próximo do gpt-oss-120b com fine-tuning adversarial, mesmo no seu estado por defeito. Ou seja, o argumento para o lançamento assenta, em parte, no facto de essa capacidade já estar disponível noutros locais.

A implicação concreta: a segurança passa para o integrador

A mudança concreta aqui é que a responsabilidade pelo comportamento de recusa e pela protecção ao nível do sistema passa dos servidores da OpenAI para quem implementa os pesos. A model card documenta os testes realizados antes do lançamento; não consegue vincular o que acontece depois do fine-tuning.

Para as equipas que adoptam o gpt-oss, isso significa que as salvaguardas que a API da OpenAI fornecia discretamente passam agora a ser itens que é preciso construir e assumir como próprios. A licença Apache 2.0 e a compatibilidade com a Responses API reduzem o custo de adopção; a model card deixa claro que a engenharia de segurança não vem incluída.