Le risque de l'IA agentique est la possibilité de préjudices ou de pertes survenant lorsqu'un système d'IA peut entreprendre des actions en vue d'un objectif avec une direction humaine étape par étape limitée. Le risque s'accroît lorsqu'un système peut utiliser des outils, modifier des données, communiquer avec d'autres systèmes ou déléguer du travail à d'autres agents.

Un agent peut planifier une séquence d'étapes, appeler des outils logiciels, récupérer des informations ou agir au nom d'un utilisateur. Cela peut rendre une tâche plus efficace, mais cela étend également l'autorité du système. Une fausse interprétation qui serait inoffensive dans une réponse textuelle peut avoir des conséquences plus importantes si l'agent peut envoyer un message, modifier un enregistrement, effectuer un achat ou lancer un autre processus.

La délégation modifie la limite du risque

La délégation d'agent à agent peut rendre plus difficile l'identification du système qui a pris une décision et des instructions qui l'ont façonnée. Chaque transfert peut modifier le contexte, les autorisations ou le niveau de vérification. Une organisation doit cartographier la chaîne des agents et des outils, limiter l'accès de chaque acteur à ce dont il a besoin et conserver des registres permettant d'attribuer les actions. Elle doit également tester le comportement de la chaîne lorsqu'un agent reçoit de mauvaises données, un objectif ambigu ou des instructions hostiles.

Lorsque plusieurs agents interagissent, leur comportement combiné peut ne pas être prévisible à partir du test de chacun d'eux de manière isolée. Les agents peuvent répéter des actions, amplifier des erreurs, se disputer des ressources partagées ou transmettre des hypothèses erronées. Cette émergence multi-agents est une préoccupation au niveau du système : surveiller un seul modèle ou une seule interface utilisateur peut faire passer à côté d'une activité ayant lieu dans l'ensemble du flux de travail connecté.

La surveillance doit s'exercer au niveau du système

La surveillance humaine n'a de sens que si une personne peut comprendre quand une intervention est nécessaire et peut agir avant qu'il ne soit difficile de réparer les dommages. Les points de révision doivent refléter l'impact et la réversibilité d'une action. Les étapes à faible impact peuvent être automatisées dans des limites claires ; les actions lourdes de conséquences ou externes peuvent nécessiter une confirmation, une double approbation ou un mode de fonctionnement restreint.

Un interrupteur d'arrêt d'urgence (kill switch) doit être conçu et testé comme faisant partie intégrante du système, et non laissé sous la forme d'une promesse informelle. Les équipes doivent savoir ce que l'interrupteur arrête, s'il révoque les autorisations d'outils et les tâches en file d'attente, et comment rétablir le service en toute sécurité. Un responsable désigné doit pouvoir mettre l'agent en pause, tandis que les intervenants en cas d'incident peuvent conserver les enregistrements et enquêter sur ce qui s'est passé.

Avant le déploiement, les organisations peuvent commencer par des autorisations restreintes, des tests en bac à sable et des limites d'action explicites. Pendant l'utilisation, elles doivent surveiller non seulement la qualité des sorties, mais aussi les appels d'outils, les modèles de délégation, les changements de portée des tâches et les tentatives de dépassement d'autorité. L'examen des risques doit être répété lorsque le modèle, les outils, les autorisations ou l'environnement opérationnel changent.