Quelque part dans votre stack, un agent a déjà produit le chiffre qui se retrouvera un jour devant un auditeur. Il a calculé la valeur — ou l'a générée ; vous ne savez peut-être pas laquelle — quelqu'un l'a collée dans une présentation, et la présentation est partie. Des mois plus tard arrive la question que tout système d'IA en production finit par recevoir : d'où vient ce chiffre, et l'obtiendrait-on à nouveau aujourd'hui ?
La plupart des équipes répondent avec une transcription. Dans une enquête du premier trimestre 2026 portant sur 420 organisations exploitant des agents IA en production, seules 17 % pouvaient reconstituer après coup la séquence complète d'appels d'outils, d'entrées et de sorties associée à une tâche précise (AgentNode, 2026). Les 83 % restants disposaient de journaux partiels, d'aucun journal, ou de journaux capturant le raisonnement du modèle mais pas ce qu'il avait réellement invoqué. Une transcription et une impression.
La trace devient une obligation légale
Pendant un temps, c'était une honte d'ingénierie. C'est sur le point de devenir une honte juridique.
Le règlement européen sur l'IA exige que les systèmes d'IA à haut risque permettent techniquement — par conception, non par ajout tardif — « l'enregistrement automatique des événements (journaux) pendant toute la durée de vie du système » (Commission européenne, 2024). La tenue manuelle de registres ne satisfait pas l'article 12. Les journaux doivent être suffisamment précis pour identifier les situations susceptibles de présenter un risque ou une modification substantielle, pour soutenir la surveillance post-commercialisation, et pour suivre le fonctionnement réel du système. Pour l'identification biométrique à distance, l'article énonce explicitement le minimum : chaque période d'utilisation, la base de données de référence consultée, les données d'entrée ayant conduit à une correspondance, les personnes physiques ayant vérifié le résultat. Ce n'est pas « conserver quelques journaux ». C'est reconstituer la décision.
Les échéances sont proches. Le règlement est entré en vigueur le 1er août 2024 ; les interdictions s'appliquent depuis février 2025, les obligations relatives aux modèles à usage général depuis août 2025 — et les obligations pour les systèmes à haut risque, dont l'article 12, s'appliquent à partir du 2 août 2026 (Future of Life Institute, 2026). Huit jours après la date de cet article. Les systèmes à haut risque intégrés dans des produits réglementés (annexe I) suivront en août 2027.
La conservation a également un plancher. Les fournisseurs doivent conserver les journaux générés automatiquement pendant au moins six mois, et l'article 26(6) impose une obligation symétrique aux déployeurs — plus longue lorsque d'autres textes comme le RGPD l'exigent, et dans tous les cas adaptée à la finalité prévue du système, pas seulement au minimum (artificialintelligenceact.eu, 2024).
Rien de tout cela n'arrive dans le vide. L'article 30 du RGPD exige des registres écrits des traitements — finalités, catégories de données, destinataires, délais d'effacement, mesures de sécurité — depuis 2018, communicables à l'autorité de contrôle sur demande (gdpr-info.eu, 2016). Le CC7.2 de SOC 2 exige la surveillance des composants du système pour détecter les anomalies et l'analyse des constats ; le CC7.3 exige l'évaluation de la compromission éventuelle des objectifs par un événement (AICPA, 2022). Dans un audit de type II, ces critères sont vérifiés sur la base de preuves issues des journaux couvrant toute la période d'examen — généralement douze mois (AgentNode, 2026) — et non d'une capture d'écran prise le jour de la visite de l'auditeur.
Pourquoi « journaliser davantage » ne suffit pas
Le réflexe est la verbosité : activer le traçage, tout stocker, acheter un tableau de bord. Trois problèmes subsistent.
Les transcriptions enregistrent ce qui a été dit, pas ce qui a été exécuté. Un journal de conversation, c'est le modèle qui narre son propre comportement. Parmi les 83 % cités plus haut, une catégorie correspond exactement à cela : le raisonnement est capturé, les invocations d'outils ne le sont pas. Lorsque la narration et l'exécution divergent, la transcription garde un visage impassible — calculé et généré se lisent de façon identique sur la page. Ce ne sont pourtant pas la même chose.
Un journal qu'on ne peut pas ré-exécuter est un témoignage, pas une preuve. Même les équipes qui capturent chaque appel d'outil ne peuvent généralement pas en relancer un à l'identique pour comparer, car rien n'a figé l'environnement dans lequel il a tourné. Le SQL a été généré ce jour-là, contre une base de données qui a depuis évolué ; l'arithmétique a été échantillonnée depuis un modèle qui n'a jamais été stable. Conserver cela six mois — ou douze — revient à stocker des affirmations plus longtemps, pas à les rendre vérifiables. La formulation de l'article 12 est précise : le système doit techniquement permettre l'enregistrement. Une reproductibilité non conçue dès le départ ne peut pas être ajoutée après coup par une bibliothèque de journalisation.
Les métadonnées ne sont pas la correction. Le registre d'audit minimal viable — six champs essentiels, dont l'identifiant de trace, l'horodatage et l'identité de l'agent (AgentNode, 2026) — établit qui et quand. Il ne dit rien sur la justesse du chiffre, ni sur le fait qu'il serait identique aujourd'hui. Les recherches sur l'observabilité des agents LLM aboutissent au même constat : la traçabilité doit couvrir les artefacts de l'ensemble du cycle de vie de l'agent, pas seulement les messages (CSIRO Data61, 2024).
L'échec est structurel. L'exécution en forme libre — un modèle émettant des chaînes qu'autre chose exécute — ne produit rien d'assez stable pour être enregistré, quelle que soit la quantité consignée.
La provenance comme propriété du résultat
La réponse de SQAI est de faire de la trace une propriété de l'exécution plutôt qu'une fonctionnalité de journalisation. Chaque résultat exécuté porte quatre hachages, chacun répondant à une question d'audit distincte :
contract_hash— ce qui pouvait s'exécuter : le contrat de capacité exact en vigueur (sha256:79f1c5a6c716…).plan_hash— ce à quoi la requête a été résolue : le plan validé, avec sa résolution enregistrée (decision_path: "exact_spec").invocation_hash— ce qui a tourné, sur quoi : la capacité plus les entrées canonicalisées, incluant uninput_hashdes données telles qu'elles étaient.computation_hash— ce qui en est sorti : lié à l'invocation et à la valeur ensemble.
Les constructions sont séparées par domaine, de sorte qu'aucun artefact ne peut en usurper un autre :
invocation_hash = sha256("sqai:invocation:v1\0" + canonicalJson(identity))
computation_hash = sha256("sqai:computation:v1\0" + invocation_hash + canonicalJson(value))
Aux hachages s'ajoute l'enveloppe de déterminisme — l'environnement d'exécution enregistré : runtime_bundle_version 0.1.0 et son sha256, plateforme et architecture, precision_mode: float64, thread_count: 1, et la graine lorsqu'elle est requise. Les dix capacités de simulation qui en ont besoin refusent de s'exécuter sans elle — seed_required, pas une réponse silencieusement différente. Tout ce qui pourrait modifier le chiffre est soit figé, soit consigné.
Voici ce que cela apporte, concrètement. En mars, un agent calcule une valeur actuelle nette :
finance.npv(0.1, [-1000, 300, 420, 560, 680])
→ 505.020148896933
computation_hash b74f67d0d7a594aa…
En juillet, l'auditeur pose la question. Vous relancez l'invocation — même spec typée, même runtime figé — et comparez les hachages : b74f67d0d7a594aa… à nouveau, octet pour octet. Peu importe que la relecture tourne en TypeScript ou en Python. canonicalJson et canonical_json constituent un contrat de sérialisation multilangage — clés triées, -0 normalisé en 0, échappement unicode fixe — de sorte que la même valeur produit les mêmes octets et donc le même hachage dans les deux langages. La page sur le déterminisme présente deux de ces enveloppes, séparées de plusieurs mois, côte à côte.
Et lorsque la relecture ne correspond pas, c'est un signal. Une source modifiée échoue bruyamment avec schema_revision_mismatch — le moteur refuse de calculer silencieusement un chiffre différent sur des données différentes et de vous laisser l'attribuer au passé. L'écart nomme ce qui a changé.
Rapportez cela aux obligations. Enregistrement automatique sur toute la durée de vie du système : chaque résultat exécuté s'enregistre lui-même, par construction — il n'existe pas de chemin non enregistré, car la surface d'exécution est constituée de 4 574 capacités en lecture seule avec des entrées typées, et non de chaînes en forme libre. Six ou douze mois de conservation : stockez les enveloppes de résultats ; la conservation devient une décision de stockage plutôt qu'un travail d'archéologie. Des preuves couvrant une période d'examen SOC 2 : les artefacts sont les preuves — la réponse à l'auditeur est une relecture, pas une enquête. Le même pipeline produit la trace pour chaque capacité, et la piste d'audit persistante est incluse dans le niveau Pro de SQAI.
Huit jours, puis chaque audit qui suivra
La date d'août lie formellement les systèmes à haut risque dans l'UE. Mais des échéances comme celle-ci fixent le modèle pour tous les examens qui suivront — l'auditeur SOC 2, le questionnaire d'appel d'offres, votre propre directeur financier en mars qui interroge un chiffre de janvier. Les agents vont devoir justifier leurs réponses comme le font les employés : avec des traces. La plupart des stacks ne peuvent pas les produire, parce que le SQL généré et l'arithmétique échantillonnée ne laissent rien d'assez stable pour être enregistré — un problème qui commence bien avant l'audit.
Une réponse que l'on peut rejouer est une réponse que l'on peut défendre. Tout le reste est une capture d'écran.