People often use “EU data residency” and “sovereignty” as if they meant the same thing. They don’t, and for Claude the difference matters a lot right now.
EU data residency is mainly about where processing and storage happen. “Sovereignty” is broader and is used to cover combinations of operational control, jurisdiction, personnel, supply chain and data-location requirements. Today you can run supported Claude models with EU processing residency controls, but not on an EU-operated sovereign cloud. As of 29 September 2026, I could not find a public announcement of Claude on the AWS European Sovereign Cloud or another EU-operated sovereign cloud.
If sovereignty is a hard requirement, the first job is to unpack what that word means in your organisation. A residency requirement, an EU-operator requirement and a legal-jurisdiction requirement lead to different architectures.
One word, three different requirements
When someone asks for “sovereign AI”, they usually mean one of three things. Each needs a different answer, so it’s worth finding out which one your customer, regulator or works council actually means.
| Requirement | The question it asks | Claude on Amazon Bedrock in EU Regions | AWS European Sovereign Cloud |
|---|---|---|---|
| Data residency | Where is my data processed and stored? | Yes, for supported models called from an EU Region | Yes, entirely within the EU |
| Operational sovereignty | Who runs the infrastructure, and who can access it? | AWS runs it; Anthropic has no access to the inference infrastructure | Only EU-resident AWS employees run day-to-day operations |
| Legal sovereignty | Whose law can compel access to the data? | AWS is a US company, so US law is part of the analysis | AWS cites legal protections, but it’s still part of Amazon, and how much that changes is debated |
| Available for Claude | Yes | No, not as of 29 September 2026 |
Sources: AWS Security blog, Anthropic: Claude in Amazon Bedrock.
The legal row is where most of the debate happens. Commercial EU Regions are run by a US company, so organisations back up EU processing with contracts. AWS points to its Data Processing Addendum and its certification under the EU-US Data Privacy Framework (AWS Alps blog). Whether that’s enough is a legal question for your counsel and DPO, not a technical one.
The AWS European Sovereign Cloud today
AWS describes the European Sovereign Cloud as an independent cloud located entirely within the EU. Only AWS employees who live in the EU control day-to-day operations, including data centre access, support and customer service (AWS Security blog).
Amazon Bedrock is available there, but the choice of models is small. In September 2026, AWS announced the first open-weight model family on Bedrock in the Sovereign Cloud: Google’s Gemma 4, served through the bedrock-mantle endpoint (AWS Security blog). That announcement covers open-weight models only. Claude isn’t part of it.
It’s worth keeping an eye on. Bedrock in the Sovereign Cloud uses the same bedrock-mantle endpoint that serves newer Claude models in commercial Regions, so Claude there is technically plausible. But neither AWS nor Anthropic has announced it, so I wouldn’t plan a project around it.
Other ways to run Claude in Europe
Outside AWS there are three other routes. Only one of them gives you EU residency, and none of them gives you sovereignty.
Google Cloud offers EU residency. Anthropic documents EU multi-region endpoints, which route requests within the European Union, as well as regional endpoints tied to a specific Region (Anthropic: Claude on Google Cloud). Google is also a US company, so the legal picture is the same as for AWS.
Microsoft Foundry doesn’t offer EU processing for Claude yet. Claude can be hosted on Azure, but only in the Global Standard and US Data Zone Standard deployment types (Anthropic: Claude in Microsoft Foundry). Anthropic operates the inference and is the data processor (Anthropic: Claude in Microsoft Foundry is now generally available). This may change, so check Anthropic’s documentation for an EU data zone before ruling it out.
Anthropic direct does not currently give you an EU-only processing control. Anthropic says its global routing may process traffic in select countries in Europe, but the first-party platform does not let you constrain commercial inference to Europe in the same way Bedrock or Google Cloud EU endpoints do. Anthropic also states that commercial-product data is stored in the US (Anthropic: Data residency).
Sovereign partner clouds and on-premises setups aren’t options for Claude today. I found no public announcement of Claude on EU sovereign partner clouds, such as those run by Thales, Orange or SAP subsidiaries, and Claude can’t be self-hosted. If a workload has to run fully sovereign or disconnected, open-weight models are the realistic choice for now.
The options side by side
| Option | Claude available | EU processing | Who operates inference | Sovereign operations |
|---|---|---|---|---|
| Amazon Bedrock, EU Regions | Yes | Yes, for supported models called from an EU Region | AWS | No |
| Google Cloud, EU endpoints | Yes | Yes, regional or EU multi-region endpoints | No | |
| Microsoft Foundry | Yes | No, Global or US Data Zone only | Anthropic | No |
| Claude Platform on AWS | Yes | No, US or Global only | Anthropic | No |
| Anthropic API directly | Yes | No EU-only control. Global routing may include Europe, but cannot be restricted to Europe; stored commercial data remains in the US. | Anthropic | No |
| AWS European Sovereign Cloud | No | Yes | AWS, EU-resident staff | Yes |
| Other EU sovereign clouds | No announcement found | Yes | EU operator | Yes |
Put simply, every route that offers Claude lacks sovereign operations, and every sovereign route lacks Claude.
Who actually needs sovereignty?
Sovereignty is a real requirement, but it is not one single technical control. Some organisations need EU processing only; others also care about who operates the infrastructure or which legal regimes can compel access.
Examples where stronger sovereignty requirements can arise include:
- Public sector or regulated procurements that explicitly require EU-operated infrastructure.
- Defence, classified work and parts of critical infrastructure.
- Professional-secrecy or sector-specific cases where counsel concludes that a US-owned operator is not acceptable.
- Customer, works council or contractual requirements that rule out particular providers or jurisdictions.
For everyone else, don’t assume either way. Start with the written requirement and have counsel and the DPO decide which safeguards are acceptable.
- AWS publishes contractual and transfer mechanisms for its commercial EU Regions, including its Data Processing Addendum and participation in the EU-US Data Privacy Framework. Whether those mechanisms are sufficient for a particular workload is a legal decision, not an architecture decision.
The question I ask customers is simple: is your requirement about where the data is, or about who could be forced to hand it over? The first has a Claude answer today. The second doesn’t, yet.
What to do if you need both
You don’t have to pick one model for everything. In practice, the answer is to split workloads by what they require.
- Classify workloads first. Work out which ones need sovereign operations and which need an EU processing residency control. You may find that different workloads need different answers.
- Run the sovereign workloads on a sovereign cloud. Today that means open-weight models, such as Gemma 4 on Bedrock in the AWS European Sovereign Cloud.
- Run everything else on Claude with EU residency, using Bedrock or Google Cloud in EU Regions, with IAM controls and CloudTrail evidence.
- Reduce what crosses the line. Where the use case allows, pseudonymise or remove personal data before it reaches the model.
- Keep the architecture portable. Put model calls behind one internal interface, so moving a workload to Claude on a sovereign cloud is a configuration change if that option ever appears.
Working out whether the requirement is residency or sovereignty?
Wolkn Minds can map the technical options and controls. Your DPO and counsel make the legal call; our job is to make the architecture and evidence clear enough for them to do that.
Sources
- AWS Security blog: Run open-weight models on Amazon Bedrock in the AWS European Sovereign Cloud
- AWS Alps blog: Cross-Region inference for EU data processing
- Anthropic: Claude in Amazon Bedrock
- Anthropic: Claude on Google Cloud
- Anthropic: Claude in Microsoft Foundry
- Anthropic: Claude in Microsoft Foundry is now generally available
- Anthropic: Data residency
