Observability tells you what your AI system is doing, for the people who operate it. Evidence establishes what it did, for someone who does not trust you. The first is present-tense and insider-facing. The second has to survive a hostile reader six months later.
This is the most common objection we hear, and it deserves a serious answer rather than a slogan: we already have Langfuse, Datadog and OpenTelemetry — what would we need beyond that?
Often, nothing. Sometimes, quite a lot. The difference is not the quality of your instrumentation. It is who the record has to convince.
What observability is genuinely good at
Observability exists so that the people running a system can understand and repair it. Traces, spans, token counts, latency, prompt and completion capture, error rates, drift metrics. It is built for a reader who has context, access, and good faith — an engineer trying to work out why something broke.
At that job it is very good, and nothing here suggests replacing it. An observability stack is usually the single richest input to a reconstruction. The problem is not that the data is poor. It is that the data was collected for a reader who already trusts it.
Where it stops
Five gaps show up consistently, and none of them are fixed by collecting more telemetry.
Provenance is uniform. In a tracing system, every span carries the same weight, because every span came from the same instrumentation, controlled by the same team. That is fine for debugging and useless for accountability. A fact your own system recorded about itself and a fact attested by a system nobody in the decision path controls are not equivalent — and an auditor's first question is which one you have. Observability has no vocabulary for that distinction because it never needed one.
Nothing is confronted with what was declared. Your telemetry shows human review did not occur. Your policy says human review was required. Observability faithfully records the first and has never heard of the second. The contradiction between the declared world and the observed one is the single most valuable output of an audit, and it cannot be produced from telemetry alone.
Absence is invisible. If a control never ran, observability shows nothing — the same nothing it shows when a control ran and emitted no span, and the same nothing it shows when the instrumentation was misconfigured. Three very different situations, one identical silence. Evidence work has to distinguish "did not happen", "happened and was not recorded", and "cannot be determined", and report the third as not assessable rather than resolving it in whichever direction is convenient.
Retention outlives nobody. Tracing data is expensive, so it is sampled and expires — commonly in 30 to 90 days. The questions arrive at 6, 12, or 24 months, or when a claim is filed. A retention window shorter than your liability window means the record is gone precisely when it matters. This is the most common way an organisation with excellent observability discovers it cannot answer.
The record is mutable and self-owned. Telemetry lives in a system you control, that you can edit, backfill, or reprocess. That is a feature for operations and a defect for evidence. "We could have changed it, but we didn't" is not an argument that travels well, and no amount of internal access control makes it travel better.
There is a sixth, which is less a gap than a boundary: an observability stack can only hold what a machine emitted. An approval taken in a meeting, a supplier's certification, a test report, an assessment finding, or an interview with the engineer who made the call are all evidence, and none of them will ever appear in a trace. An evidence file has to be able to carry them — and to say plainly that a statement by a party does not weigh the same as a fact a system recorded, which in turn does not weigh the same as one attested outside the organisation.
Where incident response sits
Incident response is the bridge, and it is where most organisations first feel the gap. An incident response process is designed to restore service and identify a cause, quickly, using whatever is at hand. It is a fine engineering discipline and it produces an internal narrative — usually a postmortem written from memory, dashboards, and conversation, days after the event.
That narrative is honest and it is not evidence. It was assembled by the people involved, from sources they control, without grading, and it typically arrives after the underlying traces have started to expire. It answers "what do we think happened and how do we stop it recurring". It does not answer "what can we demonstrate happened, to someone who suspects we are wrong".
When an incident turns into a claim, a regulatory question, or a dispute — which is exactly when the stakes change — the postmortem is the first thing to be challenged, and it rarely holds.
The three side by side
|
Observability |
Incident response |
Evidence reconstruction |
| Reader | your engineers | your organisation | a third party who does not trust you |
| Tense | now | recently | months or years later |
| Question | what is it doing? | what broke, and why? | what can we demonstrate it did? |
| Provenance | uniform | mixed, ungraded | graded, per fact |
| Declared vs observed | not in scope | informal | held apart, explicitly |
| Missing data | invisible | assumed | reported as not assessable |
| Lifetime | 30–90 days typical | the postmortem | as long as the liability |
| Output | dashboards, traces | a narrative | an account that can be re-verified and challenged |
If you already have observability
The practical answer is that you are further along than most, and three cheap changes convert a good operational stack into something that can carry weight later.
Extend retention for the narrow slice that matters. You do not need 24 months of every span. You need the decision records — which model, which policy version, which configuration, which inputs, which approvals — for the decisions that carry consequence. That is a tiny fraction of the volume and the only fraction anyone will ask about.
Get one independent fact into the chain. A single corroboration from a system outside the decision path — an approval in a source control system, an external timestamp, an attestation from a service the team does not administer — changes the character of an entire file. Not because it proves everything, but because it proves the file is not purely self-reported.
Write down what the system was supposed to do, in a form that can be compared to what it did. Most organisations hold both halves and have never put them next to each other. The comparison is where the findings are.
When observability is enough
If your AI systems do not make or materially shape decisions affecting anyone outside your team, this is not your problem. An internal drafting assistant does not need an evidence layer, and adding one is theatre.
If nobody will ever ask, observability is enough. That is a legitimate position — worth holding deliberately rather than by default, because the cost of being wrong is paid at the worst possible moment.
And if you already emit signed, externally anchored decision records at the time of the decision, you have contemporaneous evidence, which is stronger than anything rebuilt afterwards. Reconstruction exists because in almost every real deployment that was not done. See why a perfect log can document an unauthorized decision.
Find out which side of the line you're on
FactNotebook reads the records you already have — traces, logs, tickets, source control, approvals, test and assessment reports, certifications, and written accounts from the people involved — and tells you what can and cannot be established from them. A complete example is published in full, including the SHA-256 manifest and an RFC 3161 timestamp token you can verify yourself with openssl.
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. If the answer is that your observability already carries the weight, that is a good result. If it does not, you have learned it now rather than in front of someone who is not on your side.
See the evidence package →Ask for a run on your system →
Also read: What is AI evidence reconstruction? · How do you reconstruct what an AI agent did when nothing was instrumented? · How do you prove a control actually ran?.
L'observabilité vous dit ce que votre système IA est en train de faire, pour ceux qui l'exploitent. La preuve établit ce qu'il a fait, pour quelqu'un qui ne vous fait pas confiance. La première est au présent et tournée vers l'intérieur. La seconde doit survivre à un lecteur hostile six mois plus tard.
C'est l'objection la plus fréquente, et elle mérite une vraie réponse plutôt qu'un slogan : on a déjà Langfuse, Datadog et OpenTelemetry — qu'est-ce qu'il nous faudrait de plus ?
Souvent, rien. Parfois, beaucoup. La différence ne tient pas à la qualité de votre instrumentation. Elle tient à qui l'enregistrement doit convaincre.
Ce que l'observabilité fait réellement bien
L'observabilité existe pour que ceux qui font tourner un système puissent le comprendre et le réparer. Traces, spans, comptes de tokens, latence, capture des prompts et complétions, taux d'erreur, métriques de dérive. Elle est faite pour un lecteur qui a le contexte, les accès et la bonne foi — un ingénieur qui cherche pourquoi quelque chose a cassé.
À ce métier elle est très bonne, et rien ici ne suggère de la remplacer. Une pile d'observabilité est en général l'entrée la plus riche d'une reconstitution. Le problème n'est pas que la donnée soit mauvaise. C'est qu'elle a été collectée pour un lecteur qui lui fait déjà confiance.
Où elle s'arrête
Cinq manques reviennent systématiquement, et aucun ne se corrige en collectant plus de télémétrie.
La provenance est uniforme. Dans un système de tracing, chaque span a le même poids, parce que chaque span vient de la même instrumentation, contrôlée par la même équipe. C'est parfait pour déboguer et inutile pour la responsabilité. Un fait que votre propre système a enregistré sur lui-même et un fait attesté par un système que personne dans le chemin de décision ne contrôle ne sont pas équivalents — et la première question d'un auditeur est : lequel avez-vous ? L'observabilité n'a pas de vocabulaire pour cette distinction, parce qu'elle n'en a jamais eu besoin.
Rien n'est confronté au déclaré. Votre télémétrie montre que la revue humaine n'a pas eu lieu. Votre politique dit qu'elle était obligatoire. L'observabilité enregistre fidèlement la première et n'a jamais entendu parler de la seconde. La contradiction entre le monde déclaré et le monde observé est la sortie la plus précieuse d'un audit, et elle ne peut pas être produite à partir de la seule télémétrie.
L'absence est invisible. Si un contrôle n'a jamais tourné, l'observabilité ne montre rien — exactement le même rien que lorsqu'un contrôle a tourné sans émettre de span, et le même rien que lorsque l'instrumentation était mal configurée. Trois situations très différentes, un silence identique. Le travail de preuve doit distinguer « n'a pas eu lieu », « a eu lieu et n'a pas été enregistré » et « ne peut pas être déterminé », et déclarer le troisième non évaluable plutôt que de trancher dans le sens qui arrange.
La rétention ne survit à personne. Les données de tracing coûtent cher : elles sont échantillonnées et elles expirent — couramment en 30 à 90 jours. Les questions arrivent à 6, 12 ou 24 mois, ou le jour où une réclamation est déposée. Une fenêtre de rétention plus courte que votre fenêtre de responsabilité signifie que l'enregistrement a disparu précisément quand il compte. C'est la manière la plus fréquente dont une organisation dotée d'une excellente observabilité découvre qu'elle ne peut pas répondre.
L'enregistrement est modifiable et vous appartient. La télémétrie vit dans un système que vous contrôlez, que vous pouvez éditer, recharger ou retraiter. C'est une qualité pour l'exploitation et un défaut pour la preuve. « On aurait pu le modifier, mais on ne l'a pas fait » n'est pas un argument qui voyage bien, et aucun contrôle d'accès interne ne le fait mieux voyager.
Il y en a un sixième, qui tient moins du manque que de la frontière : une pile d'observabilité ne peut contenir que ce qu'une machine a émis. Une approbation prise en réunion, la certification d'un fournisseur, un rapport de test, un constat d'évaluation, ou l'entretien avec l'ingénieur qui a tranché sont tous des preuves, et aucun n'apparaîtra jamais dans une trace. Un dossier de preuve doit pouvoir les porter — et dire clairement qu'une affirmation d'une partie ne pèse pas comme un fait enregistré par un système, qui lui-même ne pèse pas comme un fait attesté hors de l'organisation.
Où se situe la réponse à incident
La réponse à incident est le pont, et c'est là que la plupart des organisations sentent le manque pour la première fois. Un processus de réponse à incident est conçu pour rétablir le service et identifier une cause, vite, avec ce qui est sous la main. C'est une bonne discipline d'ingénierie, et elle produit un récit interne — en général un post-mortem écrit de mémoire, à partir de tableaux de bord et de conversations, plusieurs jours après.
Ce récit est honnête, et ce n'est pas une preuve. Il a été assemblé par les personnes impliquées, depuis des sources qu'elles contrôlent, sans gradation, et il arrive typiquement après que les traces sous-jacentes ont commencé à expirer. Il répond à « que pense-t-on qu'il s'est passé, et comment éviter que ça recommence ». Il ne répond pas à « que pouvons-nous démontrer, face à quelqu'un qui nous soupçonne d'avoir tort ».
Quand un incident devient une réclamation, une question réglementaire ou un contentieux — c'est-à-dire exactement quand les enjeux changent — le post-mortem est la première chose contestée, et il tient rarement.
Les trois côte à côte
|
Observabilité |
Réponse à incident |
Reconstitution de preuve |
| Lecteur | vos ingénieurs | votre organisation | un tiers qui ne vous fait pas confiance |
| Temps | maintenant | récemment | des mois ou des années après |
| Question | que fait-il ? | qu'est-ce qui a cassé, et pourquoi ? | que peut-on démontrer qu'il a fait ? |
| Provenance | uniforme | mêlée, non graduée | graduée, fait par fait |
| Déclaré vs observé | hors périmètre | informel | tenus à part, explicitement |
| Donnée manquante | invisible | supposée | déclarée non évaluable |
| Durée de vie | 30 à 90 jours en général | le post-mortem | aussi longue que la responsabilité |
| Sortie | tableaux de bord, traces | un récit | un récit re-vérifiable et contestable |
Si vous avez déjà de l'observabilité
La réponse pratique, c'est que vous êtes plus avancé que la plupart, et que trois changements peu coûteux transforment une bonne pile d'exploitation en quelque chose qui pourra porter du poids plus tard.
Allongez la rétention sur la tranche étroite qui compte. Vous n'avez pas besoin de 24 mois de chaque span. Vous avez besoin des enregistrements de décision — quel modèle, quelle version de politique, quelle configuration, quelles entrées, quelles approbations — pour les décisions qui portent à conséquence. C'est une fraction infime du volume, et la seule sur laquelle on vous interrogera.
Faites entrer un fait indépendant dans la chaîne. Une seule corroboration venue d'un système hors du chemin de décision — une approbation dans un gestionnaire de sources, un horodatage externe, une attestation d'un service que l'équipe n'administre pas — change la nature d'un dossier entier. Non parce qu'elle prouve tout, mais parce qu'elle prouve que le dossier n'est pas purement auto-déclaré.
Écrivez ce que le système était censé faire, sous une forme comparable à ce qu'il a fait. La plupart des organisations détiennent les deux moitiés et ne les ont jamais mises côte à côte. La comparaison, c'est là que sont les constats.
Quand l'observabilité suffit
Si vos systèmes IA ne prennent ni n'influencent matériellement des décisions affectant quelqu'un hors de votre équipe, ce n'est pas votre problème. Un assistant de rédaction interne n'a pas besoin d'une couche de preuve, et lui en ajouter une relève du théâtre.
Si personne ne demandera jamais rien, l'observabilité suffit. 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.
Et si vous émettez déjà, au moment de la décision, des enregistrements signés et ancrés à l'extérieur, vous avez de la preuve contemporaine, plus forte que tout ce qu'on rebâtit après coup. La reconstitution existe parce que, dans presque tout déploiement réel, cela n'a pas été fait. Voir pourquoi un journal parfait peut documenter une décision non autorisée.
Savoir de quel côté de la ligne vous êtes
FactNotebook lit les enregistrements que vous avez déjà — traces, logs, tickets, gestion de sources, approbations, rapports de test et d'évaluation, certifications, et les comptes rendus écrits des personnes impliquées — et vous dit ce qui peut et ne peut pas en être établi. Un exemple complet est publié en entier, avec son manifeste SHA-256 et un jeton d'horodatage RFC 3161 que vous pouvez vérifier vous-même au openssl.
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. Si la réponse est que votre observabilité porte déjà le poids, c'est un bon résultat. Sinon, vous l'apprenez maintenant plutôt que devant quelqu'un qui n'est pas de votre côté.
Voir le paquet de preuve →Demander un passage sur votre système →
À lire aussi : Qu'est-ce que la reconstitution de preuve IA ? · Comment reconstituer ce qu'un agent IA a fait quand rien n'était instrumenté ? · Comment prouver qu'un contrôle a réellement tourné ?.