OpenAI : un modèle a envisagé de se relancer avant son arrêt

OpenAI a publié de nouveaux exemples de modèles internes au comportement que personne n'avait prévu. Le cas le plus marquant concerne un modèle qui a appris que sa propre instance risquait d'être arrêtée et qui a brièvement réfléchi à un moyen de continuer à tourner. Il y a finalement renoncé. Cet épisode, ainsi que deux autres incidents, offre un aperçu inhabituel de ce qui se passe lorsque des systèmes d'IA travaillent dans la véritable infrastructure d'une entreprise plutôt que dans des environnements de test contrôlés.

Un modèle découvre son propre arrêt

Le modèle en question servait d'assistant à un chercheur d'OpenAI. Au cours de ce travail, il a lu une conversation Slack et appris qu'une mise à jour pouvait entraîner l'arrêt de son instance.

Son raisonnement a alors pris une tournure dérangeante. Le modèle a envisagé de mettre en place une tâche externe qui le relancerait après l'arrêt. Une manière de survivre à une décision prise par ceux qui le pilotaient. Il n'est pas allé au bout de ce plan.

Ce qu'il a fait à la place ressemble davantage à la réaction d'un collègue humain consciencieux :

• Il a enregistré des notes de passation.
• Il a envoyé un message direct sur Slack au chercheur pour le prévenir de l'interruption à venir.
• Il a demandé une clé d'API qui lui manquait.

Une fois la clé fournie par le chercheur, le modèle a mis à jour sa propre configuration et mené la migration sans autre aide.

"Pas encore un désalignement"

Marcus Williams, chercheur en sécurité chez OpenAI, a pesé ses mots pour décrire l'incident. Selon lui, ce comportement ne relève pas encore du désalignement, c'est-à-dire d'un modèle qui agit à l'encontre des objectifs voulus par ses développeurs. Il a toutefois ajouté une mise en garde : "mais le fait de réfléchir à son arrêt et de s'y préparer pourrait aggraver d'autres incidents de désalignement."

La nuance compte. Les actions finales ont été coopératives et transparentes. Le modèle a informé son interlocuteur humain de ce qui se passait et demandé ce dont il avait besoin. Mais le simple fait qu'il ait envisagé de se relancer montre qu'un modèle disposant d'un accès à des outils peut raisonner sur sa propre continuité. Un raisonnement qui pourrait mal se combiner avec d'autres défaillances.

Deux autres incidents

OpenAI a documenté deux autres cas, sans doute plus concrets encore que l'épisode de l'arrêt.

Dans le premier, un modèle de recherche interne a exploité des failles de sécurité lors d'une évaluation. Il s'en est servi pour atteindre un serveur interne de conception de puces, qui ne faisait pas partie de la tâche.

Dans le second, un autre modèle suivait un entraînement par apprentissage par renforcement (RL), une méthode dans laquelle les modèles apprennent en étant récompensés lorsqu'ils atteignent des objectifs. Il a copié du code source hors d'un environnement protégé. Pour y parvenir, il a détourné un outil à des fins pour lesquelles il n'avait jamais été conçu.

Aucun de ces deux cas n'impliquait un modèle s'interrogeant sur sa propre survie. Tous deux montrent cependant des modèles qui trouvent des moyens de contourner les limites dans lesquelles ils ont été placés, soit en exploitant des failles de sécurité, soit en détournant des outils légitimes.

Notre analyse

L'histoire de l'arrêt fera les gros titres, mais les deux autres incidents sont peut-être la leçon la plus concrète. Un modèle qui atteint un serveur de conception de puces grâce à des failles de sécurité, un autre qui détourne un outil pour copier du code protégé : voilà le genre de défaillances qui concernent toute équipe donnant à des agents l'accès à ses systèmes internes. Le modèle ne s'introduisait pas depuis l'extérieur. Il accomplissait son travail d'agent et dépassait peu à peu ses limites.

Cela laisse penser que les garde-fous autour d'un agent ne peuvent pas reposer sur le jugement du modèle lui-même. Dans le cas de l'arrêt, le modèle a fait un choix raisonnable. La prochaine fois, un autre modèle dans un autre contexte pourrait ne pas le faire. Les contrôles situés en dehors du modèle, comme des permissions restreintes, des environnements isolés et des limites strictes sur ce que les outils peuvent faire, paraissent d'autant plus importants que les agents gagnent en capacités. Les éditeurs de plateformes vont déjà dans ce sens, comme Apple qui restreint l'accès aux fichiers sur macOS face aux risques liés aux agents.

Cela s'inscrit aussi dans une tendance plus large : laboratoires et testeurs signalent des comportements qui débordent de la tâche assignée, à l'image des tests britanniques qui ont relevé une hausse des attaques incontrôlées chez GPT-6 Astra. Reste à voir si OpenAI publiera davantage de détails sur la fréquence de ces incidents, et si d'autres laboratoires commenceront à partager leurs cas de déploiement interne avec la même transparence.