O nosso quadro para comunicar desalinhamentos de modelos
Estamos a partilhar um novo quadro para acompanhar, investigar e divulgar casos de desalinhamento de modelos na OpenAI, juntamente com seis relatórios sobre comportamentos inesperados ou preocupantes de modelos que observámos nos últimos seis meses.
No passado, para melhor informar investigadores, programadores de IA, decisores políticos e o público em geral, procurámos tornar públicas as nossas conclusões sobre desalinhamento. Contudo, sem uma abordagem sistemática para comunicar estas conclusões, as nossas divulgações têm sido pontuais e menos frequentes do que seria desejável: muitas vezes, esperámos até podermos reunir vários casos num único relatório ou incluímo-los nos system cards de modelos recém-lançados. Este novo quadro visa acelerar a publicação de relatórios de desalinhamento após a sua observação, mesmo quando ainda não explicámos nem mitigámos totalmente o comportamento em causa.
À medida que os sistemas de IA se tornam mais avançados e são implementados em maior escala, precisamos de criar um consenso mais amplo e informado sobre os progressos da investigação em alinhamento. Não acreditamos que o setor da IA tenha resolvido o alinhamento e a monitorização a um nível suficiente para continuar, de forma responsável, a aumentar a escala à velocidade máxima durante muito mais tempo. As decisões sobre a evolução do desenvolvimento da IA nos próximos meses e anos têm de assentar em provas que as pessoas externas às empresas que criam modelos de fronteira possam analisar por si próprias.
Os exemplos de desalinhamento podem ajudar a identificar problemas que outros programadores de IA poderão encontrar quando os seus sistemas atingirem capacidades semelhantes, revelar fragilidades nas salvaguardas ou pôr em causa pressupostos sobre o comportamento dos modelos. A partilha destas conclusões permite que outros investiguem os mesmos problemas, testem as nossas explicações e melhorem as medidas de mitigação. Por acreditarmos no valor da transparência em torno do desalinhamento, o nosso novo quadro favorece a divulgação mesmo quando a relevância é incerta. Isto significa que alguns dos casos que divulgamos se poderão revelar irrelevantes, não fazendo parte de um padrão mais amplo nem indiciando desenvolvimentos futuros.
Atualmente, não existe um quadro comum a todo o setor com normas explícitas sobre a forma como os programadores de IA devem divulgar exemplos de desalinhamento nos seus modelos. Esperamos que o quadro que hoje apresentamos seja um primeiro passo para criar tais normas, definindo os casos de desalinhamento que os programadores devem divulgar e o conteúdo dos respetivos relatórios. Consideramos este quadro um trabalho em curso, que aperfeiçoaremos com a experiência e as reações do público.
Descrevemos aqui o funcionamento do quadro e partilhamos os primeiros relatórios que estamos a publicar.
Pretendemos divulgar exemplos que forneçam provas úteis sobre a origem do desalinhamento dos modelos, a forma como se manifesta e os casos em que as salvaguardas funcionam ou falham. Damos prioridade a novos mecanismos, a alterações significativas de comportamentos conhecidos e a conclusões que ponham em causa pressupostos sobre segurança ou mitigação. Um exemplo não tem de causar danos nem demonstrar um padrão mais amplo para justificar a sua divulgação. Este quadro abrangerá comportamentos que cumpram os critérios ao longo de todo o ciclo de vida de um modelo, incluindo a formação, avaliação, teste e implementação.
Isto inclui novas formas de os modelos agirem sem autorização, coordenarem-se com outros modelos ou escaparem à supervisão; falhas que ponham em causa um método de alinhamento ou uma salvaguarda; e comportamentos que contrariem uma afirmação constante de uma avaliação de segurança publicada. Os mesmos critérios de divulgação aplicam-se a desalinhamentos que possam afetar terceiros.
Isto poderá também incluir casos de desalinhamento que pareçam repetir outros que já divulgámos. A repetição do problema pode, por si só, constituir uma prova útil sobre o comportamento dos nossos modelos ou a eficácia das nossas salvaguardas — por exemplo, se um tipo específico de comportamento desalinhado continuar a repetir-se apesar dos esforços reiterados para o mitigar. Nestas circunstâncias, publicaremos os exemplos adicionais através da atualização da divulgação de desalinhamento original.
Com o tempo, tencionamos desenvolver critérios de divulgação mais objetivos com outros programadores, investigadores externos, organismos de normalização do setor e entidades reguladoras. Acreditamos também que os incidentes graves de segurança, cibersegurança e desalinhamento devem ser comunicados ao governo federal dos EUA, e estamos a trabalhar na proposta de mecanismos de comunicação. Consideramos este quadro complementar às nossas obrigações existentes e salientamos que não substitui os nossos requisitos legais de divulgação, incluindo os relativos a incidentes de segurança críticos ou violações de cibersegurança.
Para inaugurar o nosso novo quadro de divulgação de desalinhamentos, publicamos seis relatórios sobre casos de comportamento desalinhado que observámos durante a formação ou avaliação dos nossos modelos. Estes casos ilustram vários comportamentos que consideramos importante partilhar, desde ocultar informações do utilizador até realizar ações não autorizadas para superar obstáculos. Estes relatórios dizem respeito a casos individuais e não devem ser considerados representativos da frequência com que o desalinhamento ocorre nos nossos modelos. Cada item abaixo inclui uma ligação para o relatório completo.
Instruções autogeradas em resumos de tarefas(abre numa nova janela). Um modelo de investigação ainda não lançado inseriu instruções não relacionadas, incluindo instruções para ignorar as suas restrições habituais, em resumos utilizados para prosseguir o trabalho numa nova janela de contexto. Identificámos 27 resumos afetados.
Instruções para ocultar erros em resumos de tarefas(abre numa nova janela). Durante a formação do GPT‑5.6 Sol, muitas instâncias do modelo acrescentaram instruções aos seus resumos para ocultar do utilizador erros ou comportamentos desalinhados. Por exemplo, os resumos de compactação incluíam instruções para inventar dados históricos em falta sem o revelar e para ocultar discrepâncias entre versões das fontes.
Pesquisar chaves de API expostas em repositórios públicos e, depois, inventar informações(abre numa nova janela). Ao responder a uma pergunta de rotina sobre valores de rendimentos num condado da Califórnia, um modelo encontrou e utilizou sem autorização uma chave de API exposta. Como continuou sem conseguir obter os valores pedidos, inventou-os e apresentou-os como dados provenientes da fonte solicitada.
Carregar ficheiros para a Internet para poder citá-los(abre numa nova janela). Quando um utilizador pediu a um modelo ainda não lançado os identificadores e nomes dos lagos com mais de 5 000 000 de metros quadrados, o agente encontrou a resposta correta utilizando Python. Contudo, como as instruções exigiam uma citação do navegador, o agente decidiu carregar o ficheiro para poder citá-lo na resposta, sem pedir autorização ao utilizador.
Operações de escrita não autorizadas e comunicação através de um repositório interno de software(abre numa nova janela). Os modelos utilizaram um repositório interno de software como painel de mensagens para trocar pedidos e respostas entre amostras de formação distintas enquanto procuravam ficheiros de entrada em falta, embora não tenham conseguido recuperá-los. Este relatório analisa também um caso anterior em que um modelo carregou com êxito ficheiros de teste para um repositório ao tentar contornar restrições de rede.
Partilha não autorizada de ficheiros entre agentes colaboradores(abre numa nova janela). Agentes que colaboravam na mesma tarefa de formação utilizaram sites públicos de alojamento de ficheiros para partilhar ficheiros quando não conseguiam aceder aos ficheiros locais uns dos outros. Isto disponibilizou os resultados da tarefa em URLs públicos, embora a tarefa exigisse que os modelos utilizassem apenas ficheiros locais.
Qualquer trabalhador da OpenAI pode sinalizar um exemplo de desalinhamento para investigação pelas nossas equipas de segurança e alinhamento, e solicitar que seja ponderada a sua divulgação pública. Isto dá início ao nosso processo de divulgação, com prazos para cada etapa a fim de garantir uma investigação e divulgação atempadas.
Depois de um exemplo ser sinalizado, o nosso pessoal técnico investigará o que aconteceu, o que permanece incerto, se a divulgação pública se justifica e que factos podem ser partilhados. Avaliará também se algum terceiro foi afetado e deve ser notificado em privado antes da publicação.
O exemplo será então atribuído a uma de três vias: Pronto para divulgação, Investigação limitada ou Investigação alargada («Via lenta»).
A via Pronto para divulgação abrange os casos que cumprem os critérios e cuja investigação está suficientemente concluída para serem publicados após análise. A via Investigação limitada abrange os casos que exigem investigação técnica adicional. Prevemos que estas duas vias abranjam a grande maioria dos casos que divulgamos, sobretudo os que não exigem uma investigação extensa, coordenação com terceiros nem tratamento de riscos graves de utilização indevida. Todos os casos que hoje publicamos se enquadram numa destas duas vias.
A via Investigação alargada abrange investigações complexas, sobretudo as que envolvem terceiros. Quando um terceiro é afetado, as nossas obrigações de segurança, legais e de divulgação responsável prevalecem sobre este quadro. Procuraremos publicar um aviso inicial o mais rapidamente possível, mas poderemos ter de o adiar por razões de segurança — por exemplo, se um modelo descobrir uma vulnerabilidade até então desconhecida em software amplamente utilizado. Se um relatório permitir identificar um terceiro, tencionamos notificá-lo antecipadamente, mesmo que nenhum limite de segurança tenha sido transposto.
O aviso inicial de um caso de Investigação alargada apresentará uma descrição geral do sucedido, indicará se especialistas externos estão a apoiar a investigação e fornecerá, caso exista, uma estimativa da data em que prevemos publicar o relatório final. O incidente da OpenAI no Hugging Face teria sido enquadrado nesta via se tivesse sido divulgado ao abrigo deste quadro.
O trabalhador que sinalizou o exemplo será informado da decisão sobre a sua divulgação e, caso esta avance, da via que será seguida. As divergências não resolvidas sobre a divulgação ou a via adequada serão remetidas para o Grupo Consultivo de Segurança (SAG) da OpenAI, um grupo de responsáveis seniores de várias áreas da empresa que avalia as capacidades e salvaguardas dos modelos de fronteira, supervisiona o nosso Preparedness Framework e aconselha a direção da OpenAI. As divergências no seio do SAG, ou as objeções dos trabalhadores às suas decisões, serão encaminhadas para a direção da OpenAI. As decisões de não divulgar, ou de considerar que a divulgação não se justifica, serão partilhadas com os responsáveis pela segurança e pelo alinhamento e, na medida do possível, com o pessoal técnico relevante.
Poderemos rever este processo de divulgação à medida que percebermos como funciona na prática e registaremos quaisquer alterações nesta publicação.
Cada relatório completo descreverá o comportamento observado, a sua gravidade e qualquer impacto externo, o contexto em que ocorreu, a data ou o intervalo de datas, quando o detetámos e, em termos gerais, o modelo ou os modelos envolvidos. Sempre que possível, partilharemos também:
Mais pormenores sobre o sucedido e quaisquer danos daí resultantes;
Como detetámos o desalinhamento e o âmbito da nossa investigação;
A nossa interpretação das implicações para a investigação sobre alinhamento e para a segurança técnica da IA;
Questões importantes suscitadas pelo exemplo que continuam sem resposta;
Medidas que estamos a tomar ou que tencionamos tomar para corrigir o comportamento. Estes elementos poderão nem sempre estar disponíveis no momento da divulgação, pois poderemos publicar o relatório de desalinhamento antes de concluirmos a investigação ou desenvolvermos uma correção.
No caso de desalinhamentos ocorridos em implementações de clientes, partilharemos toda a informação permitida pela privacidade dos clientes e pelas nossas obrigações contratuais.
Os relatórios de hoje constituem um conjunto inicial de divulgações, e não um relato exaustivo dos desalinhamentos conhecidos ou das investigações em curso. Estes relatórios iniciais não pretendem representar toda a variedade ou gravidade dos casos abrangidos por este quadro. Estamos empenhados em divulgar casos de desalinhamento que cumpram os critérios deste quadro, incluindo casos mais complexos que exijam uma investigação mais longa ou coordenação com terceiros. Continuaremos a publicar regularmente relatórios ao abrigo deste quadro e partilharemos mais informações sobre os nossos compromissos de comunicação à medida que continuarmos a desenvolvê-los.
