What Is an AI Audit Trail, and Why Regulators Want One

An AI audit trail is a durable, ordered record of what an artificial intelligence system actually did: which model produced a given output, on which machine, over which inputs, and under whose authority. Regulators want one for a plain reason. An AI system that cannot show its work cannot be held to account. If you cannot say what the model was asked, what it answered, and who authorised the result, you cannot investigate a complaint, defend a decision, or prove that a rule was followed. The audit trail is what converts an opaque process into an accountable one.

• An AI audit trail records the model, the machine, the inputs, the outputs and the human clearance behind each action.
• It exists so decisions can be reconstructed, investigated and defended after the fact.
• A good trail is tamper-evident: any later change to the record can be detected.
• It should be verifiable offline, without trusting the system that produced it.
• Mickai's Open Audit Record is a worked example, signed with post-quantum cryptography.

A working definition

Strip away the jargon and an audit trail is memory with integrity. It is the answer to what happened, in what order, and whether we can prove it, applied to a system that makes or assists decisions. For ordinary software this is well understood. For artificial intelligence it is both harder and more important, because the outputs are probabilistic, the inputs can be vast, and the same prompt can yield different answers on different days or different models.

So an AI audit trail is not simply a server log. It is a record built to survive scrutiny: complete enough to reconstruct a specific decision, structured enough to search, and protected enough that its own contents can be trusted. When people say an AI system is accountable or auditable, this is the artefact they are implicitly relying on, whether or not it actually exists.

What a good AI audit trail records

The value of a trail is in its completeness. Four things, recorded together, are what make an AI action reconstructable.

• Which model. The specific model and version that produced the output, so behaviour can be tied to a known system rather than a moving target.
• On which machine. The device the inference ran on, which matters for residency, isolation and knowing exactly where the processing took place.
• Over which inputs. The prompt, context and data the model saw, so the output can be understood in light of what was actually asked.
• With what human clearance. Who was authorised to act on the result, and under what standing rule, so oversight is provable rather than assumed.

Miss any one of these and the trail develops a blind spot. A record of outputs with no inputs cannot explain a decision. A record of inputs and outputs with no operator cannot show who was responsible. A record that does not pin the model and the machine cannot even establish which system you are talking about.

Why tamper-evidence matters

A record only helps if it can be trusted, and the obvious failure of ordinary logs is that they can be edited. If the same party that runs the system can quietly rewrite its history, the log proves nothing to an outsider. This is why the important property is not secrecy but tamper-evidence: not that the record can never be altered, but that any alteration is detectable.

I am deliberate about that word. I never describe our audit record as tamper-proof or unbreakable, because no honest engineer can promise that. The achievable and genuinely useful guarantee is narrower: if a record is changed after it was written, the change shows. That is enough to make the trail worth something in a dispute, because a regulator or a court does not need the record to be invulnerable. They need to know whether it has been touched.

Why offline verifiability matters

The second property that separates a serious audit trail from a decorative one is where you have to stand to check it. If verifying a record means calling back to the vendor's servers, then the vendor is still in the loop, and your evidence depends on their continued cooperation and existence. A trail you can only check with the supplier's permission is a weak trail.

Offline verifiability removes that dependency. If the record can be validated on your own hardware, with the signature and the tools in your hands, then the evidence stands on its own. It survives the supplier going out of business, changing terms, or simply being unavailable at the moment you need proof. For anything you might have to defend years later, that independence is the whole point.

The Open Audit Record as a worked example

This is the design we built into Mickai, the British Sovereign Intelligence Operating System. Every action the system takes can be written to an Open Audit Record, or OAR. Each record is signed with a post-quantum signature scheme, FIPS 204 ML-DSA-65, chosen because a record meant to hold up for years should not rest on cryptography that a future quantum computer could unpick. The signature makes the record tamper-evident, and it can be verified offline, without contacting us.

Because Mickai runs the capable model locally through our engine, Poros, with no network egress, the record can capture the full picture honestly: the model and version, the machine, the inputs and the human clearance, all on the device where the work happened. Sixty-three studios run on that one engine, with fourteen production-ready at launch and forty-nine in active development, and they all write to the same record format. That uniformity is deliberate. One consistent, verifiable trail across every tool is far more useful than a scrapbook of different logs.

It is also the part of the system we protect as intellectual property. Mickai LTD (Companies House number 17166618) holds 104 filed UK patent applications with 2,340 claims, patent-pending at the UK Intellectual Property Office. Those are applications, not grants, and I am careful to say so. The principle behind them is that we patent the mechanism, not the model: the way the record is produced, signed and verified, rather than any particular set of weights.

Where audit trails fit in the wider picture

Regulators are converging on the same expectation from several directions. The EU AI Act asks high-risk systems to keep logs and support traceability. The GDPR's accountability principle asks controllers to be able to demonstrate compliance, not just claim it. Sector rules in finance, health and the public sector increasingly assume that automated decisions can be explained and reviewed. In every case the underlying need is the same: a trustworthy account of what the system did.

I set out the fuller argument in a technical preprint on turning compliance into evidence, published on Zenodo under my ORCID, 0009-0000-5511-5858. The short version is that an audit trail is how an AI system earns the right to be trusted with consequential work. It is not paperwork bolted on at the end. It is the record that lets everyone else, the operator, the auditor, the regulator and the person affected, see what happened and check it for themselves.

Frequently asked questions

What is the difference between an AI audit trail and an ordinary log?

An ordinary log is a stream of events, usually editable, meant mainly for debugging. An AI audit trail is built for accountability: it records the model, machine, inputs, outputs and human clearance for each action, and it is protected so that changes to it can be detected. The goal is not operational visibility for engineers but defensible evidence for outsiders.

Why do regulators want an AI audit trail?

Because accountability requires reconstructability. Frameworks such as the EU AI Act and the GDPR expect that a consequential decision can be explained, reviewed and, if necessary, challenged. Without a record of what the model did and who authorised it, none of that is possible. The audit trail is the practical mechanism that lets a regulator move from trusting a claim to checking a fact.

What does 'tamper-evident' mean, and why not 'tamper-proof'?

Tamper-evident means that if the record is altered after it is written, the alteration can be detected. Tamper-proof would mean the record could never be altered at all, which no honest system can promise. I use the accurate term on purpose. For evidence, detectability is what matters: a regulator needs to know whether a record has been changed, not to be told it is invulnerable.

Why does offline verification matter?

If you can only verify a record by contacting the supplier, your evidence depends on that supplier being cooperative and still in business. Offline verification means you can check the record's integrity yourself, on your own hardware, at any time. For decisions you may have to defend years later, that independence is essential.

What is the Open Audit Record?

It is Mickai's implementation of an AI audit trail. Each record is signed using a post-quantum scheme, FIPS 204 ML-DSA-65, is tamper-evident, and can be verified offline. It captures the model, the machine, the inputs and the human clearance for each action, because Mickai runs the model locally and can record the whole picture on the device where the work took place.

Who is Micky Irons?

I am the founder and named inventor of Mickai, the British Sovereign Intelligence Operating System, built by Mickai LTD. I have published technical preprints on sovereign AI and on the compliance-to-evidence approach on Zenodo. My interest in audit trails is not academic: they are the part of the architecture that decides whether an AI system can be trusted with work that matters.