Copilot, Claude and the EU Data Boundary — What Marketing Won't Tell You About AI in M365
In 2023, Copilot for Microsoft 365 was a near-future promise. In 2024, it became available to enterprise customers. In 2025, Microsoft announced the EU Data Boundary as a solved problem, and Copilot began reaching regulated environments — with assurances that customer data would stay in Europe. In 2026, two developments complicated that picture.
The first is flex routing: a feature that allows Copilot inference to leave the EU Data Boundary during capacity peaks, redirecting it to the United States, Canada, or Australia. For new tenants created after 25 March 2026, this feature is on by default. The second is the integration of Anthropic models. Claude, which became available in Copilot from early 2026, does not run on Azure infrastructure. Inference travels from Azure to Anthropic's servers, operated on AWS and GCP, predominantly in the US.
A compliance team that approved a Copilot deployment based on EU Data Boundary assurances is now looking at a different reality than the one that informed their decision. And this applies not just to new customers. It applies to anyone running or rolling out Copilot who assumed that "EU Data Boundary = EU inference, always."
Why does this matter now? Because Copilot is a qualitatively different kind of application than previous M365 tools. SharePoint and Exchange accessed data when a specific user deliberately searched for something they knew existed. Copilot accesses everything the signed-in user can reach and synthesises it in response to natural-language questions. The volume of data potentially touched by each prompt is incomparably larger — and all of it travels into inference, whether that inference happens in the EU or not.
On top of that, Copilot's architecture has fundamentally shifted. What appeared to be a single AI assistant from a single vendor is now an orchestration layer that can route to different models with different legal realities. Behind one unified Copilot interface in Teams, Word, or Excel, you may get an OpenAI model on Azure, a Claude model on Anthropic's infrastructure, or a Grok model from xAI — depending on which model is active for a given function and how your tenant is configured.
The core thesis of this article is simple: the model is the dependency, not a detail. "We use Copilot" is not an answer to the question "where is our data processed?" That answer depends on which model is running and how it is configured. And that configuration must be part of your governance — deliberately, contractually, and with audit trails — not assumed from the platform's default state.
Copilot as a Platform, Model as a Dependency
Microsoft is positioning Copilot as a model-agnostic platform. In practice, this means that behind a single Copilot interface, multiple models can be active with different processors, different data handling terms, and different inference geographies.
As of June 2026, M365 Copilot can involve three groups of models with distinct legal realities:
Model | Inference Processor | EU Data Boundary Coverage | Default for EU/EFTA/UK |
|---|---|---|---|
OpenAI (GPT-4o and others) | Microsoft / Azure OpenAI | Yes | Yes — enabled |
Claude (Anthropic) | Anthropic (AWS/GCP, predominantly US) | No | No — requires explicit admin opt-in |
Grok (xAI) | xAI infrastructure | No | Depends on configuration |
Through a single unified UI, Copilot can therefore send data to three different processors in three different jurisdictions — depending on which model is active, set as default, or selected by the user.
Microsoft itself acknowledges this distinction: for Azure OpenAI, it controls both the runtime and the data boundary directly. For Anthropic, it integrates as a subprocessor, but inference does not happen on Azure infrastructure — it happens on Anthropic's servers. Your governance framework must reflect this difference.
What the EU Data Boundary Actually Covers
The EU Data Boundary (EUDB) is Microsoft's commitment that EU and EFTA customer data will be stored and processed within the EU/EFTA region. It covers data at rest — the contents of mailboxes, SharePoint documents, Teams messages, and other M365 data — encrypted transit within the EU/EFTA zone, and OpenAI model inference running in EU Azure regions.
What EUDB does not cover, or covers only partially: web search grounding via Bing (queries may leave the EUDB), limited pseudonymised diagnostic data used for security and operational purposes, inference on third-party models (Anthropic, Grok) when enabled, and inference itself when flex routing is active during capacity peaks.
The EUDB is therefore not absolute data isolation. It is a contractual framework covering a large portion of the data flow, but not the full technology stack running under Copilot.
Where the EUDB Cracks — Flex Routing and Anthropic
Flex Routing
Flex routing is a feature that allows Copilot's LLM inference to leave the EU Data Boundary during capacity peaks, redirecting it to the United States, Canada, or Australia.
Key facts for administrators: flex routing is on by default for new tenants created after 25 March 2026. For older tenants, status depends on your configuration — check your tenant's Message Center. Data at rest remains within the EUDB even when flex routing is active; it is the inference process itself that may leave the EU. An administrator can disable flex routing at any time in the Microsoft 365 admin centre or Power Platform admin centre.
When flex routing is on without the administrator's awareness, an organisation relying on the EUDB as the foundation of its compliance posture may be unknowingly sending AI inference outside the EU. For regulated entities — financial institutions under DORA, healthcare organisations, critical infrastructure operators under NIS2 — this can have direct compliance implications.
Anthropic as a Subprocessor
In January 2026, Anthropic entered the Microsoft product framework as a subprocessor. On the surface, this sounds reassuring: Anthropic is bound by Microsoft's Product Terms and DPA, and does not use customer data for model training. The problem lies elsewhere: Claude model inference does not run on Azure. Data is transferred from Azure to Anthropic's infrastructure on AWS or GCP, predominantly in the US.
A timeline of key changes:
January 2026 — Anthropic becomes a Microsoft subprocessor
3 April 2026 — Microsoft introduces a new admin setting to enable Anthropic as the default model for EU/EFTA/UK tenants
1 May 2026 — Anthropic independent processor path decommissioned; organisations that had not enabled Anthropic as a subprocessor by this date lost access to Claude models in Copilot
Current status for EU/EFTA/UK: Claude models are disabled by default in these regions. This is the correct default from a compliance standpoint. If an administrator deliberately enables them, data begins leaving the EUDB. The organisation then needs to assess whether the transfer of data to the US is consistent with its DPIA and a Transfer Impact Assessment (TIA), ensure Standard Contractual Clauses (SCC) are in place — Anthropic sits within the Microsoft DPA, but SCCs for the US as a third country are still required — and explicitly decide for which use cases and user groups they are enabling Claude.
Data Localisation in the EU Is Not Data Sovereignty — CLOUD Act and FISA
Storing data in the EU does not mean sovereignty over that data. This is the single most important sentence in this article.
The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, US 2018) allows American law enforcement agencies to compel US-based providers to disclose data regardless of where it is physically stored. Microsoft, OpenAI, Anthropic, and AWS are all US companies. A European headquarters or European datacentre does not eliminate this authority.
FISA Section 702 (Foreign Intelligence Surveillance Act) goes further still, allowing US intelligence agencies to collect foreign intelligence on non-US persons outside the United States without a case-specific warrant.
An important point of context: this is not a problem specific to Copilot or Microsoft 365. It applies to the entire US hyperscaler stack — Azure, AWS, and Google Cloud alike. AI and Copilot did not create this reality, but they make it more consequential by enabling an AI assistant to access a vastly broader set of organisational data than traditional applications did.
Available tools reduce this risk but do not eliminate it:
Tool | What It Reduces | What It Does Not Eliminate |
|---|---|---|
Customer Managed Keys (CMK) | Microsoft's access to stored content | US government jurisdictional authority |
Customer Lockbox | Microsoft support access to data | US intelligence agency powers |
EU Data Boundary | Geography of routine processing | CLOUD Act, FISA 702 |
Sovereign cloud (GCC High) | Some US government entity access | Full frontier model availability (not yet) |
Compliance teams must name this context in their DPIAs and TIAs and consciously accept it as residual risk — or choose alternatives outside the US hyperscaler stack.
The Biggest Security Risk Is Oversharing, Not a Technical Vulnerability
The most significant security risk from Copilot is not a technical vulnerability or a choice of model provider. It is oversharing — years of accumulated access rights that existed but caused no visible harm because no one was actively using them.
Copilot respects existing M365 permissions. It sees what the signed-in user sees: SharePoint documents, Teams conversations, Exchange mail, OneDrive files. But where a user previously had to know what to look for, one prompt is now enough: "What do we know about project XYZ?" or "Summarise all leadership decisions from the last twelve months."
The mosaic effect: Copilot can synthesise information from multiple sources that a user has individual access to, but whose combination produces output more sensitive than any single fragment. This is not a flaw in Copilot's security design — it is exactly what an AI assistant is supposed to do. The problem is misconfigured access rights.
Concrete risks include SharePoint sites with "everyone" access or excessively broad permissions, legacy project sites accessible to employees who left those projects long ago, HR or financial documents on SharePoint without properly scoped access, and AI-generated content that may or may not inherit sensitivity labels from source documents depending on whether label inheritance has been explicitly configured.
The key steps before deploying Copilot, in priority order: enable Restricted SharePoint Search to limit Copilot indexing to explicitly approved sites; deploy SharePoint Advanced Management for granular access control; review or implement sensitivity labels and DLP policies in Microsoft Purview; clean up SharePoint access rights. None of these steps should happen after deployment.
Cost Governance — The Risk Nobody Talks About
Microsoft is moving to a credit model (Copilot Credits) for part of its AI functionality. Consumption-based billing for agents includes charges for model inference, retrieval operations, tool calls, and runtime. Unlike traditional SaaS licensing, AI consumption is a variable cost.
This means AI costs cannot be managed as a one-time licensing decision. They require ongoing cost monitoring through Azure Cost Management and Power Platform Analytics, spending limits per user or per agent, and regular usage reviews.
Bundling into higher-tier licence packages (E7 "Frontier" and their equivalents) creates another dilemma: your organisation pays for a bundle that includes models or features with worse compliance characteristics than you need or are permitted to use. This is a contractual reality worth understanding before signing an Enterprise Agreement amendment.
Agent Governance
Copilot Studio enables building custom agents that act on behalf of users across mail, files, Teams, and other systems. Each agent has a configured model — the default is OpenAI, but Claude and Grok are available for administrators to enable explicitly.
Key governance considerations for agents:
Model per agent: Third-party models like Claude or Grok must be enabled by an administrator in the Power Platform Admin Center. Permissions can be scoped to specific Entra groups — for example, enabling Claude only for the development team while restricting it for HR or finance.
Audit logging: An agent acts on behalf of the user with that user's permissions — it creates documents, sends mail, and accesses files. Without an audit trail of agent actions, neither accountability nor incident response is possible. Microsoft Purview audit logging for agent actions is available but requires deliberate configuration. E5 licences are better equipped for advanced audit and compliance scenarios.
Telemetry by model per request: It is worth knowing which model handled each agent request — both for compliance reporting and for troubleshooting. This logging is not automatic in the default state.
Label inheritance: When an agent creates new documents based on existing ones, there must be a policy governing how sensitivity labels are transferred to AI-generated content. Without explicit configuration, documents may be generated without labels or with incorrect ones.
Process-level allowlists: Processes that contractually or regulatorily cannot use third-party models — HR data, financial reports, M&A communications — should be explicitly tagged and technically enforced to route only to models within the EU Data Boundary.
Direct Deployment for Greater Control Over Your Data
For organisations that need more control over where and how AI inference runs, three paths exist with different trade-offs.
Azure OpenAI and Foundry Models Sold by Azure
When deploying directly through Azure OpenAI or as a Foundry Model sold by Azure, three deployment types are available from a data residency perspective:
Deployment Type | Residency Guarantee | Suitable For |
|---|---|---|
Global Standard | None — inference goes to nearest available capacity | Development, testing |
DataZone Standard (EU) | Inference stays within the EU/EFTA zone | Most EU production deployments |
Regional (e.g., Sweden Central) | Inference stays in a specific region | Strictest residency requirements |
The default deployment for new Azure OpenAI resources is Global Standard. EU residency requires an explicit choice of DataZone or Regional — nothing happens automatically.
Zero Data Retention (ZDR): Azure OpenAI retains data for abuse monitoring for 30 days by default. For sensitive production workloads, you can request modified abuse monitoring that eliminates this retention period. ZDR is not a self-service portal setting — it requires a formal request to Microsoft and is available only to customers with an Enterprise Agreement or Microsoft Customer Agreement. Without approved ZDR, the 30-day retention applies even to data you consider most sensitive.
Network isolation via Private Link and VNet injection is available and recommended for production deployments handling sensitive data.
Claude via AWS Bedrock or Vertex AI
Claude models in Azure AI Foundry do not provide EU data residency today: even when deployed in the Sweden Central region, inference runs on Anthropic's infrastructure. EU support in Azure AI Foundry is listed as "Coming 2026" without a specific date.
If EU residency for Claude is a hard requirement, the available alternatives are AWS Bedrock with EU regions — Frankfurt (eu-central-1), Ireland (eu-west-1), Stockholm (eu-north-1) — and Google Cloud Vertex AI with EU regions. Both provide Claude model inference within the EU along with contractual data localisation guarantees.
Open-Weight Models for Maximum Control
For sovereign environments or critical infrastructure entities where frontier models are unavailable or unacceptable, self-hosted open-weight models are an option: Llama, Mistral, Microsoft Phi, or the MAI model family. These can be operated on Azure Local or managed compute without dependency on an external API.
The real trade-off: open-weight models currently lag behind frontier models like GPT-4o or Claude Sonnet in several scenarios — particularly complex reasoning and code generation. This is a deliberate choice of sovereignty over capability, one that needs to be named and accepted, not quietly avoided.
Sovereign and Critical Infrastructure Environments
For entities in government or sovereign clouds, different rules apply. These environments do not have access to frontier models in full: Claude is not available at all, and the latest GPT versions arrive with a delay or reduced functionality.
For critical infrastructure operators and regulated sectors under NIS2, the picture is similar: operating in an isolated environment or with strict data sovereignty requirements means that parts of Copilot's functionality are simply not available without an acceptable compliance posture. This is a real trade-off that must be surfaced during deployment planning.
Governance Checklist
1. Map your AI workloads and tag critical processes. Identify processes and data that must not leave the EU or reach a third-party model. Tag them explicitly and design technical enforcement.
2. Check the flex routing setting in your tenant. For tenants created after 25 March 2026, flex routing is on by default. For older tenants, check your Message Center. Make a conscious decision about whether to leave it on or turn it off.
3. Define your Anthropic / Claude policy. Claude is off by default for EU/EFTA/UK. If you intend to enable it, define a per-group policy in the Power Platform Admin Center and document the decision as part of your DPIA.
4. Secure residency, training exclusion, and retention as contractual terms. Marketing pages and FAQs are not enough. Require these commitments in your DPA and Product Terms, and for sensitive Azure OpenAI workloads, request ZDR through your EA or MCA.
5. Conduct a DPIA and Transfer Impact Assessment. The US is a third country for GDPR purposes without an adequacy decision (except under the Data Privacy Framework). A TIA is mandatory for transfers to US subprocessors, including Anthropic.
6. Configure per-model policy in the admin centre. Recommended baseline: OpenAI within EUDB enabled, Claude as a governed opt-in per Entra group. Document this state and review it regularly.
7. Address oversharing before deploying Copilot. Restricted SharePoint Search, SharePoint Advanced Management, access right remediation. Do this before, not after.
8. Implement audit logging for agent actions. Microsoft Purview audit for agents, provider and model telemetry per request, label inheritance policy for AI-generated content.
9. Include AI costs in your variable OPEX monitoring. Cost Management spending limits, per-user and per-agent usage caps, regular review cycles.
10. Pilot OpenAI versus Claude on representative prompts. Before enabling Claude in production, test both models against your specific scenarios with measurable metrics: accuracy, hallucination rate, latency, cost, and data exposure surface.
Copilot as a Platform, Model as a Governance Decision
Microsoft is building a model-agnostic orchestration platform. Vendor lock-in is shifting from the AI model itself to the Copilot platform and the M365 ecosystem. This is a commercially rational strategy — but it puts compliance teams in a position where governance must be dynamic. Things change on a timescale of weeks, not years.
The EU Data Boundary is a real contractual framework that covers a large portion of the data flow. It is not absolute sovereignty, and in combination with flex routing, Anthropic integration, and US jurisdictional authority over American companies, it is not sufficient as a single compliance answer.
The main point: with AI in M365, govern explicitly which model processes which data. The platform's default state is optimised for usability, not compliance. Governance must be deliberate, contractual, and auditable.
If you need help assessing your M365 AI compliance posture or establishing model governance policies, we are happy to help.
We help organisations with AI governance assessments, DPIAs for AI systems, model policy configuration in M365, and selecting the right deployment model for regulated environments. The initial consultation is free. We respond within 24 hours.