Pour prouver ce qu'un agent d'IA a lu avant d'agir, enregistrez chaque lecture comme un événement distinct et rattachez chaque fait de la décision à l'un de ces événements. Un événement de lecture indique le système source, l'outil ou la récupération qui l'a produit, une empreinte de la requête et du résultat, la version de l'enregistrement source, l'heure et le périmètre de données. Une carte de provenance des champs précise ensuite, pour chaque valeur utilisée par l'agent, si elle provient d'un résultat d'outil, d'un document ou du modèle. Avec ces deux éléments, un auditeur peut prendre une décision et ramener chacune de ses entrées à un enregistrement source qui existait à ce moment-là.
Cet article couvre les quatre types de lecture d'un agent, une structure d'enregistrement pour chacun, un exemple KYC synthétique, le choix entre conserver le contenu et conserver une empreinte, et ce que KLA enregistre aujourd'hui. Le guide des pistes d'audit des agents d'IA couvre l'enregistrement d'exécution dans son ensemble. Le rejeu déterministe repose sur les mêmes enregistrements de lecture.
Pourquoi les auditeurs demandent d'où vient l'information
Un agent qui examine un dossier client, rédige une note de crédit ou clôture une alerte agit sur la base de ce qu'il a lu. Lorsque le résultat est contesté, les premières questions portent sur les entrées : quels enregistrements l'agent a vus, s'ils étaient à jour, s'il était autorisé à les lire, et quels faits de sa production il a inventés.
Le droit de la protection des données pose une variante de la même question. En vertu de l'article 15, paragraphe 1, point g), du RGPD, la personne concernée qui exerce son droit d'accès a droit, lorsque les données à caractère personnel ne sont pas collectées auprès d'elle, à « toute information disponible quant à leur source ». L'article 14, paragraphe 2, point f), impose au responsable du traitement d'indiquer à la personne concernée « la source d'où proviennent les données à caractère personnel ». Un agent qui puise des données client dans plusieurs systèmes rend ces réponses plus difficiles, sauf si chaque lecture est enregistrée.
L'AI Act mentionne les entrées dans les journaux pour une catégorie. Pour les systèmes d'identification biométrique à distance visés à l'annexe III, point 1 a), l'article 12, paragraphe 3, impose la journalisation de « la base de données de référence utilisée par le système pour vérifier les données d’entrée » et des « données d'entrée pour lesquelles la recherche a abouti à une correspondance ». Pour les autres systèmes d'IA à haut risque, l'article 12, paragraphes 1 et 2, impose une journalisation automatique qui favorise la traçabilité, l'identification des risques et la surveillance après commercialisation, et laisse au fournisseur le choix des champs. Les enregistrements de lecture sont l'un des moyens d'assurer cette traçabilité pour un agent.
Ce qu'une trace par défaut montre des lectures
De nombreuses équipes partent de leurs données de traçage. Les conventions sémantiques OpenTelemetry pour l'IA générative, au statut Development, définissent un span de récupération avec gen_ai.data_source.id et gen_ai.retrieval.top_k, et un span d'exécution d'outil avec gen_ai.tool.name et gen_ai.tool.call.id.
Les attributs de contenu sont Opt-In : gen_ai.retrieval.query.text, gen_ai.retrieval.documents, gen_ai.tool.call.arguments, gen_ai.tool.call.result et l'entrée du modèle dans gen_ai.input.messages. Une trace aux réglages par défaut peut montrer qu'une récupération ou un appel d'outil a eu lieu et combien de temps il a duré, sans rien enregistrer de ce qui a été demandé ni de ce qui a été renvoyé. Lorsque la capture du contenu est activée, la trace conserve les valeurs brutes dans un stockage généralement dimensionné et conservé pour le débogage, sans version de la source ni protection de l'intégrité.
Le traçage reste utile pour l'enregistrement de lecture. Le trace_id et le span_id relient un événement de lecture au span qui l'a chronométré.
Quatre types de lecture et ce dont chacun a besoin
Les agents lisent de quatre façons. Chacune nécessite un enregistrement légèrement différent, et chacune présente une lacune typique qui rompt la piste d'audit.
| Type de lecture | Exemple | Enregistrement minimal | Lacune habituelle |
|---|---|---|---|
| Lecture dans un système structuré | Consultation d'un client dans le CRM, solde du core banking, requête SQL via un connecteur | ID et version de l'outil, empreinte des arguments, références des enregistrements, empreinte du résultat, version de l'enregistrement source ou date de référence | Seul le nom de l'outil est journalisé ; le résultat est supprimé après l'étape |
| Lecture de document | Scan de passeport, relevé bancaire, mandat signé | ID du document, checksum SHA-256, version de l’objet stocké, heure de réception, page et zone de chaque valeur citée | Le fichier est remplacé sur place sous le même nom, et le checksum ne permet plus de le retrouver |
| Récupération | Passages du manuel de politiques issus d'un index vectoriel | ID et version de construction de l'index, empreinte de la requête, ID des fragments renvoyés, scores et empreintes du contenu des fragments, top_k | L'index est reconstruit et les anciens ID de fragments n'existent plus |
| Modèle ou mémoire | Une valeur écrite par le modèle sans source citée ; un fait rappelé depuis la mémoire de l'agent | Un libellé de source explicite model ou memory ; pour la mémoire, l'ID de l'élément et sa date d'écriture | Les valeurs sans source sont stockées à côté des valeurs sourcées, sans rien pour les distinguer |
Un enregistrement de lecture et une carte de provenance des champs
L'enregistrement de lecture ci-dessous est synthétique et indépendant de tout fournisseur. Il décrit une consultation du CRM lors d'une revue KYC périodique. Les empreintes sont abrégées.
{
"read_id": "read_syn_0193_02",
"execution_id": "run_syn_0193",
"tool_call_id": "call_syn_0193_02",
"occurred_at": "2026-10-09T08:12:03.418Z",
"source": {
"system": "crm-eu",
"kind": "api",
"tool_id": "crm.customer.get",
"tool_version": "2026-09-30"
},
"request": {
"arguments_digest": "sha256:3b9e…41d0",
"record_refs": ["cust_syn_55120"]
},
"response": {
"result_digest": "sha256:c07a…9e12",
"source_record_version": "v41",
"as_of": "2026-10-09T08:12:03.390Z"
},
"boundary": {
"data_boundary_ref": "boundary_eu_kyc",
"purpose": "kyc-periodic-review"
},
"retention": {
"content_stored": "digest_only",
"content_location": "crm-eu record history"
}
}Rattacher chaque fait à sa source
Les enregistrements de lecture montrent ce que l'agent aurait pu utiliser. La carte de provenance des champs montre ce qu'il a réellement utilisé. Joignez-la à l'enregistrement de décision afin que chaque champ de sortie pointe vers une source.
"field_provenance": {
"residence_country": {
"source": "tool",
"tool_call_id": "call_syn_0193_02",
"path": "$.address.country"
},
"id_document_expiry": {
"source": "document",
"document_id": "doc_syn_771",
"checksum_sha256": "8f14…a3c2",
"page": 1
},
"source_of_funds_summary": {
"source": "model"
}
}- Source outil : la valeur est lue à un chemin d'un résultat d'outil enregistré. L'évaluateur recalcule l'empreinte du résultat et vérifie la valeur à ce chemin.
- Source document : la valeur cite un document que l'agent a reçu lors de cette étape, par son ID et son checksum, avec une page et, lorsqu'elle est disponible, une zone de la page.
- Source modèle : la valeur n'a pas de source externe. Étiquetez-la pour qu'un évaluateur la traite comme une affirmation propre à l'agent et la vérifie comme telle.
Exemple détaillé : une revue KYC périodique synthétique
Une banque européenne fictive exploite un agent de mise à jour KYC. L'agent lit le profil client, le dernier document d'identité et la synthèse des transactions, puis propose une notation de risque qu'un analyste KYC doit approuver. Tous les identifiants et toutes les valeurs ci-dessous sont inventés.
| Entrée de la décision | Valeur utilisée | Source | Preuve de provenance | Contrôle de l'auditeur et résultat |
|---|---|---|---|---|
| Pays de résidence | FR | Outil : crm.customer.get | call_syn_0193_02, empreinte du résultat, version d'enregistrement v41 | L'historique du CRM montre que v41 était à jour à 08:12:03Z ; la valeur correspond. Conforme |
| Date d'expiration du document d'identité | 2031-04-30 | Document : doc_syn_771 | Checksum, page 1, zone localisée par la couche texte | La version de l'objet stocké correspond au checksum ; la date imprimée correspond. Conforme |
| Dépôts en espèces, 90 derniers jours | 18 400 EUR | Outil : txn.summary.get | call_syn_0193_03, empreinte du résultat | Le grand livre du core banking, relancé sur la même période, donne 18 400 EUR. Conforme |
| Profession | Travailleur indépendant | Outil : crm.customer.get | call_syn_0193_02, version d'enregistrement v41 | Le CRM est passé à « Salarié » en v43 deux jours plus tard. L'agent a utilisé la valeur en vigueur à ce moment-là. Conforme, avec une note pour l'analyste |
| Synthèse de l'origine des fonds | Paragraphe narratif | Modèle | source: model | Aucune source. L'enregistrement d'approbation de l'analyste doit montrer que ce paragraphe a été examiné comme un texte rédigé par l'agent. Exception : l'écran d'approbation ne l'étiquetait pas |
Conserver le contenu ou conserver une empreinte
Une empreinte est petite, peut être stockée sans risque dans un enregistrement scellé et suffit à prouver une correspondance. Seule, elle ne prouve rien : l'auditeur a besoin des octets d'origine pour la recalculer. Décidez, source par source, où ces octets seront conservés pendant la durée de conservation.
- Empreinte et version de la source : à utiliser lorsque le système source conserve l'historique des enregistrements au moins aussi longtemps que la preuve doit pouvoir être vérifiée. Enregistrez la version ou la date de référence pour pouvoir retrouver la lecture plus tard.
- Empreinte et copie dans le stockage des preuves : à utiliser lorsque la source est modifiable, a une durée de conservation plus courte que la preuve ou se trouve chez un tiers.
- Capture au niveau du champ : ne stockez que les valeurs utilisées par la décision, avec leurs chemins. Les données personnelles présentes dans l'enregistrement de preuve se limitent ainsi à ce dont la décision a besoin.
- Masquage et accès : appliquez au contenu de lecture stocké la même classification et la même politique d'accès qu'à la source. Enregistrez le profil de masquage avec la lecture.
Ce que KLA enregistre aujourd'hui sur les lectures
KLA enregistre les lectures lorsqu'elles passent par un chemin gouverné. Les points ci-dessous décrivent le comportement actuel et ses limites.
Appels d'outils gouvernés. Lorsqu'un agent appelle un outil via le runtime KLA, les reçus signés de l'appel contiennent une empreinte SHA-256 des arguments de l'outil et du résultat libéré. Les reçus sont écrits dans le registre de preuves en ajout seul propre à chaque tenant et rassemblés dans le Sealed Evidence Bundle. Le registre conserve l'empreinte ; le contenu lu reste dans le système source et le stockage du runtime.
Provenance des champs d'un Process. Un Process peut déclarer une source pour chaque champ produit. Pour une source outil, KLA capture la valeur à un chemin du résultat d'outil libéré et écrit cette valeur. Pour une source document, l'agent cite un document de l'étape, et la porte de transition vérifie la citation par rapport aux documents que l'étape a effectivement reçus avec leur contenu. Une source déclarée sans preuve bloque la transition avec missing_field_provenance. La décision de la porte enregistre la carte sous forme de références uniquement : {source: "tool", toolKey, callId}, {source: "document", documentId, documentType, checksumSha256, page, region} ou {source: "model"}.
Document Intake. Chaque document source porte checksum_sha256, object_version_id et received_at. L'extraction enregistre par champ une empreinte du texte source, le modèle d'extraction et la version du contrat de champ, et les événements de réception sont en ajout seul. Lorsque le worker localise une valeur citée, l'enregistrement conserve la page, les coordonnées du cadre et la méthode (text_layer ou vision), jamais le texte.
Limites. KLA ne capture aujourd'hui ni les fragments de récupération vectorielle ni la fenêtre de contexte complète du modèle. Une récupération qu'un agent exécute dans son propre code, hors d'un appel d'outil gouverné, ne laisse aucun enregistrement de lecture KLA ; faites-la passer par un outil gouverné pour l'enregistrer. Les Data Boundaries sont enregistrées pour le run dans son ensemble, sans version de périmètre par lecture.
Ce que nous avons appris en construisant les champs sourcés par document
Nous avons construit les champs sourcés par document pour une preuve de concept d'entrée en relation avec des commerçants en septembre 2026. Un champ tel qu'un numéro d'immatriculation de société devait citer le document d'entrée en relation dont il provenait, et la porte du Process refusait la transition lorsque la citation manquait.
Notre revue de la première implémentation a montré que les citations étaient vérifiées par rapport à tous les documents du run. Un agent pouvait citer un document qui ne lui avait pas été présenté lors de cette étape, et le contrôle réussissait. Nous avons limité le contrôle aux documents que l'étape a effectivement reçus avec leur contenu. La même revue a montré que les valeurs capturées à partir de résultats d'outils étaient perdues lorsqu'un run se mettait en pause dans l'attente d'une réponse par courriel ; nous avons corrigé ce point pour que les captures survivent à l'attente.
Nous avons consigné une limite et l'avons conservée. Une citation prouve que l'étape a reçu le document cité. La présence de la valeur dans ce document est une autre question. Pour accélérer ce second contrôle, nous avons ajouté fin septembre des zones de citation : le worker localise la valeur citée sur la page et la page du dossier l'encadre pour l'évaluateur.
Localiser du texte avec un modèle a soulevé un problème propre. Un modèle à qui l'on demande si son propre cadre est correct a tendance à l'approuver. Nous utilisons un contrôle à l'aveugle : un second appel transcrit le cadre recadré sans voir le texte attendu, et le cadre n'est conservé que si la transcription correspond. Les zones sont une aide à la lecture construite à partir d'un contenu de page non fiable ; elles ne décident donc jamais d'une transition.
Procédure d'audit de la provenance des lectures
Appliquez ces étapes à un échantillon de décisions fondé sur le risque. Le dossier de travail d'audit des agents d'IA applique la même méthode à l'autorité, à l'approbation et au résultat.
- Lister les entrées : pour chaque décision échantillonnée, listez chaque fait utilisé par l'agent à partir de sa production et de l'enregistrement de décision.
- Retrouver la source : associez chaque fait à un événement de lecture, à un document ou à un libellé
model. Un fait sans entrée est une exception. - Recalculer les empreintes : récupérez le contenu source à la version enregistrée et recalculez l'empreinte du résultat ou le checksum.
- Vérifier la chronologie : confirmez que chaque lecture précède la décision et que la version de la source était à jour au moment de la lecture.
- Vérifier l'autorisation : comparez chaque source et chaque enregistrement avec le périmètre de données et la finalité en vigueur pour le run.
- Vérifier l'étiquetage : confirmez que les faits issus du modèle ont été présentés à l'évaluateur humain comme rédigés par l'agent.
Foire aux questions
Comment auditer l'origine des informations d'un agent d'IA sur un client ?
Prenez une décision, listez chaque fait client qu'elle a utilisé et ramenez chacun à une lecture enregistrée : l'appel d'outil ou le document, la version de l'enregistrement source et une empreinte du résultat. Recalculez l'empreinte à partir de la source à cette version. Tout fait sans enregistrement de lecture, ou étiqueté comme rédigé par le modèle, constitue soit une exception, soit une valeur que l'évaluateur doit vérifier comme une affirmation propre à l'agent.
Comment auditer le contenu qu'un agent d'IA a utilisé pour prendre une décision ?
Distinguez ce que l'agent a lu de ce qu'il a utilisé. Les événements de lecture montrent chaque récupération et chaque résultat d'outil ; une carte de provenance des champs, dans l'enregistrement de décision, relie chaque valeur de sortie à l'un d'eux. Échantillonnez des décisions, recalculez les empreintes et confirmez que le contenu se trouvait dans le périmètre de données approuvé.
Une trace de LLM montre-t-elle ce qu'un agent d'IA a lu ?
Seulement si la capture du contenu est activée. Dans les conventions GenAI d'OpenTelemetry, les documents récupérés, les arguments et résultats d'outils et les messages d'entrée du modèle sont des attributs Opt-In. Une trace par défaut montre qu'une lecture a eu lieu, sans rien enregistrer du contenu, de la version de sa source ni de son intégrité.
Un enregistrement d'audit doit-il stocker le contenu lu par un agent ou seulement une empreinte ?
Stockez une empreinte dans l'enregistrement scellé et conservez le contenu là où il peut être produit pendant toute la durée de conservation : dans le système source avec une référence de version, ou dans le stockage des preuves lorsque la source est modifiable. Une empreinte sans contenu récupérable ne peut pas être vérifiée.
Points clés à retenir
La provenance d'une décision d'agent tient en deux enregistrements : un événement par lecture, et une carte qui relie chaque fait de la décision à une lecture, à un document ou au modèle. Gardez le contenu récupérable aussi longtemps que l'enregistrement doit pouvoir être vérifié, et faites passer les récupérations par des appels gouvernés pour qu'elles soient enregistrées. Pour le format d'enregistrement, commencez par le schéma du journal d'audit des agents d'IA et l'enregistrement d'exécution des agents d'IA. Pour voir comment KLA relie les lectures aux décisions et aux effets, consultez Execution Lineage.