EU Data Residency for LLMs: Where Your Data Is Processed

EU data residency for LLMs means that prompts, outputs, embeddings and logs are stored and processed exclusively within an EU region. It is relevant under data protection law because any processing outside the EEA constitutes a third-country transfer under Chapter V GDPR and therefore requires additional safeguards.

• Data residency = place of processing. If the data flow leaves the EEA, Chapter V GDPR applies and a transfer instrument plus a transfer impact assessment (TIA) is required.
• EU hosting is possible with all major providers, but conditional. Azure OpenAI via the EU Data Boundary, Claude only via AWS Bedrock EU or Vertex EU, Vertex via regional EU endpoints, Mistral as an EU provider.
• An EU region alone does not solve the problem. US providers remain exposed to the US CLOUD Act despite an EU region; sovereign DACH providers circumvent the third-country issue entirely.

What data residency is and why it matters for the GDPR

Data residency describes the geographic location at which personal data is stored and processed. In an LLM-based system, this location is not limited to inference. Under Art. 4(1)/(2) GDPR, any operation on personal data constitutes processing. In an agent stack, this affects at least:

• Inference inputs – prompts, system prompts, attached files, voice samples.
• Inference outputs – texts and summaries that name or describe individuals (including hallucinated personal data).
• Agent memory – context windows, episodic and semantic memory, persistent vector stores.
• Embeddings and vector stores – both the indexed text and the vectors themselves are considered pseudonymous personal data, since inversion and membership inference attacks enable re-identification.
• Logs and traces – prompt logs, completion logs, observability spans.

The crucial point: each of these points may be located in a different place. EU-resident inference is of little use if the vector store, the observability backend or a downstream MCP server routes to a third country.

The third-country transfer as a trigger

As soon as personal data leaves the EEA, it constitutes a third-country transfer under Chapter V GDPR. The decisive authority here is the CJEU ruling in Schrems II (C-311/18, 16 July 2020): it invalidated the Privacy Shield and made clear that standard contractual clauses (SCCs) remain valid only in conjunction with a case-specific transfer impact assessment – including supplementary measures where necessary. The Commission operationalised this with the SCCs 2021/914 (4 June 2021) in four modules.

EU data residency is therefore the most effective means of preventing this transfer problem from arising in the first place: if all processing layers remain within the EEA, the third-country transfer ceases to be a point of assessment.

Status of the EU-US Data Privacy Framework (as of 2026, subject to change)

Where a transfer to the US is unavoidable, the EU-US Data Privacy Framework (DPF) is the central instrument. The Commission adopted the adequacy decision on 10 July 2023 (as the successor to the Privacy Shield). On 3 September 2025 the General Court (GC) dismissed the first action in Latombe v Commission (T-553/23) and confirmed the validity of the DPF at the time of its adoption.

Open issues (as of research dated 14 May 2026, subject to change):

• Latombe lodged an appeal with the CJEU on 31 October 2025; the proceedings are pending.
• NOYB/Max Schrems has signalled a separate, broader action – focusing on US executive orders that affect the independence of the Privacy and Civil Liberties Oversight Board (PCLOB). A "Schrems III" scenario therefore remains plausible.
• The General Court expressly noted that the Commission must continuously monitor the legal framework and may suspend, amend or repeal the decision if conditions change.

Operational consequence: a DPF certification is currently a valid transfer basis – however, companies should keep SCCs as a fallback in place and also carry out a TIA for DPF-certified recipients. For Switzerland, the Swiss-US DPF applies (in force since 15 September 2024); Switzerland itself has been recognised as adequate by the EU Commission since 15 January 2024.

Why an EU region does not eliminate the CLOUD Act risk

An EU region addresses the storage location, not the jurisdiction over the provider. In the TIA for AI providers, the following risks therefore persist:

• US CLOUD Act: access risk for US providers and their EEA subsidiaries, regardless of where the data is physically located.
• FISA 702 / EO 12333: exposure for providers of electronic communications services (such as Microsoft, Google, AWS).
• Countermeasures: encryption at rest and in transit as a minimum standard; increasingly encryption in use (confidential computing, TEEs); BYOK/HYOK, so that the provider cannot decrypt without the involvement of the controller.

This is precisely where the added value of sovereign DACH providers lies: they are not subject to US jurisdiction and process exclusively in DE/EU or CH.

EU hosting options of the major providers

The following overview summarises the data residency options. It is a research summary, not legal advice; provider terms change frequently and must be reassessed at the time of contracting.

How to read the table

Three patterns stand out. First: the hyperscalers offer EU regions, but tie them to configuration (region pinning) and, in some cases, to surcharges – such as the regional endpoints with Vertex. Second: Anthropic Claude can achieve residency in the EU only indirectly, namely via AWS Bedrock EU or Vertex EU, not via the Direct API. Third: sovereign DACH providers (IONOS, STACKIT, Open Telekom Cloud, Aleph Alpha, Swisscom) offer the only option with exclusive DE/EU or CH processing and without US jurisdiction risk.

Worked example: data residency in the sub-processor stack

A typical agentic deployment stack comprises five to eight sub-processor layers: foundation model provider, hosting/cloud, orchestration, vector store, memory provider, MCP server, observability and evaluation.

Let us take a concrete setup: an Austrian company operates a customer service agent on Claude via AWS Bedrock in an EU region (layers 1 + 2, EU-resident). The vector store is located in the EU (layer 4, EU-resident). However: the observability tool (layer 7) sends prompt traces to a US backend, and a connected MCP server (layer 6) of a US provider processes tool-call payloads globally.

Calculation: of 8 layers, 6 are EU-resident, 2 route to a third country. This is not sufficient for EU data residency. Even a single layer in a third country turns the entire data flow into a transfer-subject operation under Chapter V – with a TIA, SCCs and residual risk from the CLOUD Act. The most common audit findings relate precisely to these invisible layers: undisclosed MCP server flows and observability providers without a data processing agreement.

Concrete fine dimension for context: Clearview AI was fined EUR 20 million for unlawful data processing in Italy (10 February 2022) and EUR 20 million in France (17 October 2022); the Italian Garante imposed a fine of EUR 15 million on OpenAI (decision of 2 November 2024). Data flow discipline is therefore no theoretical exercise.

Practical consequences for provider selection

• Stipulate region pinning contractually. Default global routing and vendor failover into non-EU regions are a common audit finding. Residency must be laid down in the data processing agreement, not merely configurable.
• Check all layers, not just inference. Assess vector stores, memory, MCP servers and observability separately for residency and a data processing agreement; ensure an unbroken Art. 28(4) chain.
• Provide dual safeguards with US providers. Verify DPF certification, keep SCCs as a fallback, document the TIA.
• Consider sovereign options for sensitive sectors. In heavily regulated areas (such as financial services subject to banking secrecy under Art. 47 of the Swiss Banking Act), sovereign cloud and on-premises solutions practically come to the fore.

For agencies and B2B decision-makers

Data residency is not a purely IT detail, but a contractual and architectural matter that belongs early in the provider selection process. For agencies building AI agents for DACH clients, a residency-compliant architecture is a marketable quality feature: a documented EU data flow across all sub-processor layers measurably reduces your clients' third-country risk. For B2B decision-makers: demand a complete sub-processor map from the provider, with location and function for each layer, before going into production. Blck Alpaca supports the assessment of EU residency options, TIA documentation and the development of residency-compliant agent stacks.

Note: This article serves as professional information and does not constitute legal advice. For a binding assessment of your specific case, please consult a lawyer or your data protection officer.