ISO 42001 Certifies Your Process, Not Your Past

Picture the scene every compliance team is quietly dreading. A regulator, a customer, or a court asks one question. On the fourteenth of last month, at 09:42, your system declined this person's loan, flagged this transaction, or escalated this medical case. Show me that the model did what your policy says it should have done, on that decision, at that moment.

Watch what happens next. Someone reaches for a certificate. They slide a handsome PDF across the table that says the organisation holds ISO 42001, the world's first management-system standard for artificial intelligence, audited by a respectable body, valid through next year. It is a genuine achievement. It cost real money and real discipline to earn. And it answers a different question entirely.

The question a certificate was built to answer

ISO 42001 is a management-system standard. So is its older cousin in security, ISO 27001, and so, in its own way, is a SOC 2 report. They are excellent at the job they were designed for. They examine whether you have a governance structure, whether you wrote the policies down, whether you assigned the roles, whether you ran the risk assessments, whether you have a process for monitoring and improving the whole machine. An auditor samples the evidence, forms an opinion, and attests that at the time of the audit a credible system was in place.

That is worth having. An organisation that cannot describe how it governs its models is not one I would trust with mine. But notice the precise shape of what is being attested. It is a statement about your system of work, sampled at a point in time, projected forward on the assumption that the system keeps running as described. It is a photograph of the kitchen, taken on inspection day, hung on the wall as proof of every meal served since.

The gap between attesting a system and proving an event

Here is the distinction I want to drive a wedge into, because almost every governance conversation I have blurs it. Attesting a system tells you a capable process existed. Proving an event tells you what actually happened in one specific instance. These are not two strengths of the same evidence. They are different kinds of evidence, about different things.

A certificate cannot tell you whether the model that handled the 09:42 decision was the version your policy approved, or a hot-fixed build someone pushed at midnight. It cannot tell you which prompt was actually sent, which retrieval documents were actually in context, which guardrail fired or was silently switched off, what the model returned before a downstream system reshaped it. It cannot tell you any of this, because it never looked at that decision. It looked at your process for decisions, in general, on audit day.

“A management-system certificate proves you built a good kitchen. It says nothing about the meal on the plate in front of you.”

I am not knocking the standard for failing to do a job it never claimed. ISO 42001 is honest about its scope. The failure is in how the certificate gets used downstream, waved as if it were proof of conduct when it is proof of capability. The two get conflated precisely when the stakes are highest, in the regulator's room and the courtroom, where the question is never whether you have been good in general but whether you were correct here, on this one.

Why the snapshot decays the moment it is signed

There is a deeper problem than scope, and it is structural. An AI system is not a static thing the way a fire door is static. It drifts. Models are retrained, fine-tuned, swapped for a cheaper provider, wrapped in new orchestration. Prompts mutate weekly. Retrieval corpora grow and rot. A guardrail that fired in March is quietly relaxed in June to cut latency. The system the auditor blessed and the system serving traffic today are related, but they are not the same system, and the gap widens every single day after the ink dries.

So the certificate is not just narrow, it is perishable. It attests to a configuration that may no longer exist by the time anyone relies on it. Annual recertification samples the new state once a year and projects forward again, which means for most of the year you are trusting a snapshot of a thing that has already moved. In a field that changes as fast as this one, that is a very long time to be running on faith.

What proving an event actually requires

If you genuinely want to answer the 09:42 question, you need a different artefact entirely. You need a record created at the moment of the decision, by the system, capturing the things that made that decision what it was. Not a log you could edit afterwards. A record bound by cryptography, so that any later tampering is detectable, sealed in a way that ties it to a specific model, a specific input, a specific output, a specific time.

The properties that matter are not exotic, but they are demanding, and ordinary application logging meets almost none of them. To prove an event you need:

• Integrity, so the record cannot be altered after the fact without that alteration becoming obvious to anyone who checks.
• Attribution, so the record is bound to the exact model version, configuration, and policy in force at decision time, not the one in the brochure.
• Completeness, so the inputs, the context, the guardrail outcomes, and the output are captured together as one sealed unit, rather than scattered across systems that can be reconciled creatively.
• Independent verifiability, so a third party can confirm the record is authentic with mathematics, rather than with trust in your good character.
• Durability against the future, so a record sealed today still verifies in five or ten years, including against adversaries with far more computing power than exists now.

That last property is the one most people skip, and it is the one I refuse to. A signature scheme that is sound today but breaks under a future quantum machine is not durable evidence, it is a time bomb wearing a lanyard. Evidence that has to survive a decade of legal and regulatory scrutiny has to be sealed with that decade in mind.

The Open Audit Record

This is the layer I built, and it is the reason I can sit across from the hardest question and reach for something other than a PDF. In the Sovereign Intelligence Operating System, every consequential action taken by any of the fifty specialised brains is sealed, at the moment it happens, into an Open Audit Record. Not a summary written later. The thing itself, captured as it occurs, on the operator's own hardware, fully offline-capable.

Each record is signed with a post-quantum signature under FIPS 204, the ML-DSA-65 scheme, so the seal is built to outlast the cryptography we rely on today. The record binds the model version, the input, the policy in force, the guardrail outcomes, and the output into one tamper-evident unit. Anyone holding the record can verify it independently. They do not have to trust me, the operator, or the vendor. They check the mathematics, and the mathematics answers.

The point is not the cleverness of the seal. The point is what the seal lets you do. It turns the unanswerable question into a routine lookup. On the fourteenth, at 09:42, here is the exact record of that decision, here is the model that made it, here is the policy it was held to, and here is the proof that none of it was touched since. The 09:42 question stops being the thing you dread and becomes the thing you can answer in front of anyone.

How the two layers belong together

I want to be careful here, because the easy move is to set these against each other and declare a winner, and that would be wrong. The certificate and the record are not rivals. They are two layers of the same evidentiary stack, and a serious organisation wants both. The management-system standard attests that you have a credible process. The cryptographic record proves that any given decision actually ran inside that process the way it was meant to.

Put them together and something genuinely new appears. Today an ISO 42001 audit relies on sampling, because the auditor has no practical way to inspect millions of individual decisions and must instead trust that the sampled few represent the whole. Give that same auditor a stream of independently verifiable records, one per decision, and sampling stops being a limitation imposed by reality. The certifier can verify rather than trust. The snapshot becomes continuous. That is what I mean by continuous AI audit evidence: not a replacement for the standard, but the substrate that lets the standard finally reach the individual decision it was always too coarse to touch.

“Sampling is what you do when you cannot see everything. Per-decision records are what you reach for when you can.”

The owl that keeps watching

Why does any of this matter beyond the satisfaction of a tidy argument? Because the trust model of the entire field is about to be tested in anger. The EU AI Act is landing. Sectoral regulators are sharpening their questions. Courts are starting to ask not whether your governance looked tidy, but whether a specific output was what you say it was. In that world, a certificate that attests a process and a record that proves an event will be treated very differently, and the organisations that conflated them will find out the hard way which one the hard question actually needs.

I think of the owl on the council-chamber rail, the one that never closes its eyes. The certificate is the stamped scroll in one hand, and it deserves its place. But the chain of sealed discs in the other hand, each one a decision that can be reproduced and verified long after everyone in the room has forgotten the day it was made, that is the part that watches. A certificate tells me you were trustworthy on inspection day. A record tells me you were correct at 09:42. When the question that matters arrives, and it will, only one of those is holding evidence.

Certify the kitchen by all means. I will hold the certificate with respect. But when you sit down and the plate arrives, do not ask me to take the meal on faith. I sealed it the moment it was made, and you are welcome to check.