EU Residency: Anthropic, OpenAI, Copilot, and Azure Compared
None of the four paths give EU residency by default. Anthropic requires Bedrock or Vertex AI in an EU region, OpenAI a new tenant or new EU project, GitHub Copilot ghe.com with an activated residency policy, and Azure a DataZone or Standard SKU. All four are ultimately under US jurisdiction – the choice hinges on which residual risk you can document.
Four paths dominate when Swedish organizations buy generative AI: Anthropic and OpenAI directly, GitHub Copilot for development, and Azure AI Foundry as a platform. Placed side by side, a pattern emerges that simplifies the whole evaluation: none of them give EU residency by default. Residency is always something you configure and contract for. That makes the comparison simpler than it looks: the question isn’t who promises the most, but what each path requires of you.
Requirements per vendor
| Vendor path | Requirement for EU residency |
|---|---|
| Anthropic (Claude) | AWS Bedrock or Vertex AI in an EU region – its own API has no EU option |
| OpenAI | New Enterprise tenant or new EU project, plus an approved monitoring tier |
| GitHub Copilot | Enterprise Cloud on ghe.com plus an activated residency policy |
| Azure AI Foundry | DataZone or Standard deployment – Global is the default |
Four different mechanisms, one principle: residency is configuration-dependent, not a product name. Whoever asks “does the vendor have EU residency?” always gets the answer “yes” – whoever asks “which configuration does it require, and do we have it?” gets the answer that actually means something.
The table also hides an important similarity: in all four cases, the simplest and cheapest option is the one that doesn’t keep data in the EU. Residency costs money, migration, or configuration work – which is exactly why it’s so often missing when no one has explicitly owned the question.
Storage isn’t inference
The next layer of the comparison is what the residency actually covers, and that’s where the paths diverge:
- OpenAI: EU residency covers storage and GPU inference on new tenants, but authentication, routing, indexing, and analytics can sit outside the region, and certain endpoints are exempted.
- Copilot: residency stands or falls with the model policy – if it’s off, Copilot data leaves the region, and telemetry and billing sit in the US regardless.
- Azure AI Foundry: coverage depends on deployment type per model; Global deployment leaves the EU even from EU resources.
- Claude via a hyperscaler: processing happens in the region you choose, but surrounding services follow the hyperscaler’s terms and need to be reviewed separately.
The question to ask is always the same: where does storage happen, where does transit go, and where does inference run – for our exact SKU, tier, and model? The differences above aren’t arguments against any single path – they’re a reminder that coverage gets verified link by link, not by brand.
All four are ultimately under US jurisdiction
Anthropic, OpenAI, GitHub, and Microsoft are US companies, and so are the hyperscalers. The CLOUD Act reaches them all. The exposure can be mitigated – customer-controlled keys, zero data retention, EU tenants – but not eliminated.
That changes how the comparison should be read. The choice isn’t about finding a risk-free option, because there isn’t one among the four. It’s about which residual risk you can best document, mitigate, and defend to an auditor. A well-substantiated DPIA with clear mitigations beats an optimistic status summary every time. Also keep two tracks separate in the documentation: the transfer mechanism that makes the processing lawful, and the mitigations that reduce the practical risk. An auditor wants to see both, and they answer different questions.
How to use the comparison
A concrete example: an organization with an Azure environment and a developer team wants both Copilot and an internal AI assistant. The path choice becomes ghe.com with an activated model policy for Copilot, and Foundry with DataZone deployment for the assistant. The US flows – telemetry, billing, secret scanning – get documented as residual transfers. Two decisions, one coherent set of documentation.
The workflow in four steps:
- Start from the use case and your existing cloud – they decide which paths are realistic.
- List, per candidate, what the residency covers: storage, transit, inference.
- Require written confirmation per SKU, tier, and model at the time of contracting.
- Date the record and reassess at every model upgrade.
Residency terms change continuously – a comparison like this one is a map, not a final answer. The dated written statement at the time of contracting is what holds up under audit. And the earlier the requirements get set, the cheaper they are: a residency column in the procurement template costs nothing, while a migration after the fact costs months. Want help turning the map into an actual path choice for your AI initiative? Get in touch and we’ll take it from there.
Frequently asked questions
Which AI provider is safest from a GDPR perspective?
None of them is risk-free, and all four can be configured correctly. The best candidate is the one whose residual risk you can best document and defend – which is often driven by your existing cloud, your expertise, and your use case rather than by the vendor's brochure.
Does EU residency cost extra?
Often, in the form of a price premium, a higher product tier, or a more expensive SKU. The tiers change continuously, so calculate the total cost with current price lists rather than relying on old figures – and weigh the premium against the cost of documenting a worse alternative.
Does EU residency mean the CLOUD Act doesn't apply?
No. All four paths are ultimately under US jurisdiction, and the CLOUD Act follows along regardless of region. Residency reduces exposure and improves your documentation, but the residual risk still needs to be managed with mitigations and reported in the DPIA.
What should a written residency confirmation contain?
Where storage, transit, and inference happen – for the exact SKU, tier, and model you're buying – plus a date and who provided the statement. General marketing language isn't sufficient evidence in an audit.
How often do we need to reassess the vendor choice?
At every model upgrade and material change in terms, plus as an annual routine. Residency terms are configuration-dependent and change continuously, so a dated reassessment is part of ongoing management – not a one-time task at procurement.