How to Prove What an AI System Did After the Fact

You prove what an AI system did after the fact by keeping a tamper-evident audit ledger that records every action and seals each entry with a cryptographic signature that anyone can verify offline. The record is trustworthy because verification does not depend on the vendor. The signatures either check out against a published public key or they do not, and any edit, deletion or reordering breaks the chain. That is the difference between evidence and a screenshot.

This matters in 2026 because regulated buyers are being asked to account for automated decisions they did not personally make. Boards want to know what a model was shown, what it produced and who authorised the outcome. A logging feature you have to take on faith answers none of that. What holds up under scrutiny is a record whose integrity can be checked by a third party, on a disconnected machine, months later.

What does proving what an AI did actually mean?

It means three separate things, and most audit-trail claims cover only the first. One, completeness: every material action was recorded, not a sampled subset. Two, integrity: the record has not been altered since it was written. Three, attribution: each entry is bound to a specific identity and a specific point in time. A convincing answer proves all three at once, and proves them to someone who was not in the room.

How does an offline-verifiable audit ledger work?

Each action becomes an entry: the input, the model version, the output, the operator identity and a timestamp. Each entry is hashed, and each hash includes the hash of the entry before it, forming a chain. Every entry is then signed. Because the chain is append-only and each link commits to the last, you cannot quietly change entry ten without invalidating every entry after it. To verify, an auditor recomputes the hashes and checks the signatures against the public key. No network call, no vendor portal and no live service are required.

What can an auditor check without trusting the vendor?

The point of offline verification is that trust moves from the vendor to the maths. An auditor holding the ledger and the public key can independently confirm:

• That the signatures are valid, so the entries were sealed by the holder of the private key.
• That the hash chain is unbroken, so nothing was inserted, removed or reordered.
• That timestamps run forward and match the sequence, so the timeline is coherent.
• That each entry names the identity and the model version responsible.

None of these checks phone home. That is the property that makes the record admissible as evidence rather than as assurance.

Why are public cloud AI services hard to prove after the fact?

When work runs on a shared public cloud service, the buyer does not hold the record. The provider does. The log lives on infrastructure the buyer does not control, under a retention policy the buyer did not set, exportable in a format the provider chooses. There is no independent way to prove that export is complete or unaltered. Under the US CLOUD Act, data held by a US provider can also be compelled across borders, which is a separate problem for regulated European buyers. The architecture, not any provider's good faith, is the issue.

“A record you cannot verify without trusting the party who wrote it is not evidence, it is a claim.”

Which rules make this necessary?

Several regimes now expect a defensible account of automated activity. DORA has been in force since January 2025 and requires financial entities to evidence operational resilience and traceability. NIS2 raises accountability for essential and important entities across critical sectors. GDPR requires that automated decisions can be explained and contested. ISO/IEC 42001 sets out auditable AI management controls. The EU AI Act adds obligations for high-risk systems: those Annex III duties, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and the Article 50 transparency rules largely unchanged. We read the deferral as a build window, not a reprieve.

Which cryptography seals the ledger?

Signatures are what make an entry provable, so the signature scheme has to outlast the record. We seal the ledger with the post-quantum digital signature standards: FIPS 204, ML-DSA, as the primary scheme, with FIPS 205, SLH-DSA, available alongside it. Both are signature standards, chosen so that a record sealed today still verifies once classical elliptic-curve signatures are no longer safe. FIPS 203, ML-KEM, is a key-encapsulation standard for establishing keys and plays no part in signing or verifying the ledger. Getting that distinction right is the difference between a seal that holds and one that does not.

How does Mickai implement this?

Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on operator-owned hardware. Every action is sealed into a post-quantum signed audit ledger at the point it happens. Identity is hardware-attested and bound directly to the audit chain, so an entry names the machine and the operator, not just a username. A zero-egress inbound perimeter means data does not leave the estate, so the record the operator holds is the whole record. Where a decision is high-consequence, cross-model consensus records the agreement of more than one sovereign model rather than a single opaque output. The design is covered by 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD, filed and patent pending.

Frequently asked questions

What is the difference between an audit log and an offline-verifiable audit ledger?

An ordinary audit log is a list of events you have to trust. An offline-verifiable ledger seals each event with a cryptographic signature and chains the entries together, so any change is detectable. The key difference is that a third party can confirm the ledger is intact on a disconnected machine, using only the public key, without asking the vendor.

Can an AI audit trail be used as legal evidence?

It is far stronger as evidence when its integrity can be proven independently. A record that anyone can verify offline, where signatures and a hash chain show nothing was altered, is closer to admissible evidence than an exported log whose completeness rests on the provider's word. The standard to aim for is a record an opposing expert cannot plausibly claim was edited.

Why does post-quantum signing matter for an audit record?

Audit records must stay verifiable for years, often longer than the classical cryptography protecting them will remain safe. Signing with FIPS 204 and FIPS 205 means a seal applied today still verifies after quantum computing weakens older elliptic-curve signatures. It protects the future provability of a record you are creating now.

How can you prove what an AI did if it runs offline?

Running offline strengthens proof rather than weakening it. Because the operator holds the hardware and the ledger, there is no external provider whose export you must trust. Verification uses only the ledger and the public key, both of which can be examined on an air-gapped machine, so the record's integrity does not depend on any network or vendor.

Does keeping the record on our own hardware help with the CLOUD Act?

Yes. When the record sits on operator-owned hardware inside a zero-egress perimeter, there is no third-party provider holding your data that can be compelled to disclose it under the US CLOUD Act. Control of the evidence stays with the entity accountable for it, which is what most regulated buyers need.