Data Residency for AI: How to Keep Data In House

You guarantee data residency for AI by making residency a property of the architecture rather than a clause in a contract. If inference runs on hardware you own, inside your own walls, and the model is bound to loopback with no path to an external endpoint, then your data cannot leave, because there is nowhere for it to go. At that point residency stops being a promise a vendor makes and becomes something you can test. Mickai, the British Sovereign Intelligence Operating System, is built so that residency is guaranteed by where the computation happens, not by where a contract says the data is stored.

• Cloud AI complicates residency because inference happens on infrastructure you do not control, often across regions you cannot see.
• A contractual residency guarantee is only as strong as the vendor's compliance and the jurisdiction they answer to.
• Running inference locally on owned hardware makes residency architectural: the data has no route out.
• Verify residency, do not accept it: test for network egress, confirm retrieval is local, check licensing is hardware-bound, and demand an offline-verifiable audit record.
• If a system keeps working with the network unplugged, its residency claim is real. If it does not, it never was.

Why cloud AI complicates residency

Cloud AI is convenient precisely because the hard part happens somewhere else. Your prompt, your documents, and often your retrieval context travel to a provider's inference infrastructure, get processed, and return. Even with regional pinning and data-processing agreements, the workload lives on machines you do not own, in a topology you cannot inspect, subject to the laws of wherever the provider is incorporated.

Retrieval makes it worse. Modern AI features rarely send just a question. They send the relevant chunks of your internal documents alongside it, so the model has context. That means the sensitive material, not just the query, crosses the boundary. A residency guarantee that covers storage but not this in-flight context is guaranteeing the wrong thing.

Residency as architecture, not contract

A contractual guarantee says: we promise to keep your data in region X. It relies on the vendor's controls, their subprocessors, their honesty, and the reach of the jurisdiction they operate under. When it holds, it holds because everyone behaved. That is assurance, and assurance can be withdrawn, breached, or compelled.

An architectural guarantee says something stronger: the data cannot leave because the system has no mechanism to send it. There is no external endpoint in the code path. Pull the cable and the product behaves identically. This is the shift I wanted to build into Mickai from the start. Residency should be a fact about the machine, not a line item you have to trust and re-audit every year.

Running inference on hardware you own

The way you make residency architectural is to run the model where the data already is. Mickai's engine, Poros, runs a large and capable model locally, bound to loopback only, and works fully offline. The inference happens on your hardware. The retrieval happens against your own indexes on the same machine. Nothing about answering a question requires a packet to leave the building.

This is also why sovereignty and capability are not in tension. The instinct is to assume that keeping everything local means settling for a small model. It does not. Sixty-three studios run on the one local engine, fourteen production-ready at launch and forty-nine in active development, and they all draw on the same in-house inference. The residency guarantee is not bought with weaker AI. It is bought with a different architecture.

What a buyer should verify

Do not accept a residency claim. Test it. These are the checks I would run, and the ones I want buyers to run against Mickai.

• No egress, tested. Ask whether the absence of network egress is verified as a release gate, not just asserted. In Mickai it is tested, so a build that tries to phone home does not ship.
• Local retrieval. Confirm that document retrieval and context assembly happen on the local machine, so sensitive material never travels with the query.
• Hardware-bound licensing. Check that the software is licensed to your hardware and does not depend on a remote licensing server that must be reached to keep working. A licence check that phones home is a residency leak.
• Offline-verifiable audit. Require an audit record you can verify on your own equipment, without contacting the vendor.

No egress as a release gate

The phrase that matters here is release gate. Plenty of systems can be configured to avoid outbound calls. That is not the same as a system that will not ship if it makes them. In Mickai, the absence of egress on the inference path is something we test as a condition of release, so it is a property of the build rather than a setting an administrator has to remember. That is the difference between hoping a door is locked and having a lock that will not let the door close otherwise.

An audit record that survives an audit

Residency is about where data goes. Proof is about what the system did with it. Both are needed, because a regulator will ask about both. Mickai records consequential actions to the Open Audit Record, an audit trail signed with FIPS 204 ML-DSA-65 post-quantum signatures and verifiable offline. It is tamper-evident: I will not tell you a record can never be altered, but I will tell you that any alteration shows, and that you can confirm this yourself without trusting us.

That property is part of what our filings cover: 104 filed UK patent applications across 2,340 claims, patent-pending at the UK Intellectual Property Office. We patent the mechanism, not the model. I have also written up the underlying approach in technical preprints on Zenodo for anyone who wants the detail behind the claims.

Frequently asked questions

What does data residency mean for AI specifically?

It means the data used and produced by the AI, including the internal documents pulled in for context, stays within a defined boundary such as your building or your jurisdiction. AI complicates this because inference and retrieval often move that data to external infrastructure, so the boundary has to cover processing, not just storage.

Can a cloud provider guarantee residency?

They can offer a contractual guarantee about the regions they store and process data in, and reputable providers honour it. But it remains a promise backed by their controls and their jurisdiction. It is weaker than an architecture where the data has no route out in the first place.

How does local inference guarantee residency?

If the model runs on hardware you own and has no external endpoint in its code path, the data physically cannot leave. Mickai's Poros engine runs locally over loopback and works fully offline, so residency is enforced by the design rather than by a policy someone could change.

What should I ask a vendor to prove residency?

Ask whether no-egress is tested as a release gate, whether retrieval is local, whether licensing is bound to your hardware rather than a remote server, and whether the audit record can be verified offline. Then ask to watch the system keep working with the network disconnected.

Does keeping data in house mean a weaker model?

No. That is the assumption I built Mickai to disprove. A large, capable model runs locally through Poros, and all sixty-three studios draw on that same in-house engine. Residency comes from architecture, not from shrinking the model.

Is Mickai available to evaluate?

Mickai is in closed beta and we are onboarding design partners at mickai.co.uk/beta. It is built by Mickai LTD, Companies House number 17166618, and the founder and named inventor is me, Micky Irons.