Proof over policy: compliance belongs in the system, not the binder.

Ask most organisations to demonstrate AI governance and you will receive a document: a policy, a register, a risk assessment, a completed questionnaire. Each is a statement about what the system is supposed to do. None of them is the system. The distance between those two things is where nearly every governance failure we have seen actually lives.

The failure is rarely dramatic. A model is retrained to fix a seasonal drift and the change is not recorded because the pipeline that retrains it is not the pipeline the policy describes. A dataset is copied into a notebook for a legitimate investigation and never deleted. An integration is added by a competent engineer who did not know that a control depended on the old data path. Nobody behaved badly. The documentation is simply no longer a description of reality, and no mechanism existed to notice.

Documentation degrades silently. Mechanisms fail loudly. That is the entire argument.

Three properties that separate evidence from paperwork

It is produced by the work, not about it. If a record has to be written by someone after the fact, it will eventually be written late, written from memory, or not written. Evidence that is emitted by the action itself — the deployment, the approval, the data access, the batch release — cannot drift from the action, because it is the action's own trace.

It is tamper-evident. An audit trail that can be edited by the people it audits is a courtesy, not a control. Append-only records with verifiable ordering cost very little to implement at design time and are effectively impossible to retrofit convincingly after an incident.

It is queryable in the shape the question arrives in. Regulators, customers, and boards do not ask what your policy says. They ask which decisions this model influenced last quarter, who approved the change, where that personal data physically resided, and what happened to the copy. If answering takes three weeks of manual assembly, you did not have the evidence. You had the raw material for it.

Why frameworks alone under-deliver

None of this is an argument against frameworks. ISO 42001, the NIST AI RMF, and the EU AI Act's high-risk obligations are well-constructed, and they name the right concerns: lineage, human oversight, robustness, transparency, post-market monitoring. What they cannot do is execute. A framework tells you which properties your system must have. It is silent on whether yours currently has them, and that silence is where the risk accumulates.

The common failure mode is a governance programme staffed as a reporting function: a team that gathers attestations from the teams doing the work. It produces confident quarterly summaries and almost no ground truth. When an incident arrives, the summaries turn out to have been describing the intended system rather than the deployed one, and the reconstruction begins under time pressure and legal scrutiny — the worst possible conditions.

If your only evidence is an attestation that a control exists, what you have is a record of someone's belief.

What compliance as code actually requires

The phrase is used loosely, so it is worth being precise about the minimum. Controls are expressed as executable checks that run in the same pipeline as the thing they govern. Failing a check blocks the action rather than filing a ticket. Every check emits a signed, timestamped result to an append-only store. Policy changes are versioned alongside code, so that any historical decision can be evaluated against the rules in force at the time — not today's rules, which is the mistake that makes retrospective audits unfair and useless.

Two further properties matter in practice. Controls must degrade safely: when a dependency is unavailable, the default is to refuse the action, not to wave it through. And the evidence store must be readable by people who did not build it, because the auditor arriving in two years will not have access to the engineer who wrote it.

The organisational consequence

Done properly, this changes who owns governance. It stops being a department that reviews and becomes a property of the platform teams ship on. Reviews still happen, but they examine evidence rather than assertions, and the review cycle shortens dramatically because there is nothing to assemble. The compliance function moves from gathering to interpreting — which is the work it should have been doing.

It also changes the economics. Most of the cost of compliance is not the control; it is the repeated human labour of demonstrating the control. Automate the demonstration and the marginal cost of the next audit, the next market, and the next enterprise customer's security questionnaire falls towards zero. That is the argument we make to boards, and it is a commercial one before it is an ethical one.

Where to start

Pick one high-consequence decision your organisation makes with model assistance. Ask what you could prove about the last hundred instances of it — inputs, model version, approver, data location, outcome — using only what your systems already emit. The gap you find is your governance backlog, ordered by materiality, and it will be more honest than any maturity assessment.

Build systems that answer for themselves. Everything else is a promise that someone will remember.