// CLUBIC — INTELLIGENZA ARTIFICIALE
Pour le patron de Microsoft, l'IA ne doit pas rester une boite noire
Dans un long message publié sur X, le patron de Microsoft explique qu'il faut traiter les modèles d'IA comme des risques internes, les surveiller de l'extérieur et pouvoir les arrêter à tout moment.
Satya Nadella a publié ce week-end un texte intitulé "Models as Insider Risks in the Super Intelligence Era". L'idée est simple : on ne peut pas déléguer à un fournisseur de modèles la responsabilité de ce que fait une IA à notre place.
Tout part d'un constat. Avec un logiciel classique, on peut remonter d'un comportement jusqu'à la portion de code responsable. Avec les modèles d'IA actuels, c'est impossible. À l'heure actuelle, on ne sait pas relier une réponse à des données d'entraînement précises ni à un réglage des poids (les paramètres où le modèle stocke ce qu'il a appris). Ces systèmes accèdent pourtant à des données sensibles et agissent pour le compte des entreprises. Nadella refuse d'y voir des "boîtes noires imbriquées" dont on accepte ou rejette simplement les réponses.
Il laisse de côté la question de l'alignement, c'est-à-dire de la conformité des modèles aux intentions de départ, et propose une approche d'ingénieur. Il s'agit d'entourer des modèles non déterministes (dont la réponse peut varier) de systèmes déterministes, de contrôles humains et de procédures fiables. Pour cela, il les traite comme des "risques internes", au même titre qu'un salarié aux accès étendus. Pas parce qu'ils seraient forcément malveillants, mais parce qu'ils peuvent se tromper ou être compromis. Les entreprises ont déjà des réflexes pour ce cas : établir l'identité, limiter les privilèges, journaliser l'activité, et cloisonner.
Pour le PDG de Microsoft, la transparence de la "chaîne de pensée" est non négociable, c'est-à-dire ces étapes écrites par le modèle avant de répondre. Il refuse aussi que le "neuralese" (le langage interne des modèles) serve d'excuse à l'opacité. Cela ne suffit pas, car on ne sait pas encore garantir que les réponses elles-mêmes soient fidèles et transparentes. Faire tester les modèles les uns par les autres est utile, mais on risque d'obtenir des boîtes noires qui en surveillent d'autres. Les contrôles doivent donc rester hors du modèle, selon un principe de sécurité basique des années 1970 : un programme ne doit pas pouvoir contourner ni altérer les mécanismes qui encadrent ses permissions. Concrètement, il faut séparer le modèle, le "harnais" qui orchestre son travail et l'ensemble des actions qu'il peut mener.
Ce dernier point suppose de considérer un modèle comme compromis dès le départ et de pouvoir le mettre en pause ou l'arrêter en pleine tâche, comme avec un frein d'urgence.