L’argument commence par un aveu
Dans un message publié samedi après-midi, intitulé « Models as Insider Risks in the Super Intelligence Era » (« Les modèles comme risques internes à l’ère de la super-intelligence »), le directeur général de Microsoft, Satya Nadella, soutient que les organisations qui déploient des modèles de pointe devraient emprunter les contrôles qu’elles appliquent déjà aux personnes puissantes de la maison, et cesser de prendre les garanties d’un fournisseur pour un substitut aux leurs.
L’argument s’ouvre sur quelque chose que personne ne sait faire aujourd’hui. Avec le logiciel classique, écrit Nadella, « nous disposions des outils et de la capacité de remonter d’un comportement à un chemin de code précis ». Avec les modèles de pointe, « nous ne pouvons pas rattacher les comportements et les sorties du modèle à des entrées précises des données d’entraînement ni à des configurations de poids » — et pourtant ces modèles sont déployés, écrit-il, « avec accès à nos données les plus sensibles et avec la capacité d’entreprendre des actions critiques en notre nom ».
Sa conclusion est un transfert de responsabilité, pas de confiance. « Nous ne pouvons tout simplement pas externaliser la responsabilité de ce que l’intelligence fait en notre nom », écrit-il. « Les garanties d’un fournisseur de modèle ne nous déchargent pas de cette responsabilité. » La formule qu’il emploie pour l’objectif de conception : « il faut séparer la fourniture d’intelligence de l’autorité sur celle-ci ».
Pourquoi les contrôles doivent être hors du modèle
L’objection de Nadella à la solution évidente — faire surveiller un modèle par un autre — est qu’elle ne réduit pas l’opacité, elle l’empile. « On peut et on doit utiliser des modèles pour se tester et se vérifier mutuellement de manière contradictoire », écrit-il. « Mais on finit alors avec un modèle opaque à l’intérieur d’une couche d’orchestration opaque, surveillé par un autre modèle opaque. Essentiellement des boîtes noires imbriquées. »
L’alternative qu’il invoque est plus ancienne que le domaine. Les contrôles qui régissent ce à quoi un modèle accède et ce qu’il peut faire « doivent se situer en dehors du modèle », au nom d’« un principe de sécurité informatique qui remonte aux années 1970 : un programme ne doit pas pouvoir contourner ni altérer les mécanismes qui appliquent ses permissions ». Concrètement, cela signifie séparer le modèle du harnais qui orchestre son travail et de l’espace d’actions qui définit ce qu’il peut faire.
Il fixe aussi un plancher de transparence du raisonnement, et nomme ce qu’il refuse de voir servir d’excuse. La transparence de la chaîne de pensée est « non négociable », écrit-il, et « le “neuralais” ne peut pas justifier l’opacité du raisonnement du modèle » — tout en concédant que la transparence seule n’est pas fiable, car « nous ne savons pas encore rendre les sorties des modèles systématiquement fidèles ou transparentes ».
Sept principes, dont le frein
Le message énumère sept principes de conception. Diversité des modèles : aucun modèle ne doit être l’unique dépendance d’un résultat important, ni vérifier son propre travail. Tout observer : « Toute action significative du modèle doit laisser une preuve lisible par un humain et inviolable. » Vérifiabilité : tester le système entier, y compris les échecs, les attaques et les cas limites, pas seulement les tâches réussies. Contrôles indépendants : une organisation doit pouvoir décider elle-même de ce qu’un modèle atteint et fait. Auditabilité indépendante : « Aucun modèle ne doit contrôler à la fois le comportement d’un système et les preuves nécessaires pour déterminer si ce comportement est conforme à l’intention initiale. »
Vient ensuite le confinement, la ligne qui a le plus voyagé. « Nous devons supposer qu’un modèle est compromis et le confiner dès le départ », écrit Nadella. « Voyez cela comme un frein d’urgence. Une personne autorisée doit toujours pouvoir mettre en pause ou arrêter un modèle en cours de tâche. » Les modèles plus capables, ajoute-t-il, exigeront des techniques de confinement que le secteur devra normaliser.
Le septième porte sur la divulgation des incidents : quand ces systèmes échouent ou sont compromis, il faut « une divulgation rapide aux personnes concernées » et un moyen de partager ce qui a mal tourné, quels contrôles ont cédé et comment éviter que cela se reproduise — y compris, précise-t-il, les détails d’implémentation qui modifient le comportement des agents à l’exécution.
Ce qu’il faut surveiller
Nadella n’engage Microsoft sur rien de précis, et ces principes sont formulés comme un argument, non comme une feuille de route produit ou une norme. Ce qui les rend malgré tout dignes d’intérêt, c’est qui les formule et la direction qu’ils indiquent : s’éloigner de la question de savoir si tel modèle est digne de confiance, pour construire des systèmes qui n’en ont pas besoin. Sa dernière phrase le dit sans détour : « Le système de super-intelligence le plus digne de confiance ne sera pas celui dont le modèle nous inspire le plus confiance. Ce sera celui qui nous permet de faire le moins confiance possible au modèle. »
Deux des sept — l’observabilité et la divulgation des incidents — font par ailleurs l’objet de batailles politiques en cours. Reste à voir si Microsoft les défendra dans ces enceintes, et pas seulement sur le fil de son directeur général.
