Not because the answer is secret, and not because anyone destroyed anything. Because the records that survive were never meant to answer that question, and nobody can say how much weight any of them carries.
Most writing about AI governance assumes you planned for it. It tells you to install a gate, adopt a protocol, emit structured decision records, sign every action at the moment it happens. That advice is fine, and it is useless to almost everyone, because almost nobody did it.
The systems people actually have to answer for are the ones already running. They were built to work, not to be examined. Nobody wired them for evidence, because at the time nobody was asking. The question arrives later — from a regulator, an auditor, a customer, a lawyer, or an internal committee — and by then the moment has passed.
So this page answers the harder version: what can you establish about an AI system's behaviour when nothing was set up to record it, and how far can that account be trusted? The work goes by several names depending on who needs it — AI incident investigation, AI decision reconstruction, AI audit evidence, or simply being able to explain AI decisions long after deployment. They are the same problem seen from different desks, and they all reduce to one question: can you audit an AI system that was never instrumented for it?
Why the usual answers don't hold
- "We have logs." You have several partial records that disagree. Application logs, a tracing tool, CI history, ticket comments, cloud audit trails — each designed for a different purpose, none designed to answer who decided this, on what basis, under whose authority. Assembling them is not the problem. Establishing what the assembly is worth is the problem.
- "We have documentation." Documentation says what the system was supposed to do. That is a claim about the world, not an observation of it. The interesting cases are precisely the ones where documentation and runtime disagree, and a document cannot adjudicate that.
- "We'll ask the team." Recollection is evidence, but it is the weakest kind and it degrades. In a system running eighteen months, the person who could explain the decision is frequently gone — and their absence is often what triggered the question.
- "We have an audit trail." An audit trail records that events occurred, in an order. It rarely records who held the authority to cause them, what the decision rested on, or whether anything outside the system corroborates the entry. A trail is a sequence. Evidence is a sequence in which every element can be weighed.
- "We'll take screenshots." A screenshot shows that a screen looked a certain way when someone photographed it. It says nothing about when the event occurred, who caused it, or whether the record has changed since.
None of these are useless. They are simply ungraded. The problem is not that you have no material — it is that you have no way to say how much weight any part of it can carry.
What reconstruction actually means
Reconstruction is not log aggregation with a nicer interface. It is building an account of what happened that a third party can re-verify and challenge without taking your word for anything. Three things have to be true for that.
Every fact carries its provenance. Not just "confidence was 0.61", but where that came from, who or what recorded it, when, and whether anything outside the deciding system corroborates it. A fact stated by management and a fact independently attested by a system nobody in the chain controls are both facts, and they are not worth the same. An account that flattens them into one list has destroyed the only information that mattered.
Declared and observed are kept apart. The policy said human review was required. The runtime shows none occurred. Both statements belong in the record, and the value lies exactly in holding them side by side rather than resolving them. A system that silently prefers one over the other is deciding for you.
What was never recorded is stated as such. This is the part most tools get wrong, and the part that decides whether the account survives scrutiny. If the evidence for a control does not exist, the honest output is not assessable — not "compliant", not "at risk", not a score with a caveat. Naming the gaps is what makes the non-gaps credible.
An auditor who finds one inferred conclusion in your file stops trusting the rest of it — and is right to.
What you can establish, and what you can't
Being specific about this matters more than any capability claim.
Usually recoverable: the sequence of events and their recorded times; which model, policy version and configuration were in effect; what the system declared about itself versus what it did; contradictions between a stated limit and a recorded value; who or what touched the record; and which downstream effects followed.
Usually not recoverable: whether a human who clicked "approve" actually read anything; the reasoning inside a model's forward pass; anything that happened in a system that wrote no durable record; and the state of an external source that has since changed or disappeared. A citation is a pointer, not custody — if the page moved, the citation proves nothing.
Sometimes recoverable, and this is where the work is: whether a control operated rather than merely existed. A control that is documented, configured and never invoked leaves a very particular signature, and finding it is often the single most valuable output.
If someone tells you all of this is recoverable, they are selling you the part they can do and staying quiet about the rest.
When you don't need any of this
You don't need reconstruction if your AI systems don't make or materially shape decisions affecting someone outside your team. An internal drafting assistant is not an accountability problem.
You don't need it if you already emit signed, externally anchored decision records at execution time and have done so from the beginning. That is contemporaneous evidence, and it is strictly stronger than anything reconstructed after the fact. Reconstruction is a second-best that exists because the first-best usually wasn't available.
And you don't need it if nobody will ever ask. That is a real position — worth holding deliberately rather than by default, because the cost of finding out you were wrong is paid at the worst possible moment.
A worked example you can check yourself
Abstract claims about evidence deserve to be held to their own standard, so here is a reconstruction you can verify without trusting us.
We took a public record that was never produced for governance purposes: a run of the open-source coding agent OpenHands against a real GitHub issue from the SWE-bench dataset (creachadair/jrpc2 #81). An agent modified a real codebase. Nothing in that run was instrumented for audit. It is exactly the situation described at the top of this page.
From it we produced an evidence package, generated 14 July 2026. The package publishes a manifest listing the SHA-256 of every artifact it contains — including the tiers whose contents are not public. The hash is published, the content is not. That is a commitment, not a disclosure: it lets you prove later that a private artifact is the one that existed then, without publishing it now.
The ingest is anchored to an RFC 3161 timestamp from an external timestamping authority. You can verify that anchor yourself, taking our word for nothing:
openssl ts -verify -data <file> -in <token>.tsr -CAfile <TSA chain>
Most importantly, read the note the manifest carries about itself:
"The manifest cannot contain its own hash and is itself unsigned (authored, not counter-signed). It claims package integrity from generation time only: no immutability, no external time-stamp, no counter-signature."
That paragraph is the point of this entire page. An evidence artifact that does not state its own limits is asking to be believed. One that states them can be checked. We would rather publish the second kind and have you find the boundary yourself than publish the first kind and have an auditor find it for you.
If you're deploying something right now
Everything above is recovery work. It exists because the recording wasn't done. If you are standing at the other end — installing a system today, before anyone has asked you anything — you can make the later question cheap instead of expensive, and it costs very little at this stage.
Record the decision, not just the outcome: which model and version, which policy version, which configuration, and the inputs the decision rested on. Timestamp from a source the deciding system does not control. Keep the record append-only, so the past is a prefix rather than something that can be quietly revised. And get at least one independent corroboration into the chain — an approval, a check, or an attestation from a system nobody in the decision path owns. One independent fact changes the character of an entire file.
What you can demonstrate in two years is decided today, by what gets written down. Not by what gets documented.
See a real one, then ask for yours
Claims about evidence are easier to judge against an artifact than a description. The evidence package for the OpenHands run described above is published in full — the dossier, the SHA-256 manifest of every artifact it contains, and the RFC 3161 timestamp token. Verify the anchor yourself with openssl, taking our word for nothing.
If you want one for a system of your own, we run it with you, where your data already is — on your infrastructure or in your VPC. In air-gapped mode the language model runs inside the same container over a local socket, so nothing leaves your environment: that is not a privacy policy, it is an architectural property you can verify with tcpdump. You get back an evidence file — what happened, each fact with its provenance, the contradictions between declared and recorded, and an explicit list of what cannot be established. If your records cannot answer the question, that is also a result, and better learned now than in front of a regulator.
See the evidence package →Ask for a run on your system →
Also read: What is AI evidence reconstruction? · Why a perfect log can document an unauthorized decision · How do you prove a control actually ran? · How to collect audit evidence for AI agents.
Non parce que la réponse serait secrète, ni parce que quelqu'un aurait détruit quoi que ce soit. Mais parce que les traces qui subsistent n'ont jamais été faites pour répondre à cette question, et que personne ne peut dire quel poids chacune peut porter.
La plupart des textes sur la gouvernance IA supposent que vous l'aviez anticipée. Ils vous disent d'installer une barrière, d'adopter un protocole, d'émettre des enregistrements de décision structurés, de signer chaque action au moment où elle se produit. Ce conseil est bon, et il est inutile à presque tout le monde, parce que presque personne ne l'a fait.
Les systèmes dont il faut réellement répondre sont ceux qui tournent déjà. Ils ont été construits pour fonctionner, pas pour être examinés. Personne ne les a câblés pour la preuve, parce qu'à l'époque personne ne demandait rien. La question arrive plus tard — d'un régulateur, d'un auditeur, d'un client, d'un avocat ou d'un comité interne — et le moment est passé.
Cette page traite donc la version difficile : que peut-on établir du comportement d'un système IA quand rien n'était prévu pour l'enregistrer, et jusqu'où peut-on se fier à ce récit ? Ce travail porte plusieurs noms selon qui en a besoin — enquête sur incident IA, reconstitution de décision IA, preuve d'audit IA, ou simplement la capacité d'expliquer une décision longtemps après le déploiement. C'est le même problème vu depuis des bureaux différents, et il se ramène à une seule question : peut-on auditer un système IA qui n'a jamais été instrumenté pour ça ?
Pourquoi les réponses habituelles ne tiennent pas
- « On a des logs. » Vous avez plusieurs enregistrements partiels qui se contredisent. Logs applicatifs, outil de tracing, historique CI, commentaires de tickets, journaux d'audit cloud — chacun conçu pour un autre usage, aucun pour répondre à : qui a décidé, sur quelle base, sous quelle autorité. Les assembler n'est pas le problème. Établir ce que vaut l'assemblage, si.
- « On a de la documentation. » La documentation dit ce que le système était censé faire. C'est une affirmation sur le monde, pas une observation. Les cas intéressants sont précisément ceux où la documentation et le runtime divergent, et un document ne peut pas trancher cela.
- « On demandera à l'équipe. » Le souvenir est une preuve, mais la plus faible, et elle se dégrade. Sur un système en production depuis dix-huit mois, la personne qui pourrait expliquer la décision est souvent partie — et son départ est souvent ce qui a déclenché la question.
- « On a une piste d'audit. » Une piste d'audit enregistre que des événements ont eu lieu, dans un ordre. Elle enregistre rarement qui détenait l'autorité de les provoquer, sur quoi la décision reposait, ni si quoi que ce soit d'extérieur corrobore l'entrée. Une piste est une séquence. Une preuve est une séquence dont chaque élément peut être pesé.
- « On fera des captures d'écran. » Une capture montre qu'un écran avait cette apparence au moment où on l'a photographié. Elle ne dit rien du moment où l'événement s'est produit, de qui l'a causé, ni de ce que l'enregistrement est devenu depuis.
Rien de tout cela n'est inutile. C'est simplement non gradué. Le problème n'est pas que vous n'avez pas de matière — c'est que vous n'avez aucun moyen de dire quel poids chaque partie peut porter.
Ce que « reconstituer » veut vraiment dire
La reconstitution n'est pas de l'agrégation de logs avec une plus belle interface. C'est bâtir un récit de ce qui s'est passé qu'un tiers peut re-vérifier et contester sans vous croire sur parole. Trois conditions pour cela.
Chaque fait porte sa provenance. Pas seulement « la confiance valait 0,61 », mais d'où cela vient, qui ou quoi l'a enregistré, quand, et si quelque chose d'extérieur au système décideur le corrobore. Un fait affirmé par la direction et un fait attesté indépendamment par un système que personne dans la chaîne ne contrôle sont deux faits, et ils ne valent pas la même chose. Un récit qui les aplatit dans une seule liste a détruit la seule information qui comptait.
Le déclaré et l'observé restent séparés. La politique exigeait une revue humaine. Le runtime montre qu'il n'y en a pas eu. Les deux appartiennent au dossier, et la valeur tient précisément à les tenir côte à côte plutôt qu'à les résoudre. Un système qui préfère silencieusement l'un à l'autre décide à votre place.
Ce qui n'a jamais été enregistré est déclaré comme tel. C'est ce que la plupart des outils ratent, et ce qui décide si le récit survit à l'examen. Si la preuve d'un contrôle n'existe pas, la sortie honnête est non évaluable — pas « conforme », pas « à risque », pas un score assorti d'une note de bas de page. Nommer les trous, c'est ce qui rend crédible tout le reste.
Un auditeur qui trouve une seule conclusion inférée dans votre dossier cesse de faire confiance au reste — et il a raison.
Ce qu'on peut établir, et ce qu'on ne peut pas
Être précis là-dessus vaut mieux que n'importe quelle promesse de capacité.
Généralement récupérable : la séquence des événements et leurs horodatages ; quel modèle, quelle version de politique et quelle configuration étaient en vigueur ; ce que le système déclarait de lui-même face à ce qu'il a fait ; les contradictions entre une limite annoncée et une valeur enregistrée ; qui ou quoi a touché l'enregistrement ; et quels effets ont suivi.
Généralement non récupérable : si l'humain qui a cliqué « approuver » a réellement lu quelque chose ; le raisonnement interne d'un modèle ; tout ce qui s'est produit dans un système n'ayant écrit aucune trace durable ; et l'état d'une source externe modifiée ou disparue depuis. Une citation est un pointeur, pas une garde : si la page a bougé, la citation ne prouve rien.
Parfois récupérable, et c'est là qu'est le travail : savoir si un contrôle a opéré plutôt que simplement existé. Un contrôle documenté, configuré et jamais déclenché laisse une signature très particulière, et la trouver est souvent la sortie la plus précieuse.
Si quelqu'un vous affirme que tout cela est récupérable, il vous vend la partie qu'il sait faire et se tait sur le reste.
Quand vous n'avez besoin de rien de tout ça
Vous n'avez pas besoin de reconstitution si vos systèmes IA ne prennent ni n'influencent matériellement des décisions affectant quelqu'un hors de votre équipe. Un assistant de rédaction interne n'est pas un problème de responsabilité.
Vous n'en avez pas besoin si vous émettez déjà, depuis le début, des enregistrements de décision signés et ancrés à l'extérieur au moment de l'exécution. C'est de la preuve contemporaine, et elle est strictement supérieure à tout ce qu'on peut reconstituer après coup. La reconstitution est un second choix, qui existe parce que le premier n'était presque jamais disponible.
Et vous n'en avez pas besoin si personne ne demandera jamais rien. C'est une position légitime — à tenir délibérément plutôt que par défaut, car le prix de s'être trompé se paie au pire moment.
Un exemple travaillé, que vous pouvez vérifier vous-même
Des affirmations abstraites sur la preuve méritent d'être tenues à leur propre standard. Voici donc une reconstitution vérifiable sans nous faire confiance.
Nous avons pris un enregistrement public qui n'a jamais été produit à des fins de gouvernance : une exécution de l'agent de code open-source OpenHands sur une véritable issue GitHub du jeu de données SWE-bench (creachadair/jrpc2 #81). Un agent a modifié une vraie base de code. Rien dans cette exécution n'était instrumenté pour l'audit. C'est exactement la situation décrite en haut de cette page.
Nous en avons tiré un paquet de preuve, généré le 14 juillet 2026. Le paquet publie un manifeste listant le SHA-256 de chaque artefact qu'il contient — y compris les niveaux dont le contenu n'est pas public. L'empreinte est publiée, le contenu ne l'est pas. C'est un engagement, pas une divulgation : cela permet de prouver plus tard qu'un artefact privé est bien celui qui existait alors, sans le publier aujourd'hui.
L'ingestion est ancrée à un horodatage RFC 3161 délivré par une autorité d'horodatage externe. Vous pouvez vérifier cet ancrage vous-même, sans nous croire sur parole :
openssl ts -verify -data <fichier> -in <token>.tsr -CAfile <chaîne TSA>
Mais surtout, lisez la note que le manifeste porte sur lui-même :
« Le manifeste ne peut pas contenir sa propre empreinte et n'est lui-même pas signé (rédigé, non contresigné). Il n'affirme l'intégrité du paquet qu'à partir de l'instant de génération : aucune immuabilité, aucun horodatage externe, aucune contre-signature. »
Ce paragraphe est tout le propos de cette page. Un artefact de preuve qui n'énonce pas ses propres limites demande à être cru. Celui qui les énonce peut être vérifié. Nous préférons publier le second et vous laisser trouver la frontière vous-même, plutôt que publier le premier et laisser un auditeur la trouver à votre place.
Si vous êtes en train de déployer quelque chose
Tout ce qui précède est un travail de récupération. Il existe parce que l'enregistrement n'a pas été fait. Si vous êtes à l'autre bout — en train d'installer un système aujourd'hui, avant que quiconque ne vous ait rien demandé — vous pouvez rendre la question future bon marché plutôt que coûteuse, et cela coûte très peu à ce stade.
Enregistrez la décision, pas seulement le résultat : quel modèle et quelle version, quelle version de politique, quelle configuration, et les entrées sur lesquelles la décision reposait. Horodatez depuis une source que le système décideur ne contrôle pas. Gardez l'enregistrement en ajout seul, pour que le passé soit un préfixe et non quelque chose qu'on révise discrètement. Et faites entrer au moins une corroboration indépendante dans la chaîne — une approbation, un contrôle, une attestation venue d'un système que personne dans le chemin de décision n'administre. Un seul fait indépendant change la nature d'un dossier entier.
Ce que vous pourrez démontrer dans deux ans se décide aujourd'hui, par ce qui est consigné. Pas par ce qui est documenté.
Voyez-en un vrai, puis demandez le vôtre
Les affirmations sur la preuve se jugent mieux face à un artefact que face à une description. Le paquet de preuve de l'exécution OpenHands décrite plus haut est publié en entier — le dossier, le manifeste SHA-256 de chaque artefact qu'il contient, et le jeton d'horodatage RFC 3161. Vérifiez l'ancrage vous-même au openssl, sans nous croire sur parole.
Si vous en voulez un pour un système à vous, nous le faisons tourner avec vous, là où vos données se trouvent déjà — sur votre infrastructure ou dans votre VPC. En mode air-gap, le modèle tourne dans le même container via un socket local : rien ne sort de votre environnement. Ce n'est pas une politique de confidentialité, c'est une propriété d'architecture que vous pouvez vérifier au tcpdump. Vous récupérez un dossier de preuve : ce qui s'est passé, chaque fait avec sa provenance, les contradictions entre déclaré et enregistré, et la liste explicite de ce qui ne peut pas être établi. Si vos enregistrements ne peuvent pas répondre, c'est aussi un résultat — et il vaut mieux l'apprendre maintenant que devant un régulateur.
Voir le paquet de preuve →Demander un passage sur votre système →
À lire aussi : Qu'est-ce que la reconstitution de preuve IA ? · Pourquoi un journal parfait peut documenter une décision non autorisée · Comment prouver qu'un contrôle a réellement tourné ? · Collecter la preuve d'audit pour les agents IA.