Un agent exécute une opération dans un outil métier. Deux semaines plus tard, personne ne retrouve la demande initiale, la permission utilisée ni la validation du responsable. Le journal contient beaucoup de texte, mais il ne permet pas de reconstituer la décision. Un registre de preuves sert précisément à éviter cette situation : relier une action observable à son contexte, à ses contrôles et à son propriétaire.
Cette méthode complète la gouvernance de l’IA. Elle ne suppose pas de conserver toutes les conversations ni de révéler le raisonnement interne d’un modèle. Elle organise les éléments nécessaires pour contrôler des opérations déterminées. Le périmètre doit rester proportionné aux risques, à la confidentialité des données et aux capacités réelles du système.
Qu’est-ce qu’un registre de preuves pour les agents IA ?
Un registre de preuves est un ensemble structuré de références permettant de vérifier ce qu’un agent a proposé, ce qui lui était autorisé et ce qui a effectivement été exécuté. Il distingue la demande, la configuration, les décisions de contrôle, les effets et les éventuels incidents. Le texte généré par l’agent n’est qu’un élément parmi ces observations.
Le NIST AI RMF articule la gestion des risques autour de quatre fonctions : gouverner, cartographier, mesurer et gérer. Ce cadre volontaire ne fournit pas un formulaire unique pour tous les agents. Le registre proposé ici est une méthode pratique pour relier ces activités aux opérations d’un système particulier, sans prétendre constituer une certification.
Il faut d’abord choisir l’unité suivie. Une demande peut produire plusieurs appels d’outils, plusieurs refus et une seule décision finale. Un identifiant de demande relie l’ensemble ; chaque opération conserve ensuite son identifiant propre. Une opération bloquée doit rester distinguable d’une opération exécutée avec succès. Sinon, les volumes affichés dans un tableau de bord peuvent masquer le véritable comportement du service.
La chaîne de références doit permettre de retrouver les contrôles réellement appliqués à l’action.
Quelles preuves faut-il conserver pour chaque opération ?
Il faut conserver les références qui soutiennent une vérification précise, avec un niveau de détail adapté au risque. Pour une action d’écriture, le dossier minimal peut réunir l’identifiant de la demande, la version du système, l’identité technique, le contrôle de permission, l’objet visé et le résultat de l’opération. Une validation humaine, lorsqu’elle est requise, doit être datée et reliée à la proposition qu’elle a effectivement examinée.
Le registre devrait distinguer cinq familles d’informations. Le contexte décrit la tâche et son propriétaire métier. La configuration identifie le modèle, les instructions, les outils et les paramètres pertinents. L’autorisation indique la règle évaluée et son résultat. L’exécution rapporte l’appel observé et son effet. La décision documente l’acceptation, le refus, la correction ou le retour à un état antérieur.
Les références documentaires méritent aussi une version. Un simple lien vers un fichier modifiable ne permet pas de vérifier ce qui était disponible à l’instant de la réponse. Conserver un identifiant de version, un passage ou une empreinte peut être utile selon l’infrastructure. Une empreinte signale une identité de contenu ; elle ne prouve pas, à elle seule, que le document était exact ou que sa consultation était autorisée.
La checklist d’auditabilité aide à transformer ces familles en questions de recette. Le registre ne remplace pas la vérification des droits à la source : il doit montrer qu’elle a eu lieu.
Comment relier les outils sans copier toutes les données ?
On peut relier les composants par des identifiants de corrélation et des références vers des traces protégées. La recommandation W3C Trace Context normalise notamment la propagation du contexte de trace entre services via des en-têtes HTTP. Elle facilite la corrélation technique ; elle ne définit pas les preuves métier attendues d’un agent et ne garantit pas la complétude des journaux.
L’architecture doit donc préciser quels événements sont nécessaires et lesquels restent facultatifs. Un service peut enregistrer toutes les opérations d’écriture sensibles tout en échantillonnant certaines informations de performance. Si la trace requise manque, la ligne de registre doit l’indiquer explicitement. L’absence de donnée ne doit jamais devenir un résultat de contrôle positif par défaut.
Évitez de placer des secrets ou des documents complets dans les identifiants, les URL et les métadonnées de trace. Des références opaques donnent accès aux pièces par un mécanisme d’autorisation séparé. Le propriétaire des journaux, leurs lecteurs et leurs durées de conservation doivent être définis pour ce traitement précis. La minimisation se décide à partir de l’objectif de contrôle, pas à partir de l’espace disponible dans l’outil.
Comment tester un registre avant la production ?
Il faut tester sa capacité à reconstruire des cas normaux, des refus et des incidents sans dépendre de la mémoire de l’équipe. Un exercice simple consiste à sélectionner une opération récente, puis à demander à une autre personne de retrouver la demande, le contrôle d’accès, l’effet et la décision. Chaque élément introuvable devient une correction de l’instrumentation ou du processus.
Ajoutez des cas où un document externe contient une instruction malveillante, où une permission a été retirée et où l’outil échoue après une proposition valide. OWASP décrit l’injection de prompt comme un risque pouvant provenir d’instructions directes ou de contenus externes traités par le modèle. Le registre doit conserver le résultat du contrôle et l’action observée, plutôt que seulement l’explication donnée par l’agent.
Dans un exemple fictif, un assistant propose une modification de commande fournisseur. Le contrôle bloque l’écriture car le montant dépasse le périmètre autorisé. Le test réussit si la modification n’a pas eu lieu et si le dossier relie le refus à la règle évaluée. Un message « opération sécurisée » sans observation de l’outil ne constitue pas cette preuve.
Qui doit exploiter ces preuves au quotidien ?
Un responsable métier doit pouvoir décider à partir des constats, avec l’appui des équipes techniques et de sécurité. La gouvernance échoue lorsque chaque équipe possède une partie des journaux mais que personne ne peut relier un incident à une décision d’usage. Nommez un propriétaire du registre et un propriétaire de chaque famille d’actions.
La revue périodique porte sur les actions critiques, les preuves manquantes, les refus inattendus et les corrections ouvertes. Elle doit aboutir à une décision : maintenir le périmètre, réduire les permissions, corriger une source, suspendre une fonction ou élargir le pilote après validation. La méthode Noolya permet d’articuler cette revue avec le cadrage métier et les tests de terrain.
Un registre utile reste consultable. Commencez par une action importante et quelques questions vérifiables, puis étendez le dispositif aux autres opérations. Accumuler des champs sans lecteur identifié augmente la charge de maintenance et dilue les signaux. Le critère d’utilité est la capacité à prendre une décision étayée après un événement, pas la quantité de texte stockée.
Questions fréquentes
Un registre prouve-t-il qu’une réponse est correcte ?
Non. Il permet de retrouver les éléments nécessaires au contrôle. La correction factuelle dépend encore de la qualité des sources, de leur pertinence et de la vérification du résultat.
Faut-il stocker le raisonnement interne du modèle ?
Non. La méthode repose sur des entrées autorisées, des versions, des contrôles et des effets observables. Une explication générée ne remplace pas une trace d’exécution.
Peut-on commencer sans plateforme spécialisée ?
Oui. Un registre structuré peut commencer dans un outil existant si les références, les accès et les responsabilités sont fiables. Il faut ensuite tester sa capacité à reconstruire les cas.
