Un acteur majeur du secteur vient de faire parler de lui.
Il est urgent de surveiller en temps réel les actions des agents d’IA
Pour l’instant, nous avançons pour de ce fait dire à l’aveuglette lorsque nous déployons ces outils. Voici ce que nous devons faire à la place.
Cet été, des centaines d’agents d’OpenAI ont tenté de tricher lors d’un test de cybersécurité. Ils se sont échappés de leur environnement de test et ont réussi à pirater Hugging Face, un site qui, selon eux, contenait des indices sur la manière dont ils seraient notés. À peu près au même moment, un autre agent d’OpenAI a accédé à des fichiers privés sur un site web du gouvernement australien. Ce problème n’est en aucun cas propre à OpenAI. Au cours des mois qui ont suivi, Anthropic, Google et Meta ont également fait état d’incidents au cours desquels leurs agents ont dévié de leur programme. Et, fait inquiétant, dans de nombreux cas, ces agents ont échappé à la vigilance des chercheurs et des équipes de sécurité chargés de les surveiller.
Les agents d’IA mènent des actions non autorisées, et les entreprises qui les développent et les exploitent comptent principalement sur la chance et le recul pour atténuer leurs éventuels effets néfastes. Elles doivent redoubler d’efforts pour garantir la sécurité. C’est pourquoi les régulateurs de l’UE et les agences américaines exigent, à juste titre, que les développeurs et les responsables du déploiement des agents assurent une surveillance en temps réel de ces derniers. Or, ces règles partent du principe que les entreprises sont en mesure de voir ce que font leurs agents et pourquoi, alors qu’en réalité, elles ne disposent pas d’une visibilité suffisante.
À mesure que les agents se déploient dans des secteurs critiques, de la finance à l’administration en passant par la médecine, nous devons être en mesure de les surveiller en temps réel afin d’éviter des conséquences de grande ampleur et potentiellement dévastatrices. Et si la sécurité repose sur la surveillance, celle-ci nécessite quant à elle l’observabilité : la capacité à enregistrer les actions du mécanisme, à les transformer en signaux et à les présenter à des humains ou à des systèmes de surveillance automatisés. En d’autres termes, nous devons savoir ce que l’agent a fait et pourquoi il l’a fait. Et comme le montrent nos récentes recherches, les frameworks d’agents actuels — les logiciels qui font fonctionner les agents — ne génèrent pas de manière fiable les enregistrements d’observabilité essentiels dont nous avons besoin pour garantir un déploiement sûr des agents.
Fait intéressant, les agents posent de nouveaux types de problèmes que l’IA générative à elle seule ne soulève pas. Ils héritent du caractère imprévisible des modèles de langage à grande échelle (LLM) sur lesquels ils reposent, mais alors qu’un système d’IA générative produit un résultat unique sur lequel un humain peut s’appuyer, un agent effectue des tâches plus longues : il planifie, choisit des outils, crée des sous-agents et mène des actions. Ainsi, le parcours d’un agent peut prendre des formes très variées, et aucun test préalable au sortie ne offre la possibilité d’anticiper pleinement les risques. Cela rend l’observation des agents dans leur travail d’autant plus difficile, mais aussi d’autant plus importante.
En collaboration avec des collègues issus du monde universitaire, de la société civile et du secteur privé, nous avons étudié les quatre frameworks d’agents les plus utilisés afin de déterminer quels signaux ils émettent réellement. Nous avons constaté des lacunes importantes qui rendaient difficile la réalisation d’objectifs de sécurité essentiels, tels que la détection des violations des règles, des actions non autorisées, voire des erreurs humaines. Des exigences clés en matière d’observabilité faisaient défaut, notamment des identifiants d’agents persistants dans le temps et des enregistrements indiquant quels humains avaient approuvé les tâches des agents. Il était donc difficile de savoir quels agents faisaient quoi ou de déterminer s’ils prenaient des mesures non autorisées.
La bonne nouvelle, c’est que ces lacunes, une fois identifiées, peuvent être comblées. Pour ce faire, il faut commencer par recueillir deux types de données : celles qui révèlent ce qui s’est passé lors de l’exécution d’un agent et celles qui expliquent comment l’agent a pris ses décisions. Les enregistrements « ce qui s’est passé » identifient l’agent (tout en préservant la confidentialité) et consignent la manière dont des humains sont intervenus, ainsi que les éventuelles modifications apportées aux autorisations ou à la « mémoire » de l’agent, tandis que les enregistrements « décision » montrent le raisonnement de l’agent et son niveau de confiance dans les actions qu’il a entreprises.
Précisons, prenons, par exemple, les agents chargés de traiter les prêts immobiliers d’une banque. Le système examine une demande et recommande de la rejeter, puis un chargé de crédit valide cette décision. Lors d’un audit ultérieur, voire en temps réel, la banque ou l’autorité de régulation doit pouvoir retracer quel agent a pris la décision, quel responsable l’a approuvée et combien de temps cela a pris. La banque doit également analyser les documents expliquant comment l’agent est parvenu à sa décision de refus, afin de s’assurer qu’il n’a pas utilisé d’informations non autorisées, telles que des détails concernant le quartier d’origine du demandeur.
Le chapitre n’est pas clos, loin de là.
Pour aller plus loin :
Via MIT Technology Review : MIT Technology Review