Agents IA et délégation d'autorité : le nouveau point de contrôle des services régulés

La conversation sur les agents IA commence généralement par l’interface et atteint rarement la question qui compte pour une organisation régulée : que peut faire exactement cet agent au nom du client, qui lui a conféré ce droit, et comment ce droit est-il retiré ?

Un agent qui répond à des questions est un logiciel de recherche doté d’un meilleur langage. Un agent qui agit — vire des fonds, modifie des données contractuelles, dépose une demande, résilie un service — est un mécanisme de délégation d’autorité. La différence n’est pas technique. Elle est juridique et opérationnelle, et elle détermine l’ensemble de la conception des contrôles.

L’unité de conception est l’autorité déléguée

Il est utile de cesser de penser « l’agent » comme une chose unique et de décrire plutôt le mandat : qui est le mandant, quelles actions sont autorisées, dans quelles limites de montant et de durée, avec quelles exceptions, et comment le mandat prend fin. C’est l’analyse que les banques appliquent depuis toujours à une procuration ou à un mandat de prélèvement — la question est ancienne, seule l’identité de l’exécutant change.

Dès que le mandat est décrit ainsi, il devient évident quelles parties ne peuvent pas résider dans le modèle. Le périmètre, les plafonds et la révocation constituent un état qui doit être stocké et vérifié hors du modèle de langage, car il doit rester exact même lorsque le modèle se trompe.

L’identité et le consentement doivent survivre à la conversation

Le langage naturel exprime bien les intentions et prouve mal les autorisations. « Vire l’argent sur mon autre compte » n’établit ni le compte, ni le bénéficiaire, ni le montant, ni le moment, ni le droit d’en disposer. L’agent a besoin d’une session d’identité de confiance et d’un service d’autorisations structuré, extérieurs au modèle.

Dans les services de paiement, ce n’est pas une option de conception. La directive (UE) 2015/2366 et le règlement délégué (UE) 2018/389 relatif à l’authentification forte du client déterminent quand une authentification est requise et comment les éléments doivent être liés dynamiquement au montant et au bénéficiaire. Un agent n’écarte pas ces exigences ; il opère entre elles.

Là où une action doit être rattachée de manière fiable à une personne, le règlement (UE) n° 910/2014 fournit le cadre établi pour l’identification électronique et les services de confiance. Il constitue une base plus solide pour prouver le consentement qu’un enregistrement de conversation.

Placer une politique entre le modèle et l’action

L’erreur d’architecture la plus courante consiste à laisser le modèle appeler directement le service qui agit. Entre les deux doit se trouver une couche qui vérifie chaque action proposée au regard du mandat : est-elle dans le périmètre, dans le plafond, soumise à confirmation supplémentaire, ou relève-t-elle d’une catégorie qui ne se délègue pas.

Cette couche traduit également l’intention non structurée en instruction structurée. La confirmation présentée à l’utilisateur doit montrer en langage clair ce qui va se produire : ressource, bénéficiaire, montant, moment, frais, et si l’action est réversible. Qui ne comprend pas ce qu’il confirme a consenti formellement, non de manière éclairée.

Ce que la supervision financière attend

L’ACPR a mené des travaux exploratoires sur la gouvernance des algorithmes d’intelligence artificielle dans le secteur financier, portant notamment sur l’explicabilité, la gouvernance et l’évaluation des algorithmes, avec la lutte contre le blanchiment, les modèles internes et la protection de la clientèle parmi les domaines examinés.

Le point le plus utile en pratique est peu spectaculaire : l’externalisation ne déplace pas la responsabilité. Si l’agent est opéré par un prestataire, le pilotage, la surveillance et la constitution de la preuve restent chez l’entité supervisée, et doivent être sécurisés contractuellement avant la mise en production.

Les obligations existantes continuent de s’appliquer

Les décisions automatisées produisant des effets juridiques ou vous affectant de manière significative sont encadrées par le règlement général sur la protection des données, y compris le droit d’obtenir une intervention humaine et de contester la décision. Les lignes directrices du Comité européen de la protection des données et les recommandations IA et RGPD de la CNIL demeurent applicables, quelle que soit la réalisation de l’interface.

En parallèle, la législation sur l’IA introduit des obligations de transparence lorsqu’une personne interagit avec un système d’IA, ainsi qu’un régime distinct pour les systèmes à haut risque. Si l’agent sert un processus relevant de l’annexe III, les obligations de contrôle humain et de journalisation naissent indépendamment du caractère conversationnel de l’interface.

Le contrôle humain doit pouvoir changer le résultat

Une supervision qui ne peut rien arrêter est décorative. Le test pratique : une personne déterminée peut-elle mettre fin à un mandat en temps réel, a-t-elle le droit d’annuler une action dans une fenêtre définie, et cela se produit-il assez souvent pour prouver que le mécanisme fonctionne ? Une organisation qui n’a jamais utilisé le frein d’urgence ignore s’il est relié.

Concevez également le chemin de retour. Qui rembourse, qui informe la personne concernée, dans quel délai, et à qui remonte l’information. Le rétablissement fait partie de la conception des contrôles, il n’est pas la conséquence de leur échec.

Une remarque d’ordonnancement : traitez la question de la réversibilité avant celle du périmètre. Les équipes décident généralement d’abord tout ce que l’agent pourra faire, puis se demandent ce qui se passe en cas d’erreur. L’ordre inverse conduit presque toujours à un premier périmètre plus étroit mais tenable, parce qu’il fait apparaître rapidement quelles actions ne se reprennent pas proprement.

La preuve détermine ce qui sera démontrable

En cas de litige, la question n’est pas ce que l’agent a fait, mais ce qui peut être prouvé. La preuve minimale par action comporte six éléments : le mandant, le mandat au moment de l’action, la proposition exacte, la décision de la couche de politique, la confirmation de l’utilisateur et le résultat du service. Chacun doit être reconstituable indépendamment du modèle.

C’est là que la plupart des réalisations se révèlent faibles. L’enregistrement d’une conversation n’est pas la preuve d’une autorisation. Il montre ce qui a été dit, mais pas quels plafonds étaient en vigueur, quelle version de la politique s’appliquait, ni si la confirmation a été présentée de façon compréhensible. Rattachez aussi les versions : un mandat accordé sous une version de politique et exécuté après sa modification est une source de litige connue.

Tester le service, pas seulement le modèle

Les indicateurs du modèle — exactitude, taux d’erreur, qualité de sortie — ne répondent pas à la question de la sûreté du service. Testez le parcours complet : instruction ambiguë, session interrompue, authentification expirée, refus du service cible, action partiellement exécutée, utilisateur qui change d’intention en cours de route. La plupart des incidents réels naissent des états entre les étapes, non du texte produit.

Évaluez aussi l’accessibilité. L’agent comprend-il un utilisateur âgé, une personne au vocabulaire différent, ou quelqu’un qui désigne le même service autrement ? Sinon, une voie alternative utilisable doit exister — pas seulement un numéro de téléphone.

Choisir sa position stratégique délibérément

Détenir le point de contrôle

L’organisation construit sa propre couche de mandats, d’identité et de politiques. C’est l’option la plus coûteuse et la seule qui préserve la relation client lorsque les agents deviennent l’interface habituelle.

Se connecter à un agent tiers

L’organisation expose ses services pour qu’un agent tiers puisse agir sur eux. Moins cher et plus rapide, mais la relation client et la maîtrise de l’expérience passent à l’autre partie. Les conditions dans lesquelles cela est acceptable se décident à l’avance, pas au premier litige.

Être prêt sans déléguer l’action

L’organisation prépare interfaces, identité et preuves, mais ne délègue aucune action. Pour la plupart des entreprises de taille intermédiaire, c’est aujourd’hui la position raisonnable : elle préserve les options sans assumer un risque non pilotable.

À quoi ressemble un premier périmètre défendable

En pratique, un premier agent qui agit devrait rester délibérément étroit. Un périmètre défendable combine trois limites : une seule catégorie d’action, choisie parce qu’elle est réversible ; un plafond de montant et de fréquence assez bas pour qu’un défaut complet reste absorbable ; et une confirmation explicite de l’utilisateur avant tout effet externe. Ce n’est pas la version ambitieuse que réclame la démonstration, mais c’est celle qui survit au premier mois d’exploitation réelle.

Un mode d’échec revient assez souvent pour mériter d’être nommé : le mandat trop large accordé une fois, puis jamais réexaminé. L’agent reçoit à l’ouverture un périmètre pensé pour éviter d’avoir à y revenir, et ce périmètre devient la surface de risque permanente. La correction n’est pas technique : c’est une revue datée du mandat, au même titre qu’une habilitation d’accès se revoit, confiée à une personne chargée de le restreindre dès que l’usage réel s’avère plus étroit que le droit accordé.

Ce que cette approche ne peut pas faire

Le cadre de contrôle ne rend pas le modèle fiable. Il limite les conséquences de son manque de fiabilité. Il ne règle pas non plus la répartition des responsabilités dans la chaîne : si l’agent, la plateforme et le service relèvent de trois entreprises, l’attribution est une question contractuelle que la technique ne tranche pas. Commencez par des usages dont l’erreur est réversible, et n’étendez que lorsque les preuves le permettent.

Si vous envisagez un agent qui agit dans un service régulé, commencez par l’évaluation du cas d’usage et du cadre de contrôle.

Cet article est une adaptation de l’original anglais. En cas de divergence, la version anglaise fait foi.