In-Country Processing Is Not The Same As In-Your-Control: Reading The Copilot Residency Expansion

By Micky Irons

On 4 November 2025, Microsoft announced that it would offer in-country data processing for Microsoft 365 Copilot across fifteen countries. Australia, the United Kingdom, India and Japan come first, with the option to keep Copilot interactions processed inside the country by the end of 2025. Then, through 2026, eleven more follow: Canada, Germany, Italy, Malaysia, Poland, South Africa, Spain, Sweden, Switzerland, the United Arab Emirates and the United States. For the European Union and EFTA, Microsoft said local inferencing would be delivered at a regional level, aligned with its EU Data Boundary commitments.

That is a genuinely useful move, and I want to be fair about it. But I watch enterprise buyers read an announcement like this and quietly upgrade it in their heads from "where the data is processed" to "our data is now sovereign." Those are not the same sentence. Residency answers one question. Sovereignty and ownership answer two entirely different ones. If you sign off a Copilot rollout believing residency closed all three, you have mispriced your own risk.

Three questions, not one

When people say "sovereign," they usually blur three distinct things together. Pull them apart and the whole procurement conversation gets clearer.

Residency is: where does the data physically sit and get processed? This is what Microsoft just expanded. In-country processing means your Copilot interactions run in data centres inside your borders rather than being shipped to a region on the other side of the world. Good. It reduces latency, it satisfies data-localisation rules that genuinely require in-country storage, and it is a real answer to a real question.

Sovereignty is: who can lawfully compel access to that data, regardless of where it sits? This is the question residency does not touch. A US-headquartered provider remains subject to US law wherever its servers are. The Clarifying Lawful Overseas Use of Data Act, the CLOUD Act, enacted in 2018, lets US authorities compel a US-based provider to hand over data it controls no matter which country that data is stored in. The whole point of that statute is that jurisdiction follows control, not geography. Storing your data in Frankfurt or London does not remove it from the reach of a provider's home jurisdiction.

Ownership is: who runs the model, holds the keys and can see the operation? Even with in-country processing, the model weights, the orchestration and the operational plane belong to the vendor. You are a tenant. You do not run the runtime, you do not hold the root of trust, and you cannot fully attest what happened inside it. Residency does not change your tenancy.

Why the honest version matters

I am not going to tell you the law bars you from cloud. It mostly does not, and anyone selling you that line is selling fear. GDPR, the EU AI Act, DORA, and the FCA and PRA frameworks in the UK all permit cloud and hyperscaler use with appropriate controls. DORA, in application since 17 January 2025, is explicitly a controls-and-resilience regime for financial entities, not a cloud ban. The EU AI Act governs how high-risk systems behave, not where they run.

So the honest market is not "you are legally forbidden from the cloud." The honest market is preference plus a narrow hard bar. The preference is real and growing. Boards, regulators and risk committees increasingly want architectures where they can prove control under stress, including geopolitical stress. And there is a genuine tension between the CLOUD Act and European law, because GDPR Article 48 says a third-country authority's demand for personal data is only enforceable in the EU through an international agreement such as a mutual legal assistance treaty. A US provider caught between the two is a risk you inherit, not one that residency resolves.

The genuine no-cloud bar, where residency and even a sovereign-cloud wrapper are not enough, is workload-level. Classified and SECRET-and-above material. ITAR-controlled defence data. Isolated operational technology and SCADA environments that cannot touch a public network by design. Cases where a data protection impact assessment comes back negative on any externally-operated processing. For those workloads, "processed in your country by someone else's model under someone else's jurisdiction" still fails. That is a slice of the estate, not the whole of it, and it is worth being precise about which side of the line a given workload actually sits on.

When residency is enough, and when it is not

Residency is enough when your obligation is genuinely about location. Data-localisation statutes that require storage and processing inside the border, latency-sensitive workloads, and the large category of sensitive-but-not-restricted data where a controls-based cloud posture is defensible and documented. For a great deal of enterprise Copilot use, in-country processing is a real improvement and a reasonable answer. Take the win.

Residency is not enough the moment your threat model includes the provider's own jurisdiction, or the moment you need to prove, not assert, what the system did. If your risk register has a line for foreign lawful-access compulsion, residency does not close it. If your regulator wants evidence that you retain operational control of a critical function under stress, tenancy does not give you that. If the workload sits behind the hard bar above, none of the residency options on the market reach it.

That is the line. Below it, cloud with controls, now with in-country processing, is a sound choice. Above it, only an architecture you own and operate clears the bar.

What owning the runtime actually looks like

This is the gap Mickai is built for. Mickai is a Sovereign Intelligence Operating System, a SIOS. It is not a hosted service with a residency toggle. Regulated organisations own it and run it inside their own walls, air-gapped, on their own hardware. The model runs where you run it, the keys are yours, and every action the system takes is written to a cryptographically-signed audit record you hold, so you can prove behaviour rather than trust a dashboard.

When the runtime is inside your perimeter and disconnected by design, the CLOUD Act question resolves itself. There is no external provider holding your data to compel. The sovereignty question and the ownership question collapse back into the residency question, because you are the operator, the host and the jurisdiction all at once. That is the difference between in-country and in-your-control.

I hold this position from the build, not the brochure. Mickai's approach to sovereign, auditable AI is reflected in a portfolio of 104 filed UK patent applications spanning roughly 2,340 claims across 13 families, with Mickarle Wagstaff-Irons as named inventor, now moving toward examination. Filed, not granted, and I will always say so plainly.

The takeaway

Read the Copilot residency expansion for exactly what it is: a solid answer to the location question and nothing more. Before you let "in-country" become "sovereign" in a board paper, split the three questions. Where does the data sit? Who can compel it? Who runs the model? Residency answers the first. For most workloads that is enough and you should take it. For the workloads where the answer to the second and third questions has to be "us," you need to own the runtime, not rent a region.

Frequently asked questions

Does Microsoft 365 Copilot in-country processing make my data sovereign?

No. It makes your data resident. In-country processing controls where Copilot interactions are processed. It does not change who can lawfully compel access to that data, and under the US CLOUD Act a US-based provider can be required to disclose data it controls regardless of the country it is stored in. Sovereignty is a jurisdiction question, not a location question.

Are we legally barred from using cloud AI for regulated data?

Almost never at the regime level. GDPR, the EU AI Act, DORA and the UK FCA and PRA frameworks permit cloud and hyperscaler use with proper controls. The genuine no-cloud bar is workload-specific: classified or SECRET-and-above material, ITAR-controlled data, isolated OT and SCADA systems, and cases where a data protection impact assessment comes back negative. Most of the market runs on sovereignty preference, not a blanket legal prohibition.

When is data residency actually enough?

When your obligation is genuinely about location: data-localisation laws, latency, and sensitive data where a documented controls-based cloud posture is defensible. It stops being enough the moment your threat model includes the provider's home jurisdiction, or you need to prove operational control and system behaviour rather than assert it.

How does owning an air-gapped runtime change the calculation?

When you own and run the model inside your own perimeter, disconnected by design, there is no external provider holding your data to compel, so the foreign lawful-access risk falls away. And with a cryptographically-signed audit record on every action, you can prove what the system did rather than trust someone else's dashboard. That is what we mean by a Sovereign Intelligence Operating System: residency, sovereignty and ownership answered by the same architecture.

Related reading from Mickai: our work on data residency versus data sovereignty, why regulated buyers show a sovereignty preference rather than a blanket cloud ban, and how a cryptographically-signed audit record turns AI actions into evidence.