L'observabilité LLM et la piste d'audit d'un agent IA peuvent partager un identifiant de trace et répondre pourtant à des questions différentes. Une trace d'observabilité enregistre la manière dont un appel de modèle ou une étape d'agent s'est déroulé : l'opération, le modèle, le nombre de tokens, la latence, les erreurs et, si la capture du contenu est activée, les messages. Une piste de niveau audit enregistre pourquoi une action a été autorisée, qui avait autorité sur elle, quelle version de politique l'a décidée, ce que l'outil a modifié et comment chacun pourra vérifier l'enregistrement plus tard. Pour un système à haut risque au sens de l'AI Act, la piste d'audit porte la traçabilité exigée par l'article 12, et la trace aide les ingénieurs à exploiter le système.
Ce guide compare les deux champ par champ, enregistre une action synthétique des deux manières, expose ce que l'AI Act exige des journaux et liste ce qu'il faut ajouter à une pile d'observabilité. Le cadre d'audit des agents IA en entreprise situe l'enregistrement dans la méthode d'audit complète, et sa feuille de travail d'audit complétée teste une action de l'autorisation jusqu'au résultat.
Ce qu'enregistre l'observabilité LLM
De nombreux outils d'observabilité LLM émettent ou ingèrent des données OpenTelemetry. Les conventions sémantiques OpenTelemetry pour l'IA générative définissent des spans pour l'inférence, les embeddings, la récupération, la mémoire et l'exécution d'outils, avec des attributs tels que gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model, gen_ai.usage.input_tokens et gen_ai.tool.name. Ces conventions ont le statut Development : les noms peuvent encore changer.
Dans ces conventions, le contenu est Opt-In. Les entrées et sorties du modèle (gen_ai.input.messages, gen_ai.output.messages), les arguments et résultats d'outils (gen_ai.tool.call.arguments, gen_ai.tool.call.result) et les documents récupérés (gen_ai.retrieval.documents) ne sont enregistrés que si quelqu'un les active. Une trace avec les paramètres par défaut peut montrer qu'un outil s'est exécuté et combien de temps il a pris, sans aucune trace de ce qu'on lui a demandé ni de ce qu'il a renvoyé.
Ces données servent bien l'ingénierie : trouver une étape en échec, une récupération lente ou un prompt coûteux, et comparer des versions de prompt. Cet usage explique aussi les choix de stockage habituels : échantillonnage pour maîtriser le volume, rétention fixée selon le coût de stockage, et magasins que les opérateurs peuvent modifier ou purger.
Nous avons rencontré l'écart entre les deux enregistrements dans notre propre produit. Dans une preuve de concept d'entrée en relation de commerçants en septembre, l'historique du dossier reliait chaque étape à Lineage Explorer, et les liens affichaient « Trace not found » pour une exécution en pause à une validation. L'exécution ne publiait ses spans de trace qu'à la fin, alors que le reçu de la porte pour la décision en attente existait déjà. Nous avons modifié Lineage Explorer pour qu'il lise, depuis l'enregistrement d'exécution, les étapes déjà enregistrées lorsqu'aucune trace n'a été publiée, et qu'il indique que l'exécution n'est pas terminée.
Ce qu'ajoute une piste de niveau audit
Un auditeur, un régulateur ou une équipe juridique qui examine une action d'agent pose des questions auxquelles une trace n'a pas été conçue pour répondre. Le tableau associe chaque question à un champ d'observabilité typique et au champ qui y répond dans le schéma de journal d'audit des agents IA, indépendant de tout fournisseur.
| Question de l'auditeur | Champ d'observabilité typique | Champ de piste d'audit (audit event v1) | Lacune de la trace |
|---|---|---|---|
| Pour qui l'agent a-t-il agi, et qui répond du résultat ? | gen_ai.agent.name, gen_ai.conversation.id, nom du service | actors.requester, actors.delegated_user, actors.service_identity, actors.accountable_owner | La trace nomme le processus de l'agent, rarement la personne délégante ou le responsable |
| Quelle version s'est exécutée ? | gen_ai.request.model, gen_ai.response.model | components.agent.version, components.model.version, components.prompt_template.version, chacun avec configuration_digest | Un nom de modèle seul ne renvoie pas à une version approuvée de l'agent, du prompt et de l'orchestrateur |
| Quelle politique a décidé, et a-t-elle été vérifiée avant l'action ? | Aucun span GenAI pour les décisions de politique | policy.policy_id, policy.policy_version, policy.policy_digest, policy.inputs_digest, policy.decision, policy.matched_rule_ids, policy.evaluated_at | Les contrôles de politique apparaissent, au mieux, comme des spans personnalisés sans signification fixe |
| Une personne habilitée a-t-elle approuvé ? | Aucun span GenAI pour les approbations | approval.required_role, approval.reviewer, approval.decision, approval.decided_at, approval.presented_evidence_digest | La trace ne peut montrer ni ce que l'examinateur a vu ni s'il détenait le rôle |
| Qu'a modifié l'outil ? | gen_ai.tool.name, gen_ai.tool.call.id ; arguments et résultat si activés | tool_calls[].arguments_digest, result_digest, idempotency_key, downstream_effects[].before_state_digest, after_state_digest | Aucun lien entre l'appel et le changement d'état dans le système de référence |
| Chaque action figure-t-elle dans la population ? | Traces échantillonnées | sequence, lineage.ordered_event_ids, rapprochement avec le système d’origine | L'échantillonnage écarte des enregistrements par construction |
| L'enregistrement a-t-il changé depuis son écriture ? | Aucun | integrity.record_hash, integrity.previous_event_hash, integrity.signature | Les magasins de traces sont généralement modifiables et expirent selon un calendrier de stockage |
Une action synthétique, enregistrée des deux manières
L'agent de crédit d'une banque fictive enregistre une décision de crédit de 24 000 EUR. La trace d'observabilité de l'étape d'outil se présente ainsi. Les valeurs sont synthétiques.
{
"name": "execute_tool set_disposition",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"span_id": "00f067aa0ba902b7",
"start_time": "2026-07-21T09:14:31.944Z",
"end_time": "2026-07-21T09:14:32.433Z",
"attributes": {
"gen_ai.operation.name": "execute_tool",
"gen_ai.tool.name": "set_disposition",
"gen_ai.tool.call.id": "call_01JZ8V4R1E7P3M9C5Q2T6N8D0A",
"gen_ai.agent.name": "Credit review agent"
},
"status": "OK"
}L'événement d'audit de la même action
L'événement d'audit du même appel est l'enregistrement d'exécution complet synthétique et public. Il porte les mêmes trace_id et span_id, si bien que les deux enregistrements se rejoignent. Il ajoute ce qui manque au span : l'utilisateur délégant et le responsable, la politique credit-disposition-policy 4.2.1 qui renvoie require_approval au titre de la règle manual-review-above-20000, l'approbation du souscripteur senior à 09:14:31.902Z avant l'appel à 09:14:31.944Z, les empreintes des arguments et du résultat, les empreintes d'état avant et après dans le core banking, le résultat métier, et une empreinte d'enregistrement avec une signature Ed25519.
Un auditeur peut vérifier la signature, contrôler que l'approbation a précédé l'appel, rejouer la politique sur les entrées enregistrées et suivre la référence de l'effet jusque dans le core banking. Avec le span seul, l'auditeur peut confirmer qu'un outil nommé set_disposition a répondu sans erreur.
Ce que l'AI Act exige des journaux
L'article 12, paragraphe 1, du règlement sur l'IA impose que les systèmes d'IA à haut risque permettent techniquement l'enregistrement automatique des événements tout au long de leur durée de vie. L'article 12, paragraphe 2, rattache cette journalisation à l'identification des situations susceptibles de présenter un risque ou d'entraîner une modification substantielle, à la surveillance après commercialisation et à la surveillance du fonctionnement par le déployeur. L'article 12, paragraphe 3, fixe des champs minimaux pour les seuls systèmes d'identification biométrique à distance.
L'article 19, paragraphe 1, impose aux fournisseurs de conserver les journaux générés automatiquement sous leur contrôle pendant au moins six mois, sauf disposition contraire du droit de l'Union ou du droit national. L'article 26, paragraphe 6, fixe le même minimum pour les déployeurs. Les mesures correctives relèvent de l'article 20 ; le système de gestion de la qualité, y compris les procédures de tenue des registres, de l'article 17.
Pour la plupart des systèmes à haut risque, le règlement laisse au fournisseur le choix de la liste des champs. Pour un agent, la traçabilité d'une décision suppose généralement les champs d'acteur, de version, de politique, d'approbation, d'effet de l'outil et de résultat du tableau ci-dessus. Le règlement (UE) 2026/1744, publié le 24 juillet 2026, a reporté la date d'application au 2 décembre 2027 pour les systèmes à haut risque relevant de l'article 6, paragraphe 2, et de l'annexe III, et au 2 août 2028 pour ceux relevant de l'article 6, paragraphe 1, et de l'annexe I. Le guide sur la journalisation de l'article 12 détaille cette obligation.
Les quatre couches d'un dossier de preuves
Un dossier de preuves regroupe la piste d'audit d'une décision ou d'une période pour qu'un examinateur puisse la vérifier en dehors du système qui l'a produite. L'exemple Evidence Room montre un export.
- Enregistrement de la décision : identifiant, horodatage, type de décision, résultat et classification du risque. Tous les autres artefacts y renvoient.
- Contexte d'entrée : ce que l'agent a lu, avec références et versions des sources ; les versions du modèle, du prompt et de la politique en vigueur. Comment prouver ce qu'un agent IA a lu décrit l'enregistrement de lecture.
- Preuves de gouvernance : décisions de politique avec les règles déclenchées, Decision Requests avec examinateur et justification, escalades et dérogations.
- Intégrité : un manifeste des artefacts avec empreintes SHA-256, signatures, ancrages d'horodatage et chaîne de conservation, pour qu'un examinateur puisse vérifier le dossier hors ligne.
Modèles d’architecture pour des enregistrements de niveau audit
Ces modèles se placent sur le chemin de l'action. Ils exigent que l'agent appelle les outils via un point de contrôle capable d'évaluer la politique et d'enregistrer le résultat.
Un champ absent au moment où un enregistrement est scellé ne peut pas être ajouté ensuite. Début septembre 2026, une analyse du code de notre propre plateforme a montré que certains enregistrements de décision internes et certains reçus scellés ne nommaient pas l'agent qui agissait. Les reçus scellés ne peuvent pas être complétés après coup : chaque jour sans ce champ ajoutait des enregistrements qu'un auditeur ne pouvait pas rattacher à un agent. Nous avons ajouté l'identité de l'agent aux enregistrements de décision et aux reçus de porte scellés en deux jours. Arrêtez la liste des champs avant le premier enregistrement de production.
- Écrire au moment de la décision : enregistrez la décision de politique avant que l'action ne se poursuive et l'approbation avant l'appel d'outil. Un enregistrement reconstitué après coup à partir de journaux ne peut pas établir l'ordre de manière fiable.
- Stockage en ajout seul : stockez les événements là où les entrées existantes ne peuvent être ni modifiées ni supprimées, et chaînez chaque enregistrement au précédent par empreinte.
- Signer et sceller : signez chaque enregistrement, et scellez les exports avec un manifeste et une signature qu'un examinateur peut vérifier avec des clés publiées.
- Garder le contenu résoluble : une empreinte ne prouve une correspondance que si le contenu peut être produit plus tard. Conservez la version source ou une copie protégée pendant toute la durée de conservation.
- Enregistrer ce dont le rejeu a besoin : entrées de la décision, version de politique figée et sortie du modèle enregistrée. Le rejeu déterministe des décisions d'agents IA liste l'ensemble complet et ses limites.
- Relier à la télémétrie : portez
trace_idetspan_iddans l'événement d'audit pour que les ingénieurs et les auditeurs puissent passer d'un enregistrement à l'autre.
Construire la couche de preuves sur une pile d'observabilité
Les équipes qui disposent déjà du traçage peuvent ajouter la couche de preuves par phases.
- Phase 1, définir les questions : listez les types de décision exposés à un audit ou à un risque juridique et les questions qu'un auditeur posera pour chacun.
- Phase 2, placer les points de contrôle : faites passer les appels d'outils conséquents par un point de contrôle de politique qui enregistre les champs d'acteur, de version, de politique, d'approbation et d'effet.
- Phase 3, protéger l'intégrité : déplacez les événements d'audit vers un stockage en ajout seul avec empreintes, signatures et exports scellés.
- Phase 4, tester l'enregistrement : échantillonnez des actions, vérifiez les signatures, rapprochez la population et rejouez les décisions. La liste de contrôle d'audit des agents IA et la feuille de travail d'audit fournissent les tests.
Foire aux questions
Les outils d'observabilité LLM peuvent-ils servir de piste d'audit au titre de l'AI Act ?
Les traces d'observabilité en couvrent une partie. Dans les conventions OpenTelemetry GenAI, le contenu est Opt-In et il n'existe aucun span pour les décisions de politique ou les approbations. Une piste d'audit d'agent au titre de l'AI Act a aussi besoin de la personne délégante, de la version et du résultat de la politique, de l'approbation, de l'effet de l'outil sur le système de référence, de l'exhaustivité de la population et d'une preuve d'intégrité. Reliez la trace à un événement d'audit qui porte ces champs.
Comment créer des pistes d'audit pour les actions d'agents IA ?
Attribuez un identifiant d'exécution unique et enregistrez les identités de l'agent et des humains, les versions déployées, ce que l'agent a lu, les appels d'outils et leurs résultats, les décisions de politique, les approbations, les sorties, les effets de bord et les horodatages. Écrivez les enregistrements au moment de la décision dans un stockage en ajout seul et scellez les exports avec un manifeste et des signatures.
Comment auditer et rejouer les décisions d'agents IA ?
Sélectionnez une exécution dans une population rapprochée, vérifiez son intégrité, retrouvez la version de politique enregistrée et réexécutez la politique sur les entrées enregistrées, sans accès aux outils. Comparez le résultat et les règles déclenchées avec l'enregistrement. Testez séparément l'effet externe de l'outil dans le système aval, car une décision rejouée ne le prouve pas.
Qu'est-ce qu'un dossier de preuves ?
Un dossier de preuves regroupe l'enregistrement de la décision, le contexte d'entrée, les preuves de gouvernance et les éléments d'intégrité pour une décision ou une période, afin qu'un examinateur puisse le vérifier en dehors du système qui l'a produit.
Quels articles de l'AI Act portent sur les journaux ?
L'article 12 impose la journalisation automatique des événements pour les systèmes à haut risque. L'article 19, paragraphe 1, et l'article 26, paragraphe 6, imposent aux fournisseurs et aux déployeurs de conserver les journaux sous leur contrôle pendant au moins six mois, sauf disposition contraire d'un autre texte. L'article 17 couvre le système de gestion de la qualité, y compris la tenue des registres.
Qu'est-ce que le stockage en ajout seul (append-only) et pourquoi est-ce important ?
Le stockage en ajout seul accepte de nouveaux enregistrements et refuse la modification et la suppression des enregistrements existants. Avec le chaînage par empreinte et les signatures, il permet à un examinateur de détecter toute modification de la piste après son écriture.
Points clés à retenir
Gardez l'observabilité pour exploiter le système, et ajoutez un événement d'audit sur le chemin de l'action pour prouver comment une décision a été gouvernée. Reliez les deux par l'identifiant de trace. Pour chaque action conséquente, enregistrez ce que l'agent a lu, la version de politique, l'approbation, l'effet et une preuve d'intégrité. Utilisez la liste de contrôle d'audit des agents IA pour tester ces enregistrements, l'évaluation de préparation pour repérer les lacunes, et Execution Lineage pour voir comment KLA relie les enregistrements d'une exécution.