How Do You Prove to a Regulator What Your AI Did Without Giving Them Access to the System?

You prove what your AI did by handing the regulator a self-contained evidence bundle they verify with public keys alone, not by giving them a login. Every action the system took was sealed at the moment it happened to a post-quantum signed audit ledger, so the bundle can be checked offline, on the regulator's own hardware, with nothing connecting back to you. If a single record was altered, added or removed, the signatures fail and the verifier shows exactly where. Access to the running system is never required, because the proof travels in the evidence, not in the system.

This is now a procurement question, not a theoretical one. Regulated buyers in finance, healthcare, defence and critical infrastructure are asked to demonstrate what their AI decided, on what inputs, under whose authority, and to do it without exposing live systems, personal data or model internals to an outside party. Public cloud AI services cannot answer this cleanly, because their audit trail lives inside infrastructure the buyer does not control and, under the US CLOUD Act, may be reachable by a foreign jurisdiction.

What does a regulator actually need to see?

A regulator does not need your system. They need four things they can trust: what the AI did, what it acted on, who or what authorised it, and proof none of it was edited after the fact. In practice that means an ordered record of every decision, the inputs and model version behind each one, the identity that triggered it, and a chain of signatures binding those records together. If those four things can be verified independently, the regulator has what they came for.

How does offline-verifiable proof work?

Inside the Sovereign Intelligence Operating System, every action is sealed the instant it happens. Each entry records the decision, the inputs, the model version and the acting identity, then is hashed and linked to the entry before it, forming a chain where any change downstream breaks every seal above it. Each entry is signed with a post-quantum signature scheme, ML-DSA, standardised as FIPS 204, so the seals hold even against an adversary with a future quantum computer. Identity is hardware-attested and bound into the same chain, so a record cannot claim an actor the hardware did not attest. To prove what happened, the operator exports an evidence bundle, the sealed records, their signatures, the public keys and a small verifier, and the regulator runs it on their own machine, offline. This sealing architecture sits within our estate of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented.

What can an auditor check with public keys alone?

Give an auditor the bundle and a public key and they can check, without ever touching the live system:

• Integrity: every signature is valid, so no record was altered.
• Completeness: the hash chain is unbroken, so no record was inserted or removed.
• Authenticity: each action is bound to a hardware-attested identity, so no actor was forged.
• Order: the chain fixes the exact sequence, so events cannot be reordered after the fact.
• Provenance: each decision names the exact model version and inputs behind it.

The test is simple to state: change one byte anywhere in the bundle and verification fails at that point.

Why can't a cloud dashboard or KMS-anchored receipt do this?

Most current answers anchor their receipts to a cloud key management service. A receipt anchored to a cloud KMS still requires that cloud to be reachable, trusted and outside a hostile jurisdiction before anyone can verify it. When the auditor sits in a secure facility with no connectivity, or when the question is whether the cloud provider could have tampered with the record, an anchor you cannot reach or cannot independently trust is not proof. Offline verifiability removes the dependency, because the public keys travel with the bundle, so for sovereignty-sensitive buyers the location and control of the audit trail is part of the compliance question.

“The strongest proof of what an AI did is one a regulator can verify alone, offline, with a public key, and without ever being given the keys to the system.”

Which rules make this necessary?

The EU AI Act requires logging and traceability for high-risk systems. The Digital Omnibus deferred those high-risk Annex III obligations, once due on 2 August 2026, to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. DORA, in force across EU financial entities since January 2025, demands digital operational resilience and evidence of it. NIS2 raises the bar for critical-infrastructure operators, GDPR requires that you can show how automated decisions were reached, and ISO/IEC 42001 expects auditable governance of AI. Every one of these is easier to satisfy when the evidence is portable and self-verifying rather than locked inside a system an assessor must be let into.

What stops the operator forging or deleting the record?

The obvious objection is that the operator controls the hardware, so why trust their bundle. The answer is that control of the hardware does not give control of the mathematics. Records are append-only and chained, so deleting or editing one breaks every seal above it and the verifier reports the break. Signing keys are bound to attested hardware, so an entry cannot be back-dated or re-signed by a different actor without detection. Where higher assurance is needed, decisions can be taken by cross-model consensus, so no single model's output stands unchecked in the record. Forgery is not prevented by trusting us. It is made detectable by anyone holding a public key.

Frequently asked questions

Can a regulator verify what our AI did without internet access?

Yes. The evidence bundle contains the sealed records, their signatures, the public keys and a verifier, so it can be checked on an air-gapped machine. Nothing needs to reach back to our systems or to any cloud. Offline verifiability is the whole point: the proof travels in the bundle, not in a live connection.

What is a post-quantum signed audit ledger?

It is an append-only record where each entry is hashed, chained to the one before it, and signed with a post-quantum digital signature scheme. We use ML-DSA, standardised as FIPS 204, so the seals resist both classical and future quantum attacks. Because the entries are chained, altering any one of them breaks every seal above it and the verifier reports exactly where.

Does the regulator have to see personal data or our model internals?

No. The bundle proves what happened, who authorised it and that nothing was altered, without exposing the running system, the model weights or raw personal data beyond what a record requires. You can prove integrity and provenance while keeping sensitive material and system access out of scope. That separation keeps the disclosure safe for both sides.

How is this different from exporting normal system logs?

Ordinary logs can be edited, reordered or selectively deleted, and an auditor has to trust the exporter. A sealed ledger cannot be changed without breaking its signatures, so trust moves from your word to a mathematical check anyone can run. The named test is simple: change one byte and verification fails at that point.

What happens if our AI runs completely offline and disconnected?

That is the case this is built for. Mickai is a Sovereign Intelligence Operating System that runs on operator-owned hardware behind a zero-egress inbound perimeter, sealing every action as it happens. Because verification never depends on connectivity, a fully disconnected system produces exactly the same portable, checkable proof as a connected one.