LLM data residency in Europe means the inference ran on hardware in a named EEA location, under a contract that keeps the payload out of foreign legal reach. Residency is a property of the request path, not the marketing page. Sovereignty is the harder question: whether the operator can be compelled to hand your prompts to a non-EU government.
One EU gateway vendor now publishes 1,200+ EU customers, zero data retention and an 8ms latency figure on a Frankfurt-hosted endpoint at ([Requesty's EU gateway](https://www.requesty.ai/eu)). Meanwhile, as of August 2026, the Claude API'sinference_geo` parameter still only supports US — a reminder that "EU residency" is per-provider, per-endpoint, and changes quarterly (CelestInfo's provider-by-region matrix).
Key takeaways
- Residency = the compute location for that request. It is verifiable from response headers and logs, not from a trust page.
- GDPR Chapter V treats an API call that leaves the EEA as a transfer, even if nothing is stored.
- The EU AI Act adds logging and traceability duties on top of GDPR — they are not substitutes.
- Hyperscaler EU regions and European sovereign clouds solve different problems. Pick by threat model, not by flag count.
- If you handle PHI, residency and BAA coverage are separate questions with separate answers.
What does "EU data residency" actually mean for LLMs in 2026?
Residency means the inference executed in a named jurisdiction. For an LLM that is three separable things: where the model weights run, where the prompt and completion are transiently held in memory, and where any logs, caches or abuse-monitoring copies land. A vendor can satisfy the first and fail the other two.
The practical test is boring. Send a request, read the response headers, and check whether the region identifier matches what the contract says. If the vendor cannot tell you the region per request, you have a policy, not a control.
There is a second distinction that matters more than most teams expect. Residency answers "where did it run." Sovereignty answers "who can compel the operator to disclose it." A European region operated by a US-headquartered parent is resident in the EU and potentially reachable by US process. Both matter, and they are covered separately below.
How does GDPR Chapter V apply to LLM data flows and inference?
Chapter V applies to any processing that involves transferring personal data to a third country or an international organisation — and a prompt containing personal data sent to an endpoint outside the EEA is a transfer at the moment of transmission, regardless of whether the provider stores it. Transience is not a defence.
That framing catches people out. Teams assume "zero retention" equals "no transfer." It doesn't. Zero retention removes the storage risk; it doesn't remove the transfer. You still need a Chapter V mechanism — an adequacy decision, Standard Contractual Clauses plus a transfer impact assessment, or derogations that rarely fit production systems.
The EU-US Data Privacy Framework has been in force since July 2023 and gives an adequacy route for certified US recipients. It has survived its first years, but it is litigation-exposed, and treating it as permanent architecture is a bet. If your DPO's risk appetite is low, design so the transfer doesn't happen rather than so the transfer is papered.
For Swiss personal data, the equivalent regime is the nFADP, with its own adequacy list — Switzerland recognises the EU, and the EU recognises Switzerland. A Swiss-EU flow is generally not a Chapter V problem. A Swiss-US flow is.
What are the data residency requirements under the EU AI Act?
The AI Act does not contain a residency requirement as such. It imposes documentation, logging, human-oversight and post-market monitoring duties that are much easier to satisfy when inference happens in-region — which is why residency keeps getting described as an "AI Act requirement" when it is really a GDPR-plus-engineering answer.
The timeline, as written: prohibitions applied from February 2025, general-purpose AI obligations from August 2025, and the high-risk obligations for Annex III systems from August 2026. If you are deploying an LLM into a high-risk use case, the logging duty is the one that bites — you need automatic records of events over the system's lifetime, and those records are themselves personal data subject to Chapter V.
That combination is the trap. Article 12-style logging creates a data store. If that store replicates to a US region for analytics, you have built a transfer out of a compliance artefact. Ask your counsel how the two regimes interact for your specific classification; this is posture, not legal advice.
Hyperscaler EU regions vs. European sovereign clouds: a technical comparison
Both keep bytes in the EEA. They differ on control, operator jurisdiction, and how much of the stack you can inspect. For most regulated workloads the honest answer is that a hyperscaler EU region is sufficient — unless your threat model includes foreign government compulsion.
| Dimension | Hyperscaler EU region | European sovereign cloud |
|---|---|---|
| Compute location | Named EU region (e.g. Frankfurt, Dublin, Paris) | EU region, EU-headquartered operator |
| Operator jurisdiction | Often US parent | EU parent |
| CLOUD Act exposure | Possible | Generally out of scope |
| Model catalogue | Broad, first-party + marketplace | Narrower, often open-weight |
| Contracting | Standard terms, region pinning | Bespoke, sovereign addenda |
| Cost | Lower at scale | Higher per token |
| Operational maturity | High | Variable |
Pick the sovereign option when the data cannot lawfully be exposed to non-EU compulsion, or when a customer contract demands it. Pick the hyperscaler when you need breadth, SLAs and a mature audit surface. Do not pay sovereign prices for a workload that only needed a pinned region.
Does the US CLOUD Act reach your LLM deployment in Europe?
Yes, potentially — the CLOUD Act lets US authorities compel US-based providers to produce data they control, including data stored abroad. It does not matter that the server is in Frankfurt. It matters who the provider is and whether the parent can reach the data.
This is the single most misunderstood point in EU LLM procurement. "EU region" is a residency claim. It is not a sovereignty claim, and it is not a defence against a compelled disclosure order served on a US entity.
Practical mitigations, in rough order of strength:
- Use an operator with no US parent and no US-controlled infrastructure in the path.
- Keep the payload out of the provider's reach entirely — self-host, or route through a gateway that is stateless and does not log payloads.
- If you must use a US provider's EU region, get the disclosure posture in writing and have counsel assess it against your sector obligations.
The third option is the weakest. Do not let a procurement checklist treat it as equivalent to the first.
How do you architect for EU data residency? Headers, logging, and audit trails
Residency is enforced at the routing layer. The mechanism is a region-pinned endpoint plus a per-request assertion you can log. If the region is chosen by a load balancer you cannot see, you do not have a control — you have a hope.
The concrete shape: a gateway endpoint that is itself region-bound, and headers that declare the routing decision so it appears in your audit trail. Illustrative naming — your gateway will call these something else:
curl \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "X-Data-Region: eu-central-1" \
-H "X-Data-Class: phi" \
-d '{"model":"...","messages":[{"role":"user","content":"..."}]}'
Three things have to be true for this to mean anything:
- The endpoint is region-pinned. A single EU hostname, not a global one with a routing preference.
- The response echoes the region. If you cannot read back where the request ran, you cannot evidence it later.
- The audit record contains the routing decision but not the payload. Log the region, the model, the timestamp, the data class, the token counts. Not the prompt.
That last point is where per-request gating and residency meet. A gate that classifies each request as containing PHI or not — and routes accordingly — gives you both a residency control and an audit trail on every call. We wrote up the mechanics separately in implementing per-request PHI gates for LLM APIs, and the routing layer comparison in LLM routers and AI gateways for regulated industries is worth reading before you buy one.
If you are weighing self-hosting against a managed EU endpoint, the trade-offs are laid out in on-premise vs. cloud LLMs for regulated data.
How do specific providers handle EU data residency?
They differ in ways that matter at the endpoint level, and the details move. Verify against current docs before you commit; the table below is the shape of the landscape, not a substitute for a test request.
| Provider route | Residency mechanism | Watch for |
|---|---|---|
| Azure OpenAI | Region-pinned deployments, EU Data Boundary | Which sub-processors sit in the path; BAA coverage is route-specific |
| AWS Bedrock | EU regions, cross-region inference profiles | Cross-region profiles may move data between EU regions — usually fine, confirm |
| Google Vertex AI | EU multi-region endpoints | Multi-region means multiple locations; confirm the set |
| Anthropic Claude API | inference_geo parameter — US only as of August 2026 | No EU pinning via this parameter yet |
| EU-native providers | EU-hosted inference, EU operator | Narrower model catalogue, variable SLAs |
| EU gateways | Region-pinned endpoint in front of multiple models | Confirm statelessness and no payload logging in writing |
That Claude line is the useful one. A parameter that looks like a residency control can be a residency control for exactly one region (CelestInfo's matrix). Read the enum before you read the blog post.
For EU-native hosting options and how they compare on latency and catalogue, Tessera's breakdown of where to host LLM inference with EU residency covers the provider landscape in more detail.
What should a DPIA for an LLM deployment cover?
A DPIA for LLM processing needs to cover the transfer analysis, the retention behaviour of every hop, the logging store, and the re-identification risk of prompts. Most DPIAs we see cover the first and skip the rest.
The checklist I would actually use:
- Data flow map. Every hop from user input to completion, including gateways, routers and observability tooling. The observability vendor is the one people forget.
- Transfer analysis per hop. Which hops leave the EEA, under which Chapter V mechanism.
- Retention per hop. Zero retention at the model provider is worthless if your APM tool keeps full request bodies for 30 days.
- Logging design. What is recorded, where it lives, how long, who can read it. Confirm payloads are excluded.
- Sub-processor list. Current, published, and matched against the contract.
- Sovereignty assessment. Whether any operator in the path is subject to non-EU compulsion.
- Human oversight and redress. Especially if the use case trends high-risk under the AI Act.
If you handle health data, add the BAA question on top. Residency and BAA coverage are independent — an EU region does not give you a BAA, and a BAA does not give you EU residency. Navigating OpenAI's HIPAA-eligible offerings walks through how that split plays out in practice, and HIPAA-compliant LLM APIs covers the PHI handling side.
The short version
Most teams do not need a sovereign cloud. They need a region-pinned endpoint, a gateway that does not log payloads, an audit record per call, and a DPIA that actually maps the hops. That is achievable today without rebuilding your stack.
Where it gets hard is when residency and sovereignty diverge, or when PHI enters the picture and the BAA question sits alongside the transfer question. That is the problem CloudSitus is built around: stateless routing, region residency, no payload logging, no training on your data, and a per-request PHI gate with an audit trail on every call. If your workload touches PHI or sits under an EU transfer analysis, look at how the routing works before you pick a provider on region alone.
FAQ
Is using an EU region enough for GDPR compliance?
No. An EU region answers the residency question. You still need a lawful basis, a Chapter V analysis for any hop that leaves the EEA, a retention position per hop, and a DPIA where the processing is high-risk. Region pinning is one control among several.
Does the EU AI Act require data to stay in Europe?
Not directly. The AI Act sets logging, documentation and oversight duties rather than a residency rule. In practice those duties push you toward in-region processing, because the logs you are required to keep are themselves personal data under GDPR.
Does the US CLOUD Act apply if my LLM runs in Frankfurt?
It can, if the provider or its parent is a US entity that controls the data. The server location does not determine the legal reach. If that exposure is unacceptable, use an operator with no US parent and keep payloads out of the provider's reach.
What is the difference between data residency and data sovereignty for LLMs?
Residency is where the inference ran — a factual, verifiable location. Sovereignty is whether a foreign government can compel the operator to disclose your data. You can have residency without sovereignty, which is the common case for US hyperscaler EU regions.
Do I need a DPIA before deploying an LLM?
Usually yes, if you are processing personal data at scale or in a high-risk context. The DPIA should map every hop including gateways and observability tooling, state the transfer mechanism per hop, and confirm that payload logging is off. Ask your counsel to confirm the trigger for your specific deployment.