Sovereignty is decided per model, not per platform

"Does this run in Europe?" The question turns up in every second architecture workshop, usually from the data protection officer, usually once the prototype already exists. I spent a long time trying to answer it in one sentence. It cannot be done, because three questions are hiding inside it, and they have different answers.

One thing first: this is not legal advice. It is the view of someone who builds these systems, and the binding assessment of your case sits with your legal department.

Three questions that only add up together

The first is contractual. Under whose terms is the processing happening? The Microsoft Product Terms and the Data Protection Addendum, or a third party's own agreement?

The second is geographic. Where does inferencing actually run? Not where the data rests, but where the computation happens.

The third is operational. Who can reach the system in day-to-day operations, and is that access logged?

These three do not move together. A model can be fully covered contractually and still process outside the EU Data Boundary. That case has been documented reality at Microsoft since January 2026, and it is why I treat model choice as a governance decision rather than a developer decision.

The newest model is never the most sovereign one

In Microsoft Foundry the processing location is set by the deployment type. GlobalStandard processes in any Azure region, DataZoneStandard inside the zone (US, EU, and since this summer APAC), Standard only in the region of your deployment. Data at rest stays in your Azure geography in every case. This is purely about inferencing.

The sentence on Microsoft Learn that I consider the most important on the page: new deployment types arrive in a fixed order, global first, then data zone, then single region. And single-region types have no committed availability date, because they depend on capacity that frees up as older models retire.

That is not an oversight and not a backlog that gets cleared eventually. It is the design. If you want the strongest available model, you take it as a global deployment, which means worldwide processing. If you require the EU data zone, you are structurally working with the previous generation.

The trade-off belongs in the architecture decision, before anyone writes a prompt. It can be enforced: Azure Policy blocks deployments by SKU name, and GlobalStandard is exactly such a SKU name. Five lines in a policy definition, and you never have to ask why environment X is suddenly computing globally.

Since 1 September there is a price tag

Until recently, sovereignty in Foundry was mostly a question of availability. Since 1 September 2026 it is also a line in the cost model. Microsoft adjusted pricing for data zone and regional deployments outside the US: global stays as it was, the EU data zone sits nine per cent above it, regional deployments outside the US seven to sixteen per cent, the new APAC zone twenty.

Nine per cent sounds small. Work it out anyway, against the forecast annual volume rather than the pilot month. In the cost models I see, the premium is not the problem. The problem is that it appears in no business case, because the residency decision is taken after the budget has been signed off.

Contractually clean, geographically outside

The partner models are the interesting case. Anthropic has been a Microsoft subprocessor since 7 January 2026. The Product Terms, the DPA and the Customer Copyright Commitment therefore apply to Claude inside Microsoft 365 Copilot and Copilot Studio. The earlier route through separate Anthropic terms has been retired. Contractually that is a clear improvement, and procurement has less work.

Except the same documentation carries the qualifier: Anthropic models sit outside the EU Data Boundary and outside the in-country commitments for LLM processing. Microsoft states it again separately for Copilot Studio. The same pattern holds in Foundry, where Claude models are served through global or data zone options and no European data zone exists for them so far.

Contract status and processing location are two switches, not one. If your legal department ticks off the subprocessor evidence and concludes that processing happens in Europe, the review took a wrong turn at exactly that point.

One step further out sit providers who are not subprocessors at all. For xAI, Microsoft states explicitly that processing occurs outside all Microsoft-managed environments and audit controls, and that the Product Terms, the DPA, residency commitments, service level agreements and the Customer Copyright Commitment do not apply. In Copilot Studio those models are available to US tenants only anyway. The model picker looks like a list of comparable options. Legally it holds three different categories.

The switch you did not flip yourself

Flex routing lets LLM inferencing for EU and EFTA customers run outside the EU Data Boundary during peak demand, specifically in the United States, Canada or Australia. Data at rest stays inside the boundary, apart from limited pseudonymised data kept outside for security and operational purposes.

