Every major US AI vendor now has a European answer to the privacy question. OpenAI, Microsoft, Amazon and Google all offer an EU region, and in many procurement processes that closes the discussion.
EU data residency is a vendor's commitment that your data is stored inside the EU and, for some services, processed there as well. It is about where the data sits, not about which law applies to it. A US company with a European data centre remains subject to US law, and that law doesn't care where the server is.
What does EU data residency cover at the major AI vendors?
EU data residency means something different at every vendor, and the difference sits in the fine print on processing. Storage in the EU is covered by all five. The question is where the model processes your prompt.
| Vendor | EU storage | EU processing | What you need to know |
|---|---|---|---|
| OpenAI API | yes | yes, where supported | requires approval and a modified retention amendment |
| Microsoft Azure AI Foundry | yes | only with "Data Zone EU" | the recommended default is "Global Standard" |
| AWS Bedrock | yes | only with an EU inference profile | "Global" profiles route worldwide and cost about 10% less |
| Google Vertex AI | yes | only via EU endpoints | global endpoints carry no residency guarantee |
| Anthropic Claude API | no | no | only "us" and "global"; EU runs via Bedrock or Vertex |
A few details that rarely come up in sales conversations. For any region outside the US, OpenAI requires that you are approved for abuse monitoring controls and sign a Modified Retention amendment, and extended prompt caching can still mean processing outside the region in some regions. Microsoft states in its own documentation on deployment types in Azure AI Foundry that "Global" deployments may be processed in any Azure region, and still recommends starting most workloads on Global Standard. Follow the default, and you're not processing in the EU.
Anthropic's documentation is the most direct: on its own API, only the inference locations "us" and "global" are available.
Where are the exceptions in Microsoft's EU Data Boundary?
Microsoft's EU Data Boundary is the most extensive residency programme on the market, which makes it a good illustration of what keeps flowing under such a programme. Microsoft itself publishes a list of transfers that happen even inside the boundary.
Staff outside the EU can access data remotely, which Microsoft itself classes as a transfer under European privacy law, even though the data stays in a European data centre. Pseudonymised personal data processed for security purposes can go to any Azure region worldwide. Services in preview and free trials aren't covered.
Then there's the example that best shows how residency works. If you allow Anthropic's models inside Microsoft's generative AI services, Microsoft says the data is processed by Anthropic in the United States. Storage stays in the EU. Processing doesn't.
That isn't a hidden trick. It's written down plainly. But it does mean that "we're inside the EU Data Boundary" only tells you something once you know which services, models and settings you use.
Why doesn't EU data residency protect against the CLOUD Act?
EU data residency doesn't protect against the CLOUD Act, because that law looks at who controls the data, not where it sits. Section 2713 of Title 18 of the US Code requires a provider to disclose data within its "possession, custody, or control", "regardless of whether such communication, record, or other information is located within or outside of the United States".
What that means in practice became clear under oath in the French Senate on 10 June 2025. Microsoft France's director of legal affairs was asked whether he could guarantee that French citizens' data would never be handed to the US government without the consent of the French authorities. His answer, according to the official record: "Non, je ne peux pas le garantir, mais, encore une fois, cela ne s'est encore jamais produit." No, he could not guarantee it, though it had never happened.
That it hasn't happened yet is probably true. That it can't be guaranteed is the point.
On the European side sits Article 48 of the GDPR, which only recognises an order from a foreign court or authority when it rests on an international agreement, such as a mutual legal assistance treaty. A vendor can end up caught between two legal systems. As the controller, you're the one who has to explain why you accepted that risk.
Where do the Data Privacy Framework and FISA 702 stand?
The EU-US Data Privacy Framework still stands legally, but it is back before the court. On 3 September 2025, the EU General Court dismissed Latombe's action against the adequacy decision, adding that the Commission may suspend or repeal the decision if the US legal framework changes. An appeal against that ruling is pending as case C-703/25 P, lodged on 31 October 2025.
That US legal framework is meanwhile in motion. Section 702 of FISA, the basis for US surveillance of non-US persons through US providers, expired on 12 June 2026 after Congress passed two short extensions. The surveillance doesn't stop there: according to a Brennan Center analysis of 22 September 2026, the certifications and the directives issued to companies under them remain valid until 17 March 2027.
For a procurement decision, that means the legal basis for transfers exists today, but it is being reviewed by the court while the US regime it rests on is changing. A system meant to last three to five years is better not built on the assumption that this stays as it is. The wider context is in our guide to digital sovereignty and AI in the Netherlands.
What do Dutch regulators say?
Dutch regulators have been explicit about dependence on non-European cloud services since 2026. On 10 July 2026, the ACM, AFM, Dutch Data Protection Authority (AP), DNB and RDI jointly presented the report "De route naar digitale autonomie" (the route to digital autonomy) to the state secretary. DNB summarises it as a call to speed up the transition, framing digital autonomy as freedom of choice and control for organisations that use IT services.
Parliament got there first. In March 2025, the Kathmann motion asked the government to draw up a risk analysis and an exit strategy to Dutch or European suppliers for all cloud services from US tech companies. What government asks of itself, customers and clients will start asking of their suppliers.
Which data can go to an EU region of a US vendor?
Not all data needs the same protection, and an AI policy that bans everything gets worked around. This is the classification we use in projects. It's a starting point, not legal advice, and your sector or client contracts may be stricter.
| Type of data | Example | Where it can run |
|---|---|---|
| Public | marketing copy, public documentation | any vendor, including global processing |
| Internal, no personal data | process descriptions, internal manuals | an EU region with EU processing is usually enough |
| Ordinary personal data | customer correspondence, CRM notes | EU region with EU processing, a processing agreement and a transfer assessment |
| Special category personal data | medical or criminal records, national ID numbers | your own environment, or a European vendor without a non-EU parent |
| Professional secrecy and trade secrets | lawyers' and doctors' files, source code, M&A | your own environment |
The bottom two rows are where EU data residency falls short. The question there isn't whether a US authority is likely to request your data, but whether you can show that it can't. With an open-weight model in your own environment, you can, and quality is no longer a reason not to: the lag of open-weight models behind frontier models is now measured in months. What that takes is covered in our guide to local AI for business. How the GDPR and the AI Act shape it further is in private AI under the GDPR and the EU AI Act.
[ TIME SAVED ]
Save 10 hours per week on working out which AI services and settings process data outside the EU
Which settings should you check if you do use an EU region?
If you choose an EU region of a US vendor for the top three rows, check these points in the configuration itself, not in the sales material:
- The deployment type. In Azure, "Data Zone EU" rather than "Global Standard"; in Bedrock, an EU inference profile rather than "Global"; in Vertex, an EU endpoint rather than the global one.
- Caching and abuse monitoring, and where that data is retained.
- Third-party models inside the platform, such as Anthropic models in Microsoft services, which have their own processing location.
- Preview features and free trials, which often fall outside the residency commitments.
- Who looks in remotely for support, and from which country.
Record the chosen settings in your record of processing activities and check them at every model change. A new model version is sometimes offered globally first. When choosing between vendors, the criteria in choosing a sovereign cloud help, and if you want out, the route is in migrating from cloud AI to local AI.