A control can sit in the codebase, be named in the policy, and appear on the architecture diagram — and never once have acted on a real decision. "The control exists" and "the control ran" are different claims, and most AI governance only checks the first. The gap between them is where compliance quietly becomes theater.
Three proofs that aren't
"The code is there." Code can be unreachable, disabled by a config flag, or wired around. Presence is not execution.
"The documentation says so." A declaration describes intent, not behavior. The two can diverge for years without anyone noticing.
"A log shows approved = true." A single field the system wrote about itself is the system grading its own paper.
Each of these looks like proof. None of them establishes that, for the decision under scrutiny, the control did anything at all.
A control that is implemented but never triggered is, to a regulator, indistinguishable from a control that was never there.
What "it ran" actually requires
Proving execution means producing observable evidence — from a channel operationally independent of the deciding system — that the control acted on this decision, at this time. A trace, not an assertion. The deciding system cannot be the sole author of the proof that it was governed; that is the structural flaw underneath most audit records.
Effectiveness is not existence
A control can be implemented and still be inert: disabled in configuration, sitting on a code path nothing reaches, or silently bypassed. Asking "did it run?" is asking about effectiveness — whether the control was operative when a consequence occurred — not about whether someone once wrote it. Effectiveness is the property regulators are starting to demand, and the one declarative evidence cannot supply.
The honest answer when you can't tell
Sometimes the channel that would show whether a control ran simply wasn't there when the event happened. The correct output is then neither "it ran" nor "it failed" — it is NOT ASSESSABLE. Absence of observation is not evidence of absence. A system that collapses this into a pass or a fail is inventing a verdict the evidence does not support. Saying NOT ASSESSABLE out loud is what makes the rest of the record trustworthy.
Where the line sits
Whether "it ran on 94% of decisions" is good enough is a judgment for an accountable authority under a stated standard. The evidence layer's job is narrower: show, from independent observation, whether the control operated — or state honestly that it cannot be assessed. Facts first; admissibility after.
See it on a real system
A complete audit that separates controls that ran from controls that merely exist — and marks the rest NOT ASSESSABLE.
Un contrôle peut être dans la codebase, nommé dans la politique, figurer sur le diagramme d'architecture — et n'avoir jamais agi sur une décision réelle. « Le contrôle existe » et « le contrôle a tourné » sont deux affirmations différentes, et la plupart des gouvernances IA ne vérifient que la première. C'est dans cet écart que la conformité devient silencieusement du théâtre.
Trois preuves qui n'en sont pas
« Le code est là. » Le code peut être inatteignable, désactivé par un flag de config, ou contourné. La présence n'est pas l'exécution.
« La documentation le dit. » Une déclaration décrit une intention, pas un comportement. Les deux peuvent diverger pendant des années sans que personne ne le remarque.
« Un journal montre approved = true. » Un champ unique que le système a écrit sur lui-même, c'est le système qui corrige sa propre copie.
Chacune ressemble à une preuve. Aucune n'établit que, pour la décision examinée, le contrôle a fait quoi que ce soit.
Un contrôle implémenté mais jamais déclenché est, pour un régulateur, indistinguable d'un contrôle qui n'a jamais existé.
Ce qu'« il a tourné » exige réellement
Prouver l'exécution, c'est produire une preuve observable — depuis un canal opérationnellement indépendant du système qui décide — que le contrôle a agi sur cette décision, à ce moment. Une trace, pas une affirmation. Le système qui décide ne peut pas être le seul auteur de la preuve qu'il a été gouverné ; c'est la faille structurelle sous la plupart des registres d'audit.
L'efficacité n'est pas l'existence
Un contrôle peut être implémenté et rester inerte : désactivé en configuration, sur un chemin de code que rien n'atteint, ou silencieusement contourné. Demander « a-t-il tourné ? », c'est interroger l'efficacité — le contrôle était-il opérant quand une conséquence est survenue — pas le fait que quelqu'un l'ait un jour écrit. L'efficacité est la propriété que les régulateurs commencent à exiger, et celle que la preuve déclarative ne peut fournir.
La réponse honnête quand on ne peut pas savoir
Parfois, le canal qui montrerait si un contrôle a tourné n'était tout simplement pas là au moment de l'événement. La bonne sortie n'est alors ni « il a tourné » ni « il a échoué » — c'est NON ÉVALUABLE. L'absence d'observation n'est pas la preuve d'une absence. Un système qui réduit cela à un succès ou un échec invente un verdict que la preuve ne soutient pas. Dire NON ÉVALUABLE à voix haute, c'est ce qui rend le reste du registre fiable.
Où se situe la ligne
Savoir si « il a tourné sur 94 % des décisions » suffit relève du jugement d'une autorité responsable sous un standard énoncé. Le rôle de la couche de preuve est plus étroit : montrer, depuis une observation indépendante, si le contrôle a opéré — ou déclarer honnêtement qu'on ne peut l'évaluer. Les faits d'abord ; l'admissibilité après.
Voyez-le sur un système réel
Un audit complet qui sépare les contrôles qui ont tourné de ceux qui existent seulement — et marque le reste NON ÉVALUABLE.