Who Offers a Fully Offline AI With an Immutable Audit Trail?

A fully offline AI with an immutable audit trail is offered by systems that run entirely on operator-owned hardware and seal every action to a cryptographically signed ledger. Mickai is built as one such system: a Sovereign Intelligence Operating System, a SIOS, that runs with no outbound connection and writes each decision to a post-quantum signed audit chain. This is true because both requirements are architectural, not features that can be added later. An AI that can reach the internet is not offline, and a record an administrator can edit is not immutable.

The question matters more in 2026 than it did even a year ago. Regulated buyers in finance, defence and government are being told to keep sensitive data inside their own control and to prove, after the fact, exactly what an automated system did. Public services such as ChatGPT, Claude and Gemini run on infrastructure the buyer does not own, so for the most sensitive work they are often ruled out before the conversation starts. The buyer is left asking a precise question that most vendors answer loosely.

What does fully offline actually mean?

Fully offline means the system has no path to send your data anywhere. Not a filtered connection. Not a trusted vendor endpoint. No egress at all. The plain test is to pull the network cable and see whether the system keeps answering. A model that calls a cloud API, checks a licence server or ships usage telemetry is a connected system with an offline mode, which is a different risk profile. We design for a zero-egress inbound perimeter: requests and updates can enter under the operator's control, and nothing leaves the boundary.

What makes an audit trail immutable, not just a log?

A log records what happened. An immutable audit trail records what happened in a way that no one can alter afterwards, including the administrator who holds the keys. The difference is cryptography. Each entry is signed and chained to the one before it, so editing any single record breaks every signature that follows and the tampering becomes visible. We sign the ledger using FIPS 204, ML-DSA, the post-quantum signature standard, so the seal holds even against a future quantum attacker. Key exchange uses FIPS 203, ML-KEM, which protects data in transit but does not sign records and does not, on its own, make anything verifiable.

“An AI you cannot disconnect is not offline, and a record its operator can quietly edit is not an audit trail.”

What can an auditor actually check?

Offline verifiability is the point that separates a real audit trail from a dashboard. An auditor should be able to take a copy of the ledger to a separate machine, with no access to the vendor and no live connection, and confirm three things: that every entry is signed, that the chain is unbroken, and that each action is bound to the identity that performed it. We bind entries to a hardware-attested identity, so the record shows not only what was decided but which attested device and operator produced it. Verification does not depend on trusting us.

What should you ask any vendor to demonstrate?

Ask for a live demonstration, not a data sheet. A short, checkable list separates a real claim from a slogan:

• Disconnect the network in front of you and show the system still answering.
• Show where egress is blocked at the perimeter, not merely disabled in a setting.
• Export the audit ledger and verify its signatures on a machine the vendor has never touched.
• Edit one historical record and show that the chain visibly breaks.
• Show that each entry is tied to an attested hardware identity, not a shared login.
• Name the standard used to seal the ledger and confirm it is a signature standard.

A genuine offline system with an immutable trail passes all six in a room with no internet. Anything less is an aspiration.

Which rules make this necessary?

Several regimes push in the same direction. DORA has applied to EU financial entities since January 2025 and demands operational resilience and traceability. NIS2 raises the bar for essential and important entities, and GDPR governs where personal data may be processed. ISO/IEC 42001 sets management expectations for AI systems. Under the US CLOUD Act, data held by a US provider can be reachable by US authorities wherever it sits, which is exactly the exposure an offline system removes. The EU AI Act adds timing: the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk duties moved to 2 August 2028 and the Article 50 transparency rules largely unchanged. We read that deferral as a build window, not a reprieve.

None of this means that using a cloud service breaches a law, and no architecture on its own satisfies a regulation. What an offline, sealed design does is reduce exposure and support the duties a regulator will test, so that when an auditor asks what happened, the answer is provable rather than promised.

How is Mickai built for both requirements?

Mickai runs on the operator's own hardware behind a zero-egress inbound perimeter, so the data plane has no route out. Every action, from a retrieved document to a model decision, is written to a post-quantum signed audit ledger bound to hardware-attested identity. For high-stakes outputs we use cross-model consensus, where more than one sovereign model must agree before an answer is issued, and the disagreement itself is recorded. The underlying models are ours to run and to inspect, not remote services we rent. The architecture is described across 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all of which remain filed and patent pending, not granted.

Frequently asked questions

Is any public cloud AI truly offline?

No. Services such as ChatGPT, Claude and Gemini process prompts on infrastructure the provider controls, so your data leaves your boundary by design. They can be excellent for open work, but they are not offline in the sense a regulated buyer means, which requires that the system keep working with the network physically removed.

What is the difference between an audit log and an immutable audit trail?

An audit log is a record that a privileged user can usually edit or delete. An immutable audit trail is signed and chained so that altering any past entry breaks the cryptographic seal and is detectable. If you can change one historical record without the verification failing, it is a log, not an immutable trail.

Does an offline AI still receive security updates and new models?

Yes. Updates and new models enter through the same controlled inbound path that requests use, under the operator's authority, while the outbound path stays closed. Being offline refers to the data plane, meaning your information never leaves. It does not mean the system is frozen or unmaintained.

Can a vendor's contractual promise replace an offline architecture?

No. A promise not to access or move your data is a legal commitment, not a technical barrier, and it can be overridden by a subpoena, a breach or a change of ownership. Under laws such as the US CLOUD Act, a provider may be compelled to hand over data it holds. An offline architecture removes the capability rather than merely promising restraint.

How can an operator prove to an auditor that the trail was not tampered with?

Export the ledger and verify it on an independent machine the vendor has never touched. Every entry should carry a valid signature, the chain of entries should be unbroken, and each action should map to an attested hardware identity. Because verification runs offline and does not rely on the vendor, the proof holds even if the vendor is not in the room.