The point the product pages do not emphasise: for tenants created after 25 March 2026, flex routing is on by default. Existing tenants received their setting through the Message Center. If you spun up a fresh tenant for a new subsidiary, a carve-out or a demo environment, this is your case.

Two places control it. The Microsoft 365 admin centre covers Copilot and Copilot Chat, the Power Platform admin centre covers Dynamics 365, Power Platform and Copilot Studio. The Power Platform setting follows the Microsoft 365 one unless it is more restrictive. And organisations that purchased or used Multi-Geo are not in scope for the EU Data Boundary for Microsoft 365 in the first place, so the setting does not appear there.

Check the value instead of assuming it. It takes two minutes and belongs in the same file as your disclosure evidence.

When the data boundary is not enough

For cases where even the EU data zone falls short, the Sovereign Private Cloud has been available since February 2026: Azure Local, Microsoft 365 Local and Foundry Local, running on your own hardware, fully disconnected if required. Foundry Local runs there as an Arc extension on Kubernetes, since June across multiple nodes and optionally on vLLM instead of ONNX Runtime GenAI.

It is a serious option, and it costs you three things: model choice, the operational effort of running your own inference platform, and the release cadence of the cloud. Take this route for bounded processes, not for the whole organisation.

The contradiction I cannot resolve

Microsoft commits to processing in Europe, to access approval by Europe-resident personnel through Data Guardian, and to customer-held keys through External Key Management. Those are real, auditable controls. They do not change extraterritorial access under the US CLOUD Act, and none of the commitments claims otherwise. How heavily that residual risk weighs is a judgement call, not a technical question. I name it openly rather than define it away, because an architecture that does define it away protects nobody later.

What I recommend

1. Classify per use case, not per platform. One tenant can run global deployments for uncritical summarisation and data zone deployments for personal data at the same time.
2. Record three fields for every agent: contractual basis, processing location, access model. Three columns in the inventory you need anyway.
3. Enforce the processing location through Azure Policy on the SKU name instead of describing it in a guideline.
4. Check flex routing in both admin centres and record the result with a date.
5. Treat model choice as a change that needs approval. Switching a model in the picker can move the processing location without a single line of code being touched.

The last one is the point I most often have to add afterwards. On these platforms, sovereignty is not a property you buy once. It is a property of each individual model assignment, and it can change while your system runs unchanged.

What I cannot judge yet

Whether an EU data zone is coming for partner models, and when. There is no commitment I could cite, only questions in the forums.

And whether the nine per cent premium holds. It was announced in July and took effect on 1 September, and a second data point is missing.

Sources

• Deployment types for Microsoft Foundry Models, Microsoft Learn, as of 6 August 2026. Order of deployment types, data residency per type, Azure Policy sample.
• Microsoft Foundry Model Deployment Pricing Update, Microsoft Community Hub, 27 July 2026. Pricing change effective 1 September 2026.
• Flex routing (EU and EFTA), Microsoft Learn, as of 5 May 2026. Default for tenants created after 25 March 2026, target regions, interaction between the two admin centres.
• Data, Privacy, and Security for Microsoft 365 Copilot, Microsoft Learn. Anthropic models outside the EU Data Boundary and the in-country commitments.
• Anthropic as a subprocessor for Microsoft Online Services, Microsoft Learn. Subprocessor status since 7 January 2026, scope of Product Terms, DPA and Customer Copyright Commitment.
• Allow external large language models for generative responses, Microsoft Learn. Exclusion from EU Data Boundary commitments for Copilot Studio, xAI for US tenants only.
• What is the EU Data Boundary?, Microsoft Learn. Scope rules, exclusion of Multi-Geo customers.
• What is Foundry Local on Azure Local?, Microsoft Learn. Arc extension, engines, disconnected operation.
• What's New in Microsoft Foundry, June 2026, Microsoft Foundry Blog, 7 July 2026. Multi-node and vLLM for Foundry Local on Azure Local.
• Microsoft Sovereign Cloud adds governance, productivity and support for large AI models, Official Microsoft Blog, 24 February 2026. Sovereign Private Cloud, disconnected operations.