Cessez de vous demander si votre agent IA est autonome. Demandez-vous qui est responsable de ses actions.
Qualifier un agent IA d'entreprise d'autonome semble être un progrès. C'est aussi un moyen commode de faire disparaître la responsabilité.
Cette semaine, MIT Sloan Management Review et BCG ont posé un jalon utile : l'autonomie opérationnelle n'est pas une autonomie morale ou juridique. Un agent peut planifier, appeler des outils, répartir le travail et agir sans qu'une personne approuve chaque clic. Il ne peut cependant pas s'expliquer auprès d'un régulateur, absorber une perte ou faire face à un client après un mauvais résultat.
Cette distinction dépasse la simple sémantique. C'est la ligne de démarcation entre un programme IA pouvant évoluer en toute sécurité et un autre qui transforme chaque incident en chasse aux coupables.
La phrase dangereuse dans un examen d'incident n'est pas « l'agent a fait une erreur ». C'est « l'agent a décidé ». Un logiciel ne peut pas être propriétaire d'une décision. Ce sont les personnes qui ont choisi son objectif, accordé son accès, connecté ses outils et accepté son résultat qui le sont.
Le débat sur l'autonomie vise la mauvaise cible
La récente discussion sur l'autonomie des agents peut vite devenir abstraite. La question pratique est plus simple : que peut faire l'agent quand personne ne le surveille ?
Un agent qui rédige un résumé de réunion interne et un agent qui peut approuver un remboursement, mettre à jour un dossier fournisseur ou interroger un système de production peuvent utiliser le même modèle. Ils ne devraient pas recevoir le même traitement en matière de gouvernance.
Le panel de MIT Sloan souligne bien le point clé : les agents sont autonomes au sens opérationnel. Ils exécutent un travail délégué dans un système conçu par des humains. Cela signifie que l'unité de gouvernance pertinente n'est pas un employé numérique fictif. C'est tout l'environnement opérationnel autour de l'agent :
- le responsable métier qui a défini le résultat ;
- l'équipe qui a connecté les données et les outils ;
- l'identité et les permissions reçues par l'agent ;
- les chemins d'approbation et d'exception disponibles à l'exécution ; et
- les personnes responsables de sa surveillance et de son arrêt.
Cela importe car la plupart des échecs en entreprise ne commencent pas par une hallucination spectaculaire du modèle. Ils commencent par une automatisation ordinaire à qui on donne un peu trop de contexte, un peu trop d'autorité ou aucun propriétaire clair. Une politique disant « utiliser une supervision humaine » ne résout rien de tout cela.
La responsabilité doit être intégrée au workflow
L'Australian Institute of Company Directors a formulé cette semaine la version au niveau du conseil d'administration du même argument. Ses recommandations invitent les conseils à considérer le but, la validation, les exceptions et les dérogations, ainsi que la responsabilité dans les systèmes qui façonnent l'information qu'ils reçoivent. Ce sont aussi les bonnes questions pour tout workflow agentique.
Pour un responsable sécurité en entreprise, le test utile n'est pas « Avons-nous une politique IA ? » mais si chaque action significative d'un agent a une chaîne visible de responsabilité.
Commencez par un registre simple des actions. Pour chaque cas d'usage d'agent, documentez l'action, les données accessibles, les systèmes appelés, le responsable métier, le responsable technique, le seuil d'approbation et le mécanisme d'arrêt d'urgence. Si un champ est vide, l'agent n'est pas prêt pour la production.
Puis calibrez l'autonomie en fonction des conséquences, pas de la nouveauté. Les tâches à faible impact et réversibles peuvent fonctionner avec des contrôles allégés. Un agent qui envoie un brouillon pour revue n'est pas le même qu'un agent qui modifie un dossier client. Un agent qui recommande une correction n'est pas celui qui la déploie. Plus l'impact est élevé, plus les contrôles pour contourner doivent être stricts.
Ce dernier point est souvent oublié. Les portes d'approbation, permissions limitées et arrêts durs doivent exister dans l'architecture, pas seulement dans un prompt ou une page wiki. Un prompt peut être ignoré, mal interprété ou contourné par une instruction malveillante. Une identité de service à périmètre restreint et une porte d'approbation à l'exécution sont bien plus difficiles à écarter.
L'IA fantôme aggrave le problème de la responsabilité
Les programmes formels d'agents attirent la plupart de l'attention. L'IA fantôme est là où la responsabilité casse généralement en premier.
Un département peut connecter un assistant non approuvé à un lecteur partagé, donner à un agent navigateur l'accès à un portail financier ou activer une fonctionnalité IA dans un outil SaaS sans informer la sécurité. Le métier y voit un gain de productivité. L'équipe sécurité ne le découvre qu'après que des données sensibles ont franchi une frontière ou qu'une action a déjà été prise.
C'est pourquoi la découverte est un contrôle de gouvernance, pas seulement un exercice d'inventaire. Vous ne pouvez pas assigner un propriétaire, appliquer une règle de données ou définir un seuil d'approbation pour un agent dont vous ignorez l'existence.
Un programme mature combine visibilité continue et voie vers une adoption sécurisée. Trouvez les outils et connexions déjà utilisés. Classez le risque selon les données, permissions et actions possibles. Puis donnez aux équipes une voie approuvée plus simple que les contournements. Tout bloquer pousse l'activité dans l'ombre ; tout autoriser transforme la gouvernance en fonction post-mortem.
Quatre contrôles à mettre en place dès maintenant
1. Désignez un responsable avant le déploiement. Chaque agent doit avoir un propriétaire métier responsable des résultats et un propriétaire technique responsable de son intégration, de son identité et de ses contrôles. « L'équipe IA » n'est pas un propriétaire.
2. Utilisez des autorisations au niveau des actions. Accordez aux agents la moindre autorité possible pour la durée la plus courte possible. L'accès en lecture n'est pas un accès en écriture. Rédiger n'est pas envoyer. Recommander n'est pas exécuter.
3. Établissez des validations et arrêts significatifs. Exigez une approbation humaine pour les actions conséquentes ou difficiles à annuler. Rendez le contexte d'approbation riche en informations et permettez de révoquer l'accès ou d'arrêter rapidement un workflow en cours.
4. Enregistrez le chemin de décision, pas seulement la conversation. Une piste d'audit doit montrer le déclencheur, les entrées, les outils appelés, les autorisations utilisées, les validations humaines, l'action finale et toute exception. L'historique de la conversation seul n'explique pas un incident opérationnel.
La norme de gouvernance devient plus claire
Conseils d'administration, régulateurs, clients et intervenants d'incidents n'accepteront pas « c'est l'agent qui l'a fait » comme réponse. Ils demanderont qui a autorisé le cas d'usage, qui a fourni les données, qui a accordé l'accès et qui devait intervenir.
Ce n'est pas une raison pour éviter les agents. C'est une raison pour les déployer comme systèmes responsables plutôt que comme collègues magiques.
Aona aide les entreprises à découvrir l'IA fantôme, à comprendre où les données sensibles et les autorisations risquées sont exposées, et à mettre en place des contrôles pratiques autour de l'utilisation de l'IA avant qu'un incident ne révèle ces failles. Découvrez comment Aona aborde la sécurité de l'IA et la découverte de l'IA fantôme et commencez avec les workflows agents déjà en fonctionnement dans votre entreprise.
