Offline AI and the EU AI Act: From Compliance to Evidence

Running artificial intelligence offline, on hardware you own, does not lift a single duty under the EU AI Act or the General Data Protection Regulation. What it changes is how you meet those duties. Instead of asking a regulator to accept a supplier's word about what happens inside a distant data centre, you can point to records the system produced itself, on your own premises, that an independent party can check. That is the practical case for offline AI in regulated work: it moves several obligations from trust to evidence. This article is written for compliance teams and regulated buyers, and it is not legal advice.

• Offline processing keeps personal and special-category data inside your own boundary, which simplifies data residency and international-transfer questions.
• An owned system lets you generate your own records of processing rather than reconstruct them from a vendor's logs.
• A verifiable audit record turns logging and traceability from a promise into evidence a third party can inspect.
• Human oversight is far easier to demonstrate when the decision, the operator and the clearance are recorded together.
• Your actual obligations depend on your role, your use case and your risk classification, so treat this as background, not counsel.

How offline AI reframes the compliance question

Most AI compliance debates start from a hosted assumption. The model sits with a provider, your data travels to it, and your assurance rests on contracts, sub-processor lists and the provider's own attestations. That arrangement can be made lawful, but the burden of proof is awkward. You are accountable for processing you cannot directly observe, and much of your evidence is somebody else's to produce.

An offline system inverts that. With Mickai, the British Sovereign Intelligence Operating System I founded and am the named inventor of, the capable model runs locally through our engine, Poros, bound to the loopback interface and fully cut off from the network. The data does not leave the machine. The consequence for compliance is not that the rules change, but that you become the party that holds the evidence. You are no longer describing a process you rent. You are recording one you own.

Records of processing and data residency

Under the GDPR, controllers and processors are expected to maintain records of their processing activities, and to know where personal data lives and where it flows. Cross-border transfers carry their own conditions. When inference happens on a server in another jurisdiction, answering the simple question of where the data is being processed can require a diagram of sub-processors and regions.

When inference happens on a machine in your own building, the answer is short. The data is processed here, on this device, and it does not leave. Residency stops being a transfer analysis and becomes a statement of fact about a box you can point to. That does not complete your records of processing for you, but it removes a large source of uncertainty from them, and it narrows the international-transfer questions considerably.

Logging and traceability, turned into evidence

The EU AI Act expects high-risk systems to keep logs and to support traceability across their lifetime, so that events can be reconstructed and examined. The GDPR's accountability principle points the same way: you should be able to show, not merely assert, that your processing met your obligations. The weakness in ordinary logging is that logs are editable. A log file proves what it says only to the extent that you trust whoever controlled it.

This is where an owned architecture earns its keep. Mickai writes an Open Audit Record, or OAR, for the actions it takes. Each record is signed with post-quantum cryptography, using the FIPS 204 ML-DSA-65 signature scheme, and it is designed to be tamper-evident: any later alteration to the record is detectable, and the record can be verified offline, without calling back to us or to anyone else. I am careful never to call this tamper-proof. Nothing is unbreakable. The claim is narrower and more useful: if the record is changed, the change shows.

Human oversight you can demonstrate

The EU AI Act treats human oversight as a design requirement for high-risk systems, not an afterthought. Deployers are expected to keep a person meaningfully in the loop, able to understand, question and override the system. The hard part in practice is not putting a human there. It is proving, later, that the human was there and what they decided.

Because Mickai records the action, the operator and the clearance together, oversight becomes something you can show. The record does not just say an output was produced. It says who was authorised to act on it and under what standing rule. When a regulator, an auditor or a claimant asks how a decision was reached and who stood behind it, you have a signed answer rather than a recollection.

Why owning the system matters more than calling it private

'Private' has become a marketing word. A hosted service can be described as private while still processing your data on infrastructure you neither see nor control. Ownership is a stronger and simpler property. If the model, the engine and the audit record all sit on your hardware, then the questions a regulator cares about, where is the data, what did the system do, who authorised it, all have answers you can produce yourself.

That is the deliberate shape of Mickai. Sixty-three studios run on the one engine, with fourteen production-ready at launch and forty-nine in active development, and every one of them writes to the same audit record. The point of building it as an operating system rather than a loose collection of tools is that the evidence is uniform. You are not stitching together attestations from a dozen suppliers. You are reading one record.

From compliance to evidence

I have written this argument up more formally. Among the technical preprints I have published on Zenodo (my ORCID is 0009-0000-5511-5858) is one on turning compliance into evidence under the GDPR and the EU AI Act: the idea that many duties framed as obligations to be trustworthy can instead be met by producing verifiable records at the moment of processing. The Open Audit Record is the mechanism that makes that concrete. It is also why our patent position is framed as it is: with 104 filed UK patent applications and 2,340 claims, patent-pending at the UK Intellectual Property Office, we patent the mechanism, not the model. The filings are applications, not grants, and I say so plainly.

A note on scope

None of this is legal advice, and offline architecture is not a shortcut around the law. Your obligations depend on your role as controller, processor or deployer, on the use case, and on where your system sits in the Act's risk tiers. A data protection impact assessment may still be required. Human review may still be mandatory. What an owned, offline system with a verifiable record changes is the quality of your proof. It lets you answer hard questions with evidence you hold, rather than assurances you have borrowed. If you want to test that in your own environment, the closed beta is open at mickai.co.uk/beta, where we are onboarding design partners.

Frequently asked questions

Does running AI offline exempt me from the EU AI Act?

No. The Act applies according to what your system does and the risk it carries, not where the computation happens. Offline operation does not remove obligations such as human oversight, record-keeping or risk management. It changes how well you can evidence them, because the records are produced and held on your own hardware rather than a supplier's.

How does offline processing help with GDPR data residency?

If personal data is processed on a machine inside your own boundary and never leaves it, the residency question becomes a matter of fact about that device rather than an analysis of cross-border transfers and sub-processors. It does not complete your records of processing for you, but it removes a common source of ambiguity and narrows the international-transfer conditions you have to satisfy.

What is the Open Audit Record?

It is the signed, tamper-evident log that Mickai writes for the actions it takes. Each entry is signed using a post-quantum scheme, FIPS 204 ML-DSA-65, and can be verified offline. If an entry is altered after the fact, the alteration is detectable. It is designed as evidence you can hand to an auditor or a regulator without asking them to trust us.

Is this the same as a certification such as ISO 27001 or SOC 2?

No. Certifications are independent attestations against a defined standard, and they are targets we are working towards, not claims I will make before they are earned. An audit record is a different thing: it is evidence about specific actions your system took. The two are complementary. One says your controls meet a standard; the other shows what actually happened.

Who is behind Mickai?

Mickai is built by Mickai LTD, registered at Companies House under number 17166618. I am Micky Irons, the founder and named inventor. I have published technical preprints on sovereign AI and on the compliance-to-evidence approach on Zenodo, and the architecture described here reflects that work.

Can I evaluate this for a regulated use case?

Yes. We are running a closed beta at mickai.co.uk/beta and onboarding design partners, including teams in regulated settings who want to test the audit record against their own compliance requirements. I would still encourage you to take your own legal advice on your specific obligations.