Gouverner les agents IA qui agissent sur vos systèmes de référence

La plupart des programmes de gouvernance de l’IA en entreprise ont été conçus pour un monde où l’IA produit un résultat et où une personne décide de la suite à lui donner. Un modèle note une demande de crédit. Un assistant rédige un e-mail. Un chatbot répond à une question sur une politique interne. L’humain reste au centre, et c’est lui qui répond de l’action.

Les agents IA bouleversent cet équilibre. Un agent peut consulter une fiche client, estimer qu’une action s’impose, puis l’exécuter : mettre à jour un champ dans le CRM, émettre un bon de commande dans l’ERP, clôturer un dossier de service ou modifier un paramètre de compte dans une plateforme bancaire cœur. Le résultat n’est plus une suggestion. C’est une modification d’un système de référence.

J’ai passé plus de vingt ans à déployer et à exploiter ces systèmes de référence, et l’enseignement est constant : le risque réside dans ce qui est écrit, pas dans ce qui est dit. Cet article explique pourquoi les agents exigent des contrôles différents et à quoi ressemble un cadre de contrôle réaliste.

Pourquoi répondre et agir ne comportent pas les mêmes risques

Un modèle qui génère une réponse peut se tromper, être biaisé ou mal expliqué. Ce sont des risques réels, mais ils sont généralement contenus par la personne qui lit la réponse. Un agent qui agit ajoute une nouvelle série de risques, plus proches du risque opérationnel que du risque de modèle.

• L’échelle. Une instruction erronée peut être exécutée des milliers de fois avant que quiconque ne s’en aperçoive, car les agents ne se fatiguent pas et ne s’arrêtent pas pour remettre en question une tendance.
• La portée. Les agents utilisent souvent des identifiants d’intégration créés pour des échanges entre systèmes, qui peuvent conférer des accès bien plus larges que ceux d’un collaborateur pris isolément.
• L’enchaînement. Le résultat d’un agent peut devenir l’entrée d’un autre, de sorte qu’une erreur peut se propager entre systèmes et équipes.
• La réversibilité. Certaines actions, comme l’envoi d’une communication à un client ou un transfert de fonds, ne peuvent pas simplement être annulées.
• La responsabilité. Lorsqu’une donnée est modifiée, auditeurs et régulateurs demanderont qui a fait la modification et sous quelle autorité. « C’est l’IA » n’est pas une réponse acceptable.

Rien de tout cela ne signifie qu’il faille éviter les agents. Cela signifie que le modèle de gouvernance doit passer de la revue des résultats au contrôle des actions.

Connaître chaque agent et le rattacher à une identité

On ne peut pas gouverner ce que l’on ne voit pas. Le premier contrôle est un inventaire tenu à jour de tous les agents en service, qu’ils soient développés en interne, intégrés à une plateforme éditeur ou activés par une équipe métier au sein d’une application existante.

Pour chaque agent, l’inventaire devrait au minimum consigner :

• Finalité et responsable. La raison d’être de l’agent et le responsable métier nommément désigné qui répond de son comportement.
• Systèmes et données. Les systèmes de référence qu’il peut lire et modifier, et les niveaux de classification des données qu’il traite.
• Actions. Les opérations précises qu’il peut effectuer : créer, modifier, supprimer, approuver, envoyer ou payer.
• Modèles et fournisseurs sous-jacents. Les modèles sur lesquels il s’appuie et qui les fournit.
• Niveau de risque. Une notation fondée sur l’impact de ses actions, qui détermine ensuite tous les autres contrôles décrits ci-dessous.

Beaucoup d’organisations découvrent que des agents sont déjà actifs dans des plateformes dont elles détiennent les licences, activés par un simple paramètre de configuration plutôt que par un projet formel. L’inventaire initial est souvent la première étape la plus utile.

Ensuite, chaque agent devrait agir sous sa propre identité, et non sous un compte de service partagé ni sous les identifiants de la personne qui l’a configuré. Cette identité devrait être enregistrée dans vos processus de gestion des identités et des accès, comme tout autre utilisateur à privilèges.

Les habilitations devraient suivre le principe du moindre privilège au niveau des objets, des champs et des opérations. Un agent qui met à jour le statut d’un dossier n’a pas besoin de modifier les coordonnées bancaires d’un client. Un agent qui prépare des ordres de paiement n’a pas besoin du pouvoir de les valider. Lorsqu’un agent agit pour le compte d’un utilisateur donné, il ne devrait pas hériter de plus de droits que cet utilisateur lui-même.

C’est un terrain familier pour quiconque a mené des revues d’accès sur des plateformes CRM ou ERP. La différence est que les habilitations des agents sont souvent accordées rapidement, pendant un pilote, puis jamais réexaminées. Intégrez les identités des agents à la recertification périodique des accès dès le premier jour.

Fixer les seuils d’approbation selon le risque, pas selon l’habitude

L’« humain dans la boucle » est souvent traité comme un simple interrupteur. En pratique, il devrait s’agir d’un ensemble de seuils liés au niveau de risque de chaque action.

• Autonome. Les actions à faible impact et facilement réversibles, comme étiqueter un dossier ou mettre à jour une note interne, peuvent s’exécuter sans revue, sous réserve d’une surveillance.
• Humain en supervision. Les actions à impact modéré s’exécutent automatiquement, mais une personne examine a posteriori des échantillons ou les exceptions et peut intervenir.
• Humain dans la boucle. Les actions à fort impact, comme les modifications de données financières des clients, les décisions de crédit, les paiements ou les communications externes, exigent une approbation explicite avant de prendre effet.
• Interdit. Certaines actions ne devraient jamais être déléguées à un agent, quels que soient les contrôles.

Les seuils devraient aussi tenir compte des volumes et des montants. On peut confier à un agent l’octroi d’un petit geste commercial, mais pas l’émission de centaines en une heure, ni d’un geste au-delà d’un montant fixé. Les approbateurs ont besoin d’assez de contexte pour prendre une vraie décision, faute de quoi l’approbation devient une simple formalité.

Intégrer garde-fous, journalisation et surveillance dès la conception

Les garde-fous sont les limites techniques qui s’appliquent quelle que soit la décision du modèle. Ils comprennent le filtrage des entrées et des sorties, des règles de validation sur les données que l’agent écrit, des limites de fréquence, des plafonds de dépenses et de montants, des restrictions sur les outils qu’un agent peut appeler, et des protections contre l’injection de prompts provenant de contenus non fiables, comme les e-mails ou documents entrants.

La journalisation des activités est ce qui transforme un agent, boîte noire, en un système auditable. Pour chaque action, vous devriez pouvoir reconstituer :

• quel agent a agi, sous quelle identité et pour le compte de qui ;
• ce qui l’a déclenché et sur quelles informations il s’est appuyé ;
• quelle version du modèle et de la configuration était utilisée ;
• ce qu’il a modifié, avec les valeurs avant et après ;
• qui l’a approuvé, lorsqu’une approbation était requise.

Les journaux devraient être protégés contre la falsification, conservés conformément à vos politiques d’archivage et reliés à la piste d’audit du système de référence lui-même, afin qu’une modification faite par un agent ne se distingue pas d’une modification humaine lorsqu’un auditeur la retrace.

La surveillance exploite ensuite ces journaux pour détecter dérives et usages abusifs : volumes inhabituels, actions en dehors des heures normales, hausse des taux de correction par des humains, ou modifications concentrées sur certains clients ou comptes. Le comportement des agents évolue avec les données, les prompts et les modèles sous-jacents ; la surveillance doit donc être continue, et non un test ponctuel avant la mise en service.

Préparer la gestion des incidents et le retour arrière avant d’en avoir besoin

Tout agent qui écrit dans un système de référence a besoin d’un plan de gestion des incidents, rédigé et testé avant la mise en production. Ce plan devrait au minimum couvrir :

• Un arrêt d’urgence. Un moyen rapide et bien compris de suspendre un agent ou de révoquer ses habilitations sans arrêter l’ensemble de la plateforme.
• L’analyse du périmètre d’impact. La capacité d’identifier, à l’aide du journal d’activité, chaque donnée touchée par un agent sur une période donnée.
• Le retour arrière. Une méthode éprouvée pour restaurer les données concernées dans leur état antérieur, et un processus clair pour les actions irréversibles, comme la remédiation auprès des clients.
• L’escalade. Des circuits définis vers vos processus existants de risque opérationnel, de sécurité de l’information et, le cas échéant, de notification aux régulateurs.

La bonne nouvelle est que la plupart des organisations disposent déjà de ces capacités pour d’autres systèmes. Le travail consiste à les étendre aux agents et à s’assurer que les équipes qui les exploitent savent que les agents entrent dans leur périmètre.

Par où commencer

La gouvernance des agents n’exige pas une nouvelle bureaucratie. Elle exige d’appliquer délibérément des disciplines existantes, notamment la gestion des identités, la gestion des changements, le risque opérationnel et l’audit, à un nouveau type d’acteur. Une séquence de départ judicieuse consiste à inventorier ce qui est déjà en service, à le classer selon l’impact de ses actions, à resserrer habilitations et approbations pour les niveaux les plus élevés, et à vérifier que vous pouvez journaliser, surveiller et annuler ce que font ces agents.

Bien menée, cette démarche ne freine pas l’adoption. Elle donne aux dirigeants métier, aux équipes risques et aux régulateurs la confiance nécessaire pour confier davantage aux agents.

Cet article est fourni à titre d’information générale et ne constitue pas un conseil juridique ou réglementaire.