--- title: "EU-Datenresidenz für LLMs: Wo Ihre Daten verarbeitet werden" description: "EU-Datenresidenz für LLMs bedeutet, dass Prompts, Outputs, Embeddings und Logs ausschließlich in einer EU-Region gespeichert und verarbeitet werden. Sie ist datenschutzrechtlich relevant, weil jede Verarbeitung außerhalb des EWR ein Drittlandtransfer nach Kapitel V DSGVO ist und damit zusätzliche Garantien erfordert." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/dsgvo-konform-ai-agents-einsetzen/eu-datenresidenz-fuer-llms" category: "KI Agenten" topic: "DSGVO-konformer AI-Agent-Einsatz" updated: "2026-07-29T08:52:56.062Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # EU-Datenresidenz für LLMs: Wo Ihre Daten verarbeitet werden EU-Datenresidenz für LLMs bedeutet, dass Prompts, Outputs, Embeddings und Logs ausschließlich in einer EU-Region gespeichert und verarbeitet werden. Sie ist datenschutzrechtlich relevant, weil jede Verarbeitung außerhalb des EWR ein Drittlandtransfer nach Kapitel V DSGVO ist und damit zusätzliche Garantien erfordert. ## Kernaussagen - Datenresidenz beschreibt den physischen Speicher- und Verarbeitungsort. Verlässt der Datenfluss den EWR, greift Kapitel V DSGVO und es braucht ein Transfer-Instrument plus Transfer-Impact-Assessment (TIA). - EU-Hosting ist bei den großen Anbietern möglich, aber an Bedingungen geknüpft: Azure OpenAI über die EU Data Boundary, Anthropic Claude nur über AWS Bedrock EU oder Google Vertex EU, Vertex über regionale EU-Endpunkte, Mistral als EU-Anbieter. - Wichtige Einschränkungen (Stand Recherche 14. Mai 2026): Anthropic-Modelle in Microsoft 365 Copilot sind von der EU Data Boundary ausgenommen; auf der AWS European Sovereign Cloud (eusc-de-east-1, gestartet Jänner 2026) sind Claude-Modelle noch nicht verfügbar. - Die Anthropic Direct API bietet nur die Regionen 'us' und 'global'; echte EU-Residenz erfordert den Umweg über AWS Bedrock EU oder Vertex EU. - US-Anbieter bleiben trotz EU-Region dem US CLOUD Act ausgesetzt. Das EU-US Data Privacy Framework ist gültig, aber das Verfahren Latombe ist beim EuGH anhängig; SCCs als Fallback bleiben Pflicht (Stand 2026, vorbehaltlich Änderung). - Souveräne Cloud-Optionen wie IONOS, STACKIT, Open Telekom Cloud, Aleph Alpha und Swisscom verarbeiten ausschließlich in DE/EU bzw. CH und umgehen das Drittland-Problem. **EU-Datenresidenz für LLMs** bedeutet, dass Prompts, Outputs, Embeddings und Logs ausschließlich in einer EU-Region gespeichert und verarbeitet werden. Sie ist datenschutzrechtlich relevant, weil jede Verarbeitung außerhalb des EWR ein [Drittlandtransfer nach Kapitel V DSGVO](/de/wissen/ki-agenten/dsgvo-konform-ai-agents-einsetzen/drittlandtransfer-usa-data-privacy-framework) ist und damit zusätzliche Garantien erfordert. - **Datenresidenz = Verarbeitungsort.** Verlässt der Datenfluss den EWR, greift Kapitel V [DSGVO](/de/glossar/dsgvo) und es braucht ein Transfer-Instrument plus Transfer-Impact-Assessment (TIA). - **EU-Hosting ist bei allen großen Anbietern möglich, aber bedingt.** Azure [OpenAI](/de/glossar/openai) über die EU Data Boundary, Claude nur über AWS Bedrock EU oder Vertex EU, Vertex über regionale EU-Endpunkte, Mistral als EU-Anbieter. - **Eine EU-Region allein löst das Problem nicht.** US-Anbieter bleiben trotz EU-Region dem US CLOUD Act ausgesetzt; souveräne DACH-Anbieter umgehen das Drittland-Thema vollständig. ## Was Datenresidenz ist und warum sie für die DSGVO zählt Datenresidenz beschreibt den geografischen Ort, an dem personenbezogene Daten gespeichert und verarbeitet werden. Bei einem [LLM](/de/glossar/llm)-gestützten System ist dieser Ort nicht auf die Inferenz beschränkt. [Nach Art. 4(1)/(2) DSGVO ist jede Operation auf personenbezogenen Daten eine Verarbeitung](/de/wissen/ki-agenten/dsgvo-konform-ai-agents-einsetzen/auftragsverarbeitung-art-28-ki-anbieter). In einem Agenten-Stack betrifft das mindestens: - **Inferenz-Inputs**: Prompts, System-Prompts, angehängte Dateien, Sprachsamples. - **Inferenz-Outputs**: Texte und Zusammenfassungen, die Personen benennen oder beschreiben (auch halluzinierte personenbezogene Daten). - [**Agent](/de/glossar/agent)-Memory**: Kontextfenster, episodisches und semantisches Gedächtnis, persistente Vektorspeicher. - **Embeddings und Vektorspeicher**: sowohl der indexierte Text als auch die Vektoren selbst gelten als pseudonyme personenbezogene Daten, da Inversions- und Membership-Inference-Angriffe eine Re-Identifizierung ermöglichen. - **Logs und Traces**: [Prompt](/de/glossar/prompt)-Logs, Completion-Logs, Observability-Spans. Der entscheidende Punkt: Jeder dieser Punkte kann an einem anderen Ort liegen. Eine EU-residente Inferenz nützt wenig, wenn der Vektorspeicher, das Observability-Backend oder ein nachgelagerter [MCP](/de/glossar/mcp)-Server in ein Drittland routet. ### Der Drittlandtransfer als Auslöser Sobald personenbezogene Daten den EWR verlassen, handelt es sich um einen Drittlandtransfer nach Kapitel V DSGVO. Maßgeblich ist hier das EuGH-Urteil *Schrems II* (C-311/18, 16. Juli 2020): Es erklärte das Privacy Shield für ungültig und stellte klar, dass Standardvertragsklauseln (SCCs) nur in Verbindung mit einem fallbezogenen Transfer-Impact-Assessment gültig bleiben, inklusive ergänzender Maßnahmen, wo nötig. Die Kommission hat dies mit den SCCs 2021/914 (4. Juni 2021) in vier Modulen operationalisiert. EU-Datenresidenz ist deshalb das wirksamste Mittel, um diese Transfer-Problematik gar nicht erst entstehen zu lassen: Bleiben alle Verarbeitungsschichten im EWR, entfällt der Drittlandtransfer als Prüfpunkt. ## Status des EU-US Data Privacy Framework (Stand 2026, vorbehaltlich Änderung) Wo ein Transfer in die USA unvermeidbar ist, ist das [**EU-US Data Privacy Framework (DPF)**](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) das zentrale Instrument. Die Kommission hat den Angemessenheitsbeschluss am 10. Juli 2023 erlassen (als Nachfolger des Privacy Shield). Am 3. September 2025 wies das **EU-Gericht (EuG)** in *Latombe v Commission* (T-553/23) die erste Klage ab und bestätigte die Gültigkeit des DPF zum Zeitpunkt seiner Annahme. Offene Punkte (Stand Recherche 14. Mai 2026, vorbehaltlich Änderung): - Latombe hat am 31. Oktober 2025 Rechtsmittel beim **EuGH** eingelegt; das Verfahren ist anhängig. - NOYB/Max Schrems hat eine eigene, breitere Klage signalisiert, mit Fokus auf US-Executive-Orders, die die Unabhängigkeit des Privacy and Civil Liberties Oversight Board (PCLOB) betreffen. Ein „Schrems-III"-Szenario bleibt damit plausibel. - Das EU-Gericht hat ausdrücklich festgehalten, dass die Kommission den Rechtsrahmen laufend überwachen und den Beschluss bei geänderten Bedingungen aussetzen, ändern oder aufheben kann. Operative Konsequenz: Eine DPF-Zertifizierung ist derzeit eine gültige Transfer-Grundlage, Unternehmen sollten jedoch **SCCs als Fallback** vorhalten und auch bei DPF-zertifizierten Empfängern ein TIA durchführen. Für die Schweiz gilt das Swiss-US DPF (in Kraft seit 15. September 2024); die Schweiz selbst ist seit 15. Jänner 2024 von der EU-Kommission als angemessen anerkannt. ## Warum eine EU-Region das CLOUD-Act-Risiko nicht eliminiert Eine EU-Region adressiert den Speicherort, nicht die Jurisdiktion über den Anbieter. Im TIA für [KI](/de/glossar/ki)-Anbieter bleiben deshalb diese Risiken bestehen: - **US CLOUD Act**: Zugriffsrisiko für US-Anbieter und deren EWR-Töchter, unabhängig davon, wo die Daten physisch liegen. - **FISA 702 / EO 12333**: Exposition für Anbieter elektronischer Kommunikationsdienste (etwa Microsoft, Google, AWS). - **Gegenmaßnahmen**: Verschlüsselung at rest und in transit als Mindeststandard; zunehmend Encryption-in-use (Confidential Computing, TEEs); BYOK/HYOK, sodass der Anbieter ohne Mitwirkung des Verantwortlichen nicht entschlüsseln kann. Genau hier liegt der Mehrwert souveräner DACH-Anbieter: Sie unterliegen keiner US-Jurisdiktion und verarbeiten ausschließlich in DE/EU bzw. CH. ## EU-Hosting-Optionen der großen Anbieter Die folgende Übersicht fasst die Datenresidenz-Optionen zusammen. Sie ist eine Recherche-Zusammenfassung, keine Rechtsberatung; Anbieterbedingungen ändern sich häufig und sind bei Vertragsabschluss neu zu prüfen. | Anbieter | EU-Region möglich? | Hinweise | | --- | --- | --- | | **Microsoft Azure OpenAI / 365 Copilot** | Ja, über EU Data Boundary | EU Data Boundary für Kerndienste; [Fine-Tuning](/de/glossar/fine-tuning) kann laut DPA regionsübergreifend verarbeitet werden. Anthropic-Modelle in M365 Copilot (Sept 2025 / Jän 2026) sind von der EU Data Boundary ausgenommen | | **OpenAI [API](/de/glossar/api) (Enterprise/Business/API)** | Teilweise | EU-Datenresidenz für berechtigte Enterprise-/Edu-Accounts und bestimmte API-Setups; sonst standardmäßig globales Routing. OpenAI Ireland Ltd ist EWR/CH-Vertragspartner; DPA mit Wirkung Dez 2025 / Jän 2026 | | [**Anthropic Claude](/de/glossar/anthropic-claude) (Direct API)** | Nein (nur „us"/„global") | Direct API bietet nur Regionen „us" und „global". Für EU-Residenz Umweg über AWS Bedrock EU oder Vertex EU | | **Anthropic Claude über AWS Bedrock** | Ja, EU-Regionen | EU-Regionen verfügbar; Provider-Modelle sind von den Provider-Diensten isoliert. European Sovereign Cloud (eusc-de-east-1, Jän 2026), Claude dort noch nicht verfügbar | | **Google Vertex AI (Gemini, Claude)** | Ja, regionale EU-Endpunkte | 10 EU-Regionen für Claude auf Vertex; Regionsauswahl garantiert In-Region-Verarbeitung; Aufpreis für regionale Endpunkte | | **Mistral AI** | Ja | EU-ansässiger Anbieter, EU-Verarbeitung betont; 10-Tage-Einspruchsfrist für neue Sub-Prozessoren | | **IONOS / STACKIT / Open Telekom Cloud** | Ja, ausschließlich DE/EU | Souveräne Cloud; In-Country-Verarbeitung, begrenzte Sub-Prozessor-Ketten; deutsches AVV-Recht | | **Aleph Alpha (Pharia)** | Ja, EU-souverän/On-Prem | On-Prem- und EU-Souverän-Optionen; BfDI-kompatible AVV-Templates | | **Swisscom Sovereign AI** | CH-Residenz | Schweiz-residente Verarbeitung nach revDSG | | **DeepSeek API** | Nein | PRC-Jurisdiktion; „Country-of-Concern"-Risiko; für DACH-Enterprise in regulierten Sektoren nicht empfohlen | ### Lesart der Tabelle Drei Muster stechen heraus. Erstens: Die Hyperscaler bieten EU-Regionen, koppeln sie aber an Konfiguration (Region-Pinning) und teils an Aufpreise, etwa die regionalen Endpunkte bei Vertex. Zweitens: Anthropic Claude ist in der EU nur indirekt residenzfähig, nämlich über AWS Bedrock EU oder Vertex EU, nicht über die Direct API. Drittens: Souveräne DACH-Anbieter (IONOS, STACKIT, Open Telekom Cloud, Aleph Alpha, Swisscom) bieten die einzige Option mit ausschließlicher DE/EU- bzw. CH-Verarbeitung und ohne US-Jurisdiktionsrisiko. ## Rechenbeispiel: Datenresidenz im Sub-Prozessor-Stack Ein typischer agentischer Deployment-Stack umfasst fünf bis acht Sub-Prozessor-Schichten: Foundation-Model-Anbieter, Hosting/Cloud, [Orchestrierung](/de/glossar/orchestrierung), Vektorspeicher, Memory-Provider, MCP-Server, Observability und Evaluation. Nehmen wir ein konkretes Setup: Ein österreichisches Unternehmen betreibt einen Kundenservice-Agenten auf Claude über AWS Bedrock in einer EU-Region (Schicht 1 + 2, EU-resident). Der Vektorspeicher liegt in der EU (Schicht 4, EU-resident). Aber: Das Observability-Tool (Schicht 7) sendet Prompt-Traces an ein US-Backend, und ein angebundener MCP-Server (Schicht 6) eines US-Anbieters verarbeitet Tool-Call-Payloads global. Rechnung: Von 8 Schichten sind 6 EU-resident, 2 routen ins Drittland. Das genügt **nicht** für EU-Datenresidenz. Schon eine einzige Schicht im Drittland macht den gesamten Datenfluss zu einem transferpflichtigen Vorgang nach Kapitel V, mit TIA, SCCs und Restrisiko durch den CLOUD Act. Die häufigsten Audit-Findings betreffen genau diese unsichtbaren Schichten: nicht offengelegte MCP-Server-Flows und Observability-Anbieter ohne AVV. Konkrete Bußgeld-Dimension zur Einordnung: Clearview AI wurde wegen rechtswidriger Datenverarbeitung in Italien mit 20 Mio. EUR (10. Februar 2022) und in Frankreich mit 20 Mio. EUR (17. Oktober 2022) belegt; das italienische Garante verhängte gegen OpenAI 15 Mio. EUR (Bescheid vom 2. November 2024). Datenfluss-Disziplin ist also keine theoretische Übung. ## Praktische Konsequenzen für die Anbieterauswahl - **Region-Pinning vertraglich festschreiben.** Standardmäßiges globales Routing und Vendor-Failover in Nicht-EU-Regionen sind ein häufiges Audit-Finding. Die Residenz muss im AVV festgelegt sein, nicht nur konfigurierbar. - **Alle Schichten prüfen, nicht nur die Inferenz.** Vektorspeicher, Memory, MCP-Server und Observability separat auf Residenz und AVV prüfen; eine ungebrochene Art.-28(4)-Kette sicherstellen. - **Bei US-Anbietern dual absichern.** DPF-Zertifizierung verifizieren, SCCs als Fallback halten, TIA dokumentieren. - **Souveräne Optionen bei sensiblen Sektoren erwägen.** In stark regulierten Bereichen (etwa Finanzdienstleistung mit Bankgeheimnis nach Art. 47 BankG in der Schweiz) drängen souveräne Cloud- und On-Prem-Lösungen praktisch in den Vordergrund. ## Für Agenturen und B2B-Entscheider Datenresidenz ist kein reines IT-Detail, sondern ein Vertrags- und Architekturthema, das früh in die Anbieterauswahl gehört. Für Agenturen, die KI-Agenten für DACH-Kunden bauen, ist die residenzkonforme Architektur ein verkaufbares Qualitätsmerkmal: Ein dokumentierter EU-Datenfluss über alle Sub-Prozessor-Schichten reduziert das Drittland-Risiko deiner Kunden messbar. Für B2B-Entscheider gilt: Verlange vom Anbieter eine vollständige Sub-Prozessor-Karte mit Standort und Funktion je Schicht, bevor du produktiv gehst. [Blck Alpaca](/de) unterstützt bei der Bewertung von EU-Residenz-Optionen, der TIA-Dokumentation und dem Aufbau residenzkonformer Agenten-Stacks. --- *Hinweis: Dieser Beitrag dient der fachlichen Information und stellt keine Rechtsberatung dar. Für die verbindliche Beurteilung deines konkreten Falls konsultiere bitte eine Rechtsanwältin oder einen Rechtsanwalt bzw. deine Datenschutzbeauftragte.* ## FAQ ### Was bedeutet EU-Datenresidenz bei LLMs genau? Datenresidenz beschreibt, an welchem geografischen Ort personenbezogene Daten gespeichert und verarbeitet werden. Bei LLMs umfasst das nicht nur die Inferenz, sondern jeden Verarbeitungspunkt: Prompts, Outputs, Agent-Memory, Embeddings in Vektorspeichern sowie Logs und Traces. EU-Datenresidenz liegt nur dann vor, wenn alle diese Schichten innerhalb des EWR bleiben. ### Warum ist Datenresidenz für die DSGVO relevant? Sobald personenbezogene Daten den EWR verlassen, handelt es sich um einen Drittlandtransfer nach Kapitel V DSGVO. Dieser ist nur mit einem Angemessenheitsbeschluss, Standardvertragsklauseln oder anderen Garantien zulässig. Nach dem EuGH-Urteil Schrems II (C-311/18, 16. Juli 2020) ist zusätzlich ein Transfer-Impact-Assessment erforderlich. EU-Residenz vermeidet diese Transfer-Problematik weitgehend. ### Kann ich Anthropic Claude mit EU-Datenresidenz nutzen? Nicht über die Direct API: Diese bietet laut Recherche-Stand nur die Regionen 'us' und 'global'. Für EU-Residenz musst du Claude über die EU-Profile von AWS Bedrock oder über die regionalen EU-Endpunkte von Google Vertex AI beziehen. Beachte: Auf der AWS European Sovereign Cloud (eusc-de-east-1, gestartet Jänner 2026) sind Claude-Modelle noch nicht verfügbar. ### Reicht eine EU-Region aus, um den US CLOUD Act zu umgehen? Nein. Eine EU-Region verhindert nicht, dass US-Anbieter und ihre EWR-Töchter dem US CLOUD Act sowie FISA 702 / EO 12333 unterliegen können. Das Risiko einer behördlichen Herausgabeanordnung besteht unabhängig vom physischen Speicherort. Genau dieses Restrisiko muss ein Transfer-Impact-Assessment dokumentieren. ### Welche Anbieter verarbeiten ausschließlich in der EU oder der Schweiz? Souveräne Anbieter wie IONOS AI Model Hub, STACKIT und T-Systems Open Telekom Cloud verarbeiten ausschließlich in DE/EU. Aleph Alpha (Pharia) bietet On-Prem- und EU-Souverän-Optionen, Mistral AI ist EU-ansässig. Für die Schweiz adressiert Swisscom Sovereign AI eine reine CH-Residenz nach revDSG. --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/dsgvo-konform-ai-agents-einsetzen/eu-datenresidenz-fuer-llms). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.