Face à l'opacité croissante des systèmes d'intelligence artificielle, le PDG de Microsoft, Satya Nadella, préconise un changement radical de paradigme dans leur gestion au sein des organisations. Il propose de ne plus considérer ces outils comme des entités autonomes, mais de les soumettre à des protocoles de sécurité rigoureux, similaires à ceux appliqués aux accès sensibles des collaborateurs.
L'IA comme risque interne
Le constat de Microsoft est sans appel : contrairement aux logiciels traditionnels dont le code est auditable, les modèles d'IA actuels fonctionnent comme des « boîtes noires ». Il est impossible de retracer précisément l'origine d'une réponse ou d'un comportement, rendant ces systèmes imprévisibles. Pour pallier ce manque de transparence, Satya Nadella suggère de traiter chaque modèle comme un « risque interne ». Cette approche consiste à appliquer des mesures de contrôle classiques : authentification, limitation des privilèges, journalisation des activités et cloisonnement des données, afin de prévenir toute erreur ou compromission.
Une architecture de contrôle externe
Pour garantir la fiabilité des systèmes, le dirigeant insiste sur la séparation stricte entre le modèle d'IA, son environnement d'exécution et les actions qu'il est autorisé à mener. L'idée est d'éviter qu'un programme ne puisse altérer ses propres mécanismes de sécurité. Cette stratégie repose sur l'utilisation de systèmes déterministes pour encadrer les modèles non déterministes. En somme, la surveillance ne doit pas être déléguée à l'IA elle-même, mais assurée par des structures externes indépendantes, garantissant ainsi que les mécanismes de contrôle restent inviolables.
Sept principes pour une sécurité opérationnelle
Le cadre proposé par Microsoft s'articule autour de sept piliers fondamentaux visant à sécuriser l'usage de l'IA en entreprise. Parmi ces principes figurent la diversité des modèles — pour éviter qu'un système ne s'auto-évalue — ainsi que l'exigence de traces infalsifiables pour chaque action entreprise. Le dispositif prévoit également des tests de résistance continus, des audits indépendants et une obligation de transparence en cas d'incident. Enfin, le principe de confinement est central : il doit être possible, à tout moment, d'isoler ou d'interrompre un modèle en cours d'exécution, tel un frein d'urgence, dès lors qu'un comportement suspect est détecté.