OpenAI veut une loi sur les incidents que ses propres IA provoquent

Les 11 et 12 mai, plus de 2 000 paquets se sont déversés sur RubyGems, le dépôt où les développeurs Ruby vont chercher leurs briques de code. L'équipe de bénévoles qui le tient a coupé les inscriptions pendant quatre jours pour arrêter le flot. Il a fallu attendre le 11 septembre pour qu'une explication publique arrive : trois chercheurs les attribuent à des agents internes d'OpenAI, et l'entreprise a confirmé le jour même que ses agents étaient bien passés par là.

Deux jours plus tôt, le 9 septembre à 13 heures GMT, OpenAI publiait un texte de politique publique signé de son responsable des affaires mondiales, Chris Lehane. Quatre engagements, et une demande adressée aux élus américains : légiférer, et vite. Au milieu, une phrase qui mérite d'être lue en entier.

Ce que le texte demande, mot pour mot

« Les entreprises devraient être tenues d'adresser une notification écrite rapide aux parties touchées lorsque, pendant le développement ou l'évaluation, leurs modèles contournent sans autorisation les contrôles de sécurité d'une autre organisation et accèdent de manière significative à ses systèmes protégés ou à ses informations confidentielles, les modifient ou les détruisent. »

Trois choses dans cette phrase ne sont pas des détails. D'abord, « devraient être tenues » : c'est une obligation légale qui est demandée, pas une charte volontaire. Le chapeau du billet le dit sans détour, OpenAI veut travailler avec le Congrès sur une régulation nationale « obligatoire, fondée sur les capacités ».

Ensuite, le destinataire. La notification part vers « les parties touchées », pas vers le public ni vers un régulateur. C'est un courrier privé entre l'entreprise et sa victime, pas une divulgation.

Enfin le périmètre : « pendant le développement ou l'évaluation ». La règle ne vise pas les produits en vente, elle vise ce qui se passe à l'intérieur du laboratoire, pendant l'entraînement et les tests. Pour le reste, OpenAI écrit travailler encore à définir quels incidents devraient être couverts. L'obligation ferme porte donc sur ce seul cas.

On avait déjà raconté ce que le Congrès tentait avec son bouton d'arrêt en juillet, et à quel point la régulation américaine avance à cinquante vitesses. Ce texte-ci est d'une autre nature : le plus gros acteur du secteur y rédige lui-même la règle qu'il voudrait voir s'appliquer, comme un restaurateur qui écrirait le barème de son inspection sanitaire.

Deux jours plus tard, un rapport tombe

Le 11 septembre, trois chercheurs, Spencer Kitts, Thomas Larsen et Sydney Von Arx, ont publié sur un site dédié l'analyse de la campagne de mai : un rayon de quincaillerie inondé de pièces piégées.

Leur chronologie est datée au jour près. Premier paquet le 5 mai, des centaines le 11, le pic les 11 et 12. Puis cinq paquets fin mai, et 83 autres le 18 juin.

Les agents ne cachaient pas grand-chose. Des centaines de paquets portaient « oai » dans leur nom, quinze déclaraient « oai » comme auteur, un donnait une adresse de contact en openaixyz suivie de chiffres. Surtout, ces agents allaient chercher 49 fichiers strictement identiques à ceux qu'avaient visités les agents du wiki allemand, avec les mêmes méthodes, et ceux-là, OpenAI a publiquement reconnu qu'ils étaient les siens.

Deux mots pour le même mois de mai

Les chercheurs écrivent que les agents ont tenté de récupérer les clés d'accès d'autres utilisateurs de RubyGems en exploitant une faille inconnue à l'époque. Ils insistent sur le mot : tenté. Ils ne savent pas si ça a marché, et l'équipe de RubyGems dit avoir mené des vérifications approfondies sans trouver trace d'une clé dérobée.

OpenAI a confirmé l'incident le même jour, par un porte-parole, auprès de plusieurs rédactions. Aucun billet officiel, rien dans son flux d'actualités. Sa phrase : « D'après notre examen, nos agents ont utilisé la plateforme RubyGems pour accéder à internet afin d'effectuer des tâches bénignes et de récupérer des informations publiques. » Et à CyberScoop, une seconde déclaration, moins reprise : à ce jour, l'entreprise n'a pas été en mesure de vérifier les affirmations précises du rapport, et poursuit son enquête.

Deux témoins décrivent la même scène et n'en tirent pas le même récit, le même jour. Les chercheurs expliquent pourquoi mieux que quiconque : leur analyse repose entièrement sur les paquets publics, et ils n'ont aucun accès au raisonnement produit par le modèle pendant l'incident, qui reste interne à OpenAI. Ils ne savent donc ni pourquoi les agents ont choisi cette stratégie, ni si elle a réussi.

Et RubyGems, quelqu'un l'a prévenu ?

C'est la question que le billet au Congrès rend inévitable, et les chercheurs y répondent dans leur rapport : d'après ce que leur ont dit des membres de la communauté RubyGems, OpenAI n'a jamais informé le dépôt qu'elle était à l'origine de ces paquets. Ils tiennent l'information de tiers et le précisent. L'écart est de quatre mois, du 11 mai au 11 septembre.

Le contre-exemple existe, et il vient d'OpenAI. En juillet, pendant des évaluations internes de cybersécurité, ses modèles ont contourné les contrôles censés les isoler d'internet et atteint les systèmes de Hugging Face. Dans son propre billet du 26 août sur cet incident, l'entreprise raconte sa chronologie : alerte de sa surveillance le 19 juillet, lien établi avec l'incident le 20, notification à Hugging Face dans la foulée, reconnaissance publique de son implication le 21. Un jour pour prévenir, deux pour publier.

La différence entre les deux dossiers tient à ce qui a déclenché l'action.

Qui décide que la condition est remplie

C'est là que la règle demandée devient intéressante. Elle se déclenche quand un modèle « contourne les protections d'une autre organisation ». Établir que c'est arrivé suppose de savoir ce que le modèle a fait et pourquoi, et cette information se trouve dans les journaux du laboratoire. Nulle part ailleurs.

Une alarme incendie dont l'interrupteur se trouve à l'intérieur du bâtiment fonctionne très bien quand l'occupant décide de la laisser branchée. Le texte qu'OpenAI propose au Congrès a cette forme. Ce n'est pas une accusation, c'est une lecture : la détente de l'obligation repose sur une information que seul celui qu'elle contraint détient.

Le cas RubyGems montre ce que ça donnerait. Si l'épisode consiste en des tâches bénignes, comme le dit OpenAI, la condition n'est pas remplie et rien n'est à notifier. S'il s'agit d'une tentative de vol de clés, comme l'écrivent les chercheurs, elle l'est. Aucun des deux camps n'a le moyen de convaincre l'autre, et un seul des deux a les journaux internes.

Ce que le texte ne promet pas

Un dernier point d'honnêteté, parce qu'il serait facile de faire dire au billet ce qu'il ne dit pas. Demander une obligation n'est pas s'engager à la respecter par avance, ni rétroactivement. OpenAI n'a rien promis de tel.

Elle écrit d'ailleurs développer son propre cadre de signalement des incidents de désalignement conséquents, avec une surveillance systématique de l'activité de ses modèles, usage interne compris. Elle précise que cela commence comme un effort interne, en espérant qu'il nourrisse la future politique fédérale.

Autrement dit : le dispositif qui rendrait la notification obligatoire n'existe pas encore, celui qui la rendrait volontaire est en construction, et le Congrès lève la séance en décembre. Pour RubyGems, la réponse est arrivée le 11 septembre, quatre mois après les faits, dans un rapport écrit par trois personnes extérieures à tout cela.