MICKAI
Article · 8 July 2026

Data Residency Is Not Data Sovereignty

Keeping data inside a border is a location fact, not a control fact, and the two are routinely confused in procurement.

Data Residency Is Not Data Sovereignty
Author
Micky Irons
Published
8 July 2026
Follow Micky Irons
LinkedInX
data sovereigntydata residencysovereign aieu ai actgovernance

On 2 August 2026 the EU AI Act reaches full application, and the questions that regulators, chief information security officers and public-sector buyers were able to defer are now live. At the same time the UK Sovereign AI programme is pressing departments to state where their models run and who holds the keys, and the NHS continues to voice unease about foreign control of patient data. The phrase that keeps surfacing in tenders is data residency. It is the wrong phrase for what most of these bodies actually need.

Residency answers where, sovereignty answers who

Data residency is a statement about geography. It says that records sit on infrastructure inside a named country or region, and that copies are not written outside that boundary without a documented exception. It is a location fact. Data sovereignty is a statement about authority. It asks who can read the data, who can move it, who can compel its disclosure, and who can switch off the systems that process it. That is a control fact, and it is a different question entirely.

The two are routinely merged in procurement because a region label is easy to verify and a control chain is not. A buyer can point at a datacentre map and tick a box. Establishing that the encryption keys, the administrative accounts, the update pipeline and the legal jurisdiction all rest with parties the buyer trusts is slower work, and it rarely fits inside a compliance checkbox. So residency gets treated as a proxy for sovereignty, and the proxy fails precisely when it matters.

Data Residency Is Not Data Sovereignty, illustration 1

Why the border does not hold

Consider a public body that stores citizen records in a national region. The bytes never leave the country. Yet the operator of the region may hold the master keys, may run the maintenance accounts with standing access, and may be incorporated under a legal regime that can compel production of data regardless of where the disks physically spin. Extraterritorial disclosure powers do not respect datacentre walls. If a foreign court or agency can lawfully order the operator to hand over records, residency has bought the buyer nothing on the control question.

The processing layer is where the gap widens further. Even when stored data stays put, inference and analytics frequently route through shared services, telemetry pipelines and model endpoints that sit outside the residency boundary. A record can be encrypted at rest inside the border and still be decrypted, embedded, logged and reasoned over by systems the buyer neither owns nor governs. Residency describes the filing cabinet. It says nothing about who reads the files.

Keeping data inside a border is a location fact, not a control fact. Sovereignty is decided by who holds the keys, who can compel disclosure and who can turn the system off, none of which a region label can settle.

Data Residency Is Not Data Sovereignty, illustration 2

The four tests procurement should actually run

To separate the two properly, buyers can pose four control questions and refuse to accept a region map as an answer to any of them.

  • Key custody: who generates, holds and rotates the encryption keys, and can the buyer revoke access unilaterally without the operator cooperating?
  • Administrative access: which accounts hold standing or break-glass access to the running systems, who employs the people behind them, and are those actions logged in a store the buyer controls?
  • Legal reach: under whose jurisdiction is the operating entity constituted, and what disclosure or access powers can be exercised against it irrespective of where the data resides?
  • Processing path: where does inference, embedding, analytics and telemetry actually run, and does any of it leave the trust boundary the contract claims to establish?

A supplier that can answer all four with evidence is offering sovereignty. A supplier that answers only the first geography question and deflects the rest is offering residency dressed as something more. The distinction is testable, and it should be tested before signature rather than discovered during an incident.

Data Residency Is Not Data Sovereignty, illustration 3

What the regulation is really asking

The EU AI Act does not use the word residency as its organising idea. Its obligations attach to control: risk management, human oversight, logging, data governance and the ability to explain and, where required, halt a system. Those are authority questions, not map questions. A high-risk system whose data happens to sit in region while its oversight, keys and stop control sit elsewhere does not satisfy the spirit or the letter of the obligation. The UK Sovereign AI framing lands in the same place when it asks departments who holds the keys, because keys are custody and custody is control.

This matters for the NHS case in particular. The concern voiced about foreign control of patient data is not primarily a concern about which country the disks are in. It is a concern about whether a party outside the health service governance can read, move or be compelled to surrender the most sensitive records a citizen holds. Residency cannot answer that. Only a demonstrable control chain can.

Data Residency Is Not Data Sovereignty, illustration 4

Building for sovereignty rather than around it

The practical response is to design so that control never leaves the buyer hands in the first place. That means keys generated and held inside the buyer boundary, administrative access that the operator cannot exercise unilaterally, processing that runs on infrastructure the buyer governs, and an audit trail written to a store the buyer owns. It means treating the model runtime, not just the storage bucket, as part of the trust boundary.

This is the design premise of Mickai, a Sovereign Intelligence Operating System (SIOS) built so that models run under the operator own control, keys stay with the operator, and processing does not silently cross a boundary the contract promised to hold. The approach is described across a portfolio of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; these are filed applications, never granted or patented. The point of the architecture is narrow and specific: make sovereignty a property that can be inspected and proven, not a label that residency is quietly asked to stand in for.

The line buyers should draw

Residency and sovereignty are both legitimate requirements, and residency has its place in a compliance posture. The error is substitution. When a tender asks for residency and accepts a region map, it has verified where the data sleeps and left every question about who controls it unanswered. As the AI Act reaches full application and sovereign programmes harden their language, the buyers who fare best will be the ones who write the four control tests into their requirements and decline to treat a location fact as a control fact. The border tells you where the data is. It does not tell you whose data it has become.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/data-residency-is-not-data-sovereignty. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles