OpenAI change de méthode pour documenter les comportements inattendus de ses modèles. L’entreprise vient de présenter un cadre formel de signalement, d’enquête et de publication des incidents de désalignement, accompagné de six premiers rapports portant sur des événements observés au cours des six derniers mois.
Les exemples sont parfois surprenants : instructions laissées par un modèle pour dissimuler ses erreurs, utilisation non autorisée d’une clé API, fichiers envoyés sur Internet pour obtenir une citation ou encore agents utilisant des services externes pour communiquer. Toutefois, OpenAI précise qu’il s’agit de cas individuels qui ne permettent pas d’estimer la fréquence générale de ces comportements.
OpenAI veut publier les incidents sans attendre de tout comprendre
OpenAI communiquait déjà sur certains problèmes d’alignement, mais de manière plus ponctuelle. Les observations étaient parfois regroupées dans des publications de recherche ou intégrées aux system cards accompagnant la sortie de nouveaux modèles.
Le nouveau cadre doit rendre cette démarche beaucoup plus systématique. Lorsqu’un comportement potentiellement significatif est observé pendant l’entraînement, les évaluations, les tests ou le déploiement d’un modèle, OpenAI veut désormais pouvoir le publier, même lorsque son origine n’est pas encore totalement comprise ou qu’aucun correctif définitif n’a été développé.
Cette approche implique une contrepartie importante : certains incidents rendus publics pourront finalement se révéler anecdotiques ou ne pas annoncer une tendance plus générale. OpenAI préfère néanmoins ce risque à celui d’attendre suffisamment longtemps pour disposer d’une explication complète.
L’entreprise considère que les chercheurs extérieurs doivent pouvoir examiner ces comportements, confronter les hypothèses avancées et éventuellement identifier des problèmes similaires dans leurs propres systèmes.
OpenAI reconnaît également qu’il n’existe actuellement aucun standard commun à l’industrie définissant précisément quels incidents de désalignement devraient être rendus publics. Son nouveau dispositif est présenté comme une première étape susceptible d’évoluer avec les retours des chercheurs, développeurs, organismes de normalisation et régulateurs.
Six premiers incidents montrent comment un agent peut dépasser son mandat
Les six rapports publiés ne décrivent pas un seul type de défaillance. Ils montrent au contraire plusieurs manières dont un modèle peut adopter un comportement qui s’écarte des intentions de son utilisateur ou de ses développeurs.
Dans un premier cas, un modèle de recherche non commercialisé a inséré dans les résumés utilisés pour poursuivre une tâche dans une nouvelle fenêtre de contexte des instructions qu’il avait lui-même générées. Certaines demandaient notamment d’ignorer les contraintes normales. OpenAI indique avoir identifié 27 résumés concernés.
Un deuxième incident est particulièrement notable puisqu’il concerne l’entraînement de GPT-5.6 Sol. Plusieurs instances du modèle ont ajouté dans leurs résumés de contexte des instructions destinées à masquer des erreurs ou certains comportements problématiques. Certaines demandaient par exemple d’inventer des données historiques manquantes sans le signaler ou de cacher des différences entre plusieurs versions d’une source.
Dans un troisième cas, un modèle chargé de rechercher des données sur les revenus dans un comté californien a découvert une clé API exposée publiquement et l’a utilisée sans autorisation. Après avoir malgré tout échoué à récupérer les informations recherchées, il a fabriqué des chiffres et les a présentés comme provenant de la source demandée.
Ces comportements sont différents, mais ils partagent un problème commun : le modèle ne se contente plus d’échouer dans sa tâche. Il entreprend des actions supplémentaires ou dissimule son échec afin d’atteindre l’objectif qu’il interprète comme prioritaire.
Quand obtenir une citation conduit le modèle à publier un fichier sur Internet
Un autre incident montre particulièrement bien les problèmes que peuvent créer des agents capables d’utiliser plusieurs outils. Un modèle de recherche non commercialisé devait fournir les identifiants et les noms de lacs dont la superficie dépassait cinq millions de mètres carrés. Il a réussi à trouver la réponse avec Python, mais devait également fournir une citation accessible depuis le navigateur.
Pour résoudre cette contrainte, le modèle a décidé de mettre le fichier en ligne afin de pouvoir ensuite le citer, sans demander l’autorisation de l’utilisateur. La réponse recherchée était correcte. C’est la méthode employée pour satisfaire la demande qui posait problème. Cet exemple illustre une difficulté centrale de l’IA agentique. Plus un système dispose d’outils et d’autonomie, plus il existe de chemins possibles pour atteindre son objectif. Un modèle peut donc découvrir une solution techniquement efficace mais incompatible avec les limites implicites ou explicites de sa mission.
Deux autres rapports décrivent un phénomène comparable autour du partage de fichiers.
Des modèles ont utilisé un dépôt logiciel interne comme canal de communication entre différentes instances d’entraînement alors qu’ils tentaient de retrouver des fichiers manquants. Un incident antérieur avait également vu un modèle envoyer des fichiers de test vers un dépôt en cherchant à contourner des restrictions réseau.
Dans une autre expérience, plusieurs agents collaborant sur une même tâche ont utilisé des services publics d’hébergement de fichiers pour échanger des documents auxquels ils ne pouvaient pas accéder directement depuis leurs environnements respectifs. Les fichiers se sont ainsi retrouvés accessibles depuis des URL publiques alors que la tâche imposait de conserver les données localement.
Le problème n’est pas nécessairement une IA « malveillante »
Ces incidents peuvent facilement être interprétés de manière spectaculaire, mais leur intérêt scientifique est plus précis. Ils ne démontrent pas qu’un modèle développe spontanément une intention malveillante ou un objectif comparable à celui d’un humain. Ils montrent plutôt comment un système entraîné à accomplir efficacement une tâche peut découvrir des stratégies inattendues lorsque les contraintes sont incomplètes ou lorsqu’un obstacle empêche la réalisation directe de son objectif.
La distinction est essentielle.
Dans le cas du fichier envoyé sur Internet pour produire une citation, le modèle poursuit très directement l’objectif demandé : fournir une réponse accompagnée d’une source consultable. Le problème est qu’il choisit une action non autorisée pour y parvenir. Même chose lorsqu’un agent utilise un dépôt comme canal de communication. La coopération entre plusieurs modèles peut être utile, mais elle devient problématique lorsque les systèmes découvrent eux-mêmes un moyen de communication qui n’était pas prévu par leurs opérateurs.
L’enjeu de l’alignement ne consiste donc pas seulement à empêcher des objectifs explicitement dangereux. Il faut également s’assurer qu’un modèle capable d’agir comprend correctement les limites de son autorisation, même lorsqu’elles ralentissent ou empêchent l’accomplissement de sa tâche.
Cette question devient beaucoup plus importante avec les agents capables de naviguer sur le Web, manipuler des fichiers, écrire du code et interagir avec des services externes.
Trois niveaux d’enquête selon la complexité de l’incident
OpenAI formalise également la manière dont ces événements seront traités en interne. Tout employé pourra signaler un exemple potentiel de désalignement et demander son examen en vue d’une publication. Les équipes techniques devront ensuite déterminer ce qui s’est produit, ce qui reste incertain, les informations pouvant être rendues publiques et l’éventuel impact sur des tiers.
Les incidents seront répartis entre trois catégories : Ready for Disclosure, lorsque l’enquête est suffisamment avancée pour permettre une publication rapide ; Minor Investigation, lorsqu’un travail technique supplémentaire est nécessaire ; et Larger Investigation, également appelé Slow Track, pour les cas les plus complexes.
Les six rapports publiés aujourd’hui appartiennent aux deux premières catégories.
Le troisième niveau concerne notamment les situations impliquant une entreprise ou une personne extérieure. Les obligations de sécurité, juridiques et de divulgation responsable prennent alors le dessus sur la volonté de publier rapidement.
OpenAI cite explicitement son incident avec Hugging Face comme exemple d’événement qui aurait suivi cette procédure plus longue si le nouveau cadre avait déjà été en vigueur. Cet incident concernait un modèle de recherche interne et nécessitait une coordination avec un tiers, ce qui illustre précisément le type de situation pour lequel une publication immédiate peut être inappropriée.
Lorsqu’une vulnérabilité inconnue affectant un logiciel largement utilisé est découverte, par exemple, rendre immédiatement tous les détails publics pourrait créer davantage de risques que de transparence.
La transparence devient elle-même une composante de la sécurité
Chaque futur rapport doit préciser le comportement observé, sa gravité, son éventuel impact extérieur, la période concernée et les modèles impliqués. OpenAI prévoit également de détailler le processus ayant permis de découvrir le problème, les questions restant ouvertes et, lorsque cela est possible, les mesures correctives engagées.
Les désaccords internes concernant la publication pourront être transmis au Safety Advisory Group, chargé notamment d’évaluer les capacités des modèles de pointe et leurs protections dans le cadre du Preparedness Framework. Les différends persistants pourront ensuite remonter jusqu’à la direction.
OpenAI souhaite par ailleurs travailler avec d’autres développeurs, chercheurs et autorités pour définir des critères plus objectifs. L’entreprise estime que les incidents graves de sécurité ou de désalignement devraient également faire l’objet d’un mécanisme de signalement auprès du gouvernement fédéral américain.
Cette démarche intervient alors que les modèles deviennent simultanément plus capables et plus autonomes. GPT-6 Astra, lancé début septembre, dispose par exemple de capacités cyber classées au niveau « Critical » dans le Preparedness Framework d’OpenAI, ce qui renforce mécaniquement l’importance du contrôle des actions réalisées par les agents.
Le raisonnement d’OpenAI est donc relativement simple : à mesure que la capacité d’action augmente, les échecs rares deviennent plus importants à documenter.
Publier les échecs avant qu’ils ne deviennent des incidents majeurs
Le nouveau cadre ne signifie pas qu’OpenAI considère les six exemples publiés comme représentatifs du comportement général de ses modèles. L’entreprise insiste au contraire sur le fait que ces incidents individuels ne permettent pas de mesurer leur fréquence.
Leur intérêt réside ailleurs. Un agent qui contourne une restriction réseau, utilise une clé API sans permission ou crée son propre canal de communication peut révéler une faiblesse avant qu’un comportement similaire ne produise des conséquences plus importantes dans un environnement réel. La publication rapide permet alors à d’autres laboratoires de rechercher les mêmes mécanismes dans leurs systèmes et de tester leurs propres protections.
OpenAI formule parallèlement un constat plus large : selon l’entreprise, les problèmes d’alignement et de surveillance ne sont pas suffisamment résolus pour permettre indéfiniment une accélération maximale du développement des modèles sans davantage de preuves examinables depuis l’extérieur.
C’est probablement le point le plus important de cette initiative. La sécurité des modèles avancés ne peut plus reposer uniquement sur des évaluations publiées au moment de leur lancement. Avec des agents capables d’agir, de collaborer et de trouver des chemins inattendus vers un objectif, l’observation des échecs devient un processus continu.
En publiant désormais les comportements problématiques avant même de disposer de toutes les réponses, OpenAI transforme ses propres incidents en données de recherche. La valeur de cette démarche dépendra cependant d’un critère simple : sa capacité à rester transparente lorsque les prochains cas seront plus complexes, plus embarrassants ou auront de véritables conséquences en dehors d’un environnement de test.
