MICKAI
Article · 13 June 2026

You Cannot Prove a Negative Without a Record

When your artificial intelligence is accused of misuse, the only defence is a tamper-evident account of what it actually did. Ordinary logs fail at exactly the moment you need them most.

You Cannot Prove a Negative Without a Record
Author
Micky Irons
Published
13 June 2026
Follow Micky Irons
LinkedInX
AI accountabilityaudit recordtamper-evidenceAI governancepost-quantum cryptography

You cannot prove a negative without a record

Here is a problem that every operator of an intelligent system will eventually face, and almost none have prepared for. One day a customer, a regulator, a journalist, or a court will accuse your artificial intelligence (AI) of doing something it should not have done. It read data it had no right to touch. It made a decision it was forbidden to make. It acted on a user it was never authorised to act on. Then the question lands on your desk, and it is the hardest question in security. Prove it didn't.

You cannot. Not with confidence, not under pressure, not in front of someone who has every incentive to disbelieve you. Proving a negative is the oldest trap in logic. You cannot demonstrate the absence of an event by reasoning about it. You can only demonstrate it by holding up a complete, trustworthy account of everything that actually happened and showing that the accused event is not in it. No record, no defence. That is the whole game, and most teams are walking onto the field without a ball.

Innocence is not a state, it is an account

Security people learn early that you do not get to feel innocent. You get to be provably innocent, or you get to be suspected. There is no third option once an allegation is made, because the burden has quietly shifted. The accuser does not have to show that your system misbehaved. They only have to show that you cannot demonstrate it didn't, and human institutions treat that inability as guilt. Ask anyone who has sat in a breach response room while a regulator waits for logs that turn out to be incomplete.

The deeper trouble with AI is that the thing being accused is fast, autonomous, and opaque. A traditional application does a small number of things, slowly, in ways a human signed off on. A modern AI system takes a great many consequential micro-decisions every hour, each one a judgement call, each one capable of being wrong in a way that looks deliberate after the fact. When you multiply the volume of consequential actions by the difficulty of explaining any single one of them, you get a liability surface that ordinary logging was never designed to cover.

So the question is not whether your AI is well-behaved. Mine is, yours probably is too. The question is whether, on the worst day, you can reconstruct exactly what it did, in order, without anyone being able to argue you edited the story afterwards. Behaviour is invisible. Only the account is admissible, and an account you cannot produce is the same as one that never existed.

Why ordinary logs fail at exactly the wrong moment

Most systems do keep logs. The problem is that the logs answer the wrong question. Conventional logging proves what your system told itself it was doing. It does not prove what actually happened, because the same operator who runs the system also writes, stores, rotates, and can alter the log. A record that the keeper can change is not evidence. It is a diary, and a diary persuades no one who suspects the author.

A marble relief of an interlocking chain with one link visibly fractured, lit by gold rim light against void black.
Tamper-evidence made physical. Break a single link in a hash-chained record and the fracture is visible to anyone, with no quiet repair.

Stack up the failure modes and the picture gets bleak. Logs are written after the action, so a system that has already gone wrong cannot be trusted to honestly describe how it went wrong. Logs are mutable, so anyone with sufficient access can quietly remove the inconvenient line. Logs are usually incomplete, capturing what a developer thought to capture rather than the full chain of cause and effect. And logs sit inside the vendor's trust boundary, which means the party with the most to lose from the truth is also the party guarding it. On the day you need to prove a negative, every one of those weaknesses becomes the other side's argument.

This is not a hypothetical worry any more. From August 2026 the European Union (EU) AI Act places real obligations on high-risk systems for record keeping and traceability, and liability regimes across multiple jurisdictions are tilting toward the operator who cannot account for an automated decision. The regulatory direction of travel is unambiguous. If a machine acted, you will be expected to show the machine's working. Soft logs will not survive that standard, and the teams discovering this in a response room are discovering it too late.

What a record has to be before it counts

If a record is going to defend you, it has to satisfy conditions that ordinary logging quietly skips. It must be created before or at the moment of the action, not narrated afterwards, because an account written after the fact is exactly when tampering happens. It must be tamper-evident, so that any change, even deleting a single entry, breaks the structure visibly and cannot be silently repaired. It must be complete, covering every consequential action rather than a hand-picked subset. And, most importantly, it must be verifiable by someone who does not trust you, because a record you have to vouch for is worth nothing the moment your honesty is the thing in dispute.

That last condition is the one almost everyone gets wrong. The point of evidence is to remove yourself from the chain of belief. If the verifier has to take your word that the record is genuine, you have not escaped the trap of proving a negative, you have just moved it one step back. A record only ends the argument when the other side can check it themselves, with their own tools, owing you nothing. Anything short of that is a better diary, and a better diary still loses the argument.

The record we built, and why it ends the argument

This is the problem the Open Audit Record (OAR) inside Mickai was built to solve, and it is the reason I describe Mickai as a Sovereign Intelligence Operating System (SIOS) rather than another model with a dashboard. In Mickai, every AI action is signed before it executes. Not logged after. Signed, cryptographically, in the instant of decision, so the account is created at the only moment it cannot be doctored. Those signatures are hash-chained and append-only, which means each entry locks the one before it. Remove a line and the chain breaks. Edit a line and the chain breaks. There is no quiet correction, only a visible fracture that anyone can spot.

The signatures are post-quantum, using the United States National Institute of Standards and Technology (NIST) standard for module-lattice digital signatures, Federal Information Processing Standards Publication 204 (FIPS 204), in its ML-DSA-65 parameter set. A record signed today does not become forgeable the day a sufficiently capable quantum computer arrives. And the whole thing is verifiable offline, in an ordinary web browser, with no trust placed in Mickai as the vendor. That is the part that matters most to me. You do not have to believe me. You run the check yourself, against the cryptography, and the record either holds or it does not. Beneath that, the Pantheon chain anchors the audit root to Bitcoin, so the existence and ordering of the record is witnessed by something that neither I nor anyone else can quietly rewrite.

A marble bust of a stern philosopher in profile, half-lit by gold rim light against void black, examining something unseen.
The only record that ends an argument is one a sceptic can verify alone, owing the vendor nothing.

None of this makes the AI behave better. It was never meant to. The fifty brains on the Poseidon silicon substrate are governed by their own controls, and the record is a different organ entirely. What the OAR does is convert good behaviour into provable behaviour, which is the only kind that survives an accusation. When someone claims Mickai touched data it should not have, I do not argue, and I do not ask anyone to trust my logs. I point to a signed, hash-chained, offline-verifiable account and let them confirm for themselves that the action they are alleging simply is not there. The negative proves itself.

Build the account before you need it

The uncomfortable truth is that the day you need this record is the day it is too late to start keeping it. You cannot retroactively sign actions that have already run. You cannot hash-chain a history you did not capture. Evidence is not something you assemble in the response room. It is something that either already exists, complete and untampered, or does not. Every autonomous action your system takes between now and your first serious allegation is either being recorded in a way that will defend you or quietly accumulating into a liability you cannot answer for.

I am a security realist about most claims in this industry, including some of my own. The architecture I have described is built and running, the audit machinery is live, and the Pantheon chain is the one piece we are still bringing up. But the underlying point is just logic, and it holds whatever you run. When the accusation comes, and for any consequential AI system it will come, your only defence is a tamper-evident account of what the machine actually did, written before the fact, complete, and checkable by someone who owes you nothing. You cannot prove a negative without a record. So build the record first.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/prove-a-negative-without-a-record. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles