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.

• Datenresidenz = 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 allen großen Anbietern möglich, aber bedingt. Azure 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-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. 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-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-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-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) 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-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.

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, 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 Ihrer Kunden messbar. Für B2B-Entscheider gilt: Verlangen Sie vom Anbieter eine vollständige Sub-Prozessor-Karte mit Standort und Funktion je Schicht, bevor Sie produktiv gehen. Blck Alpaca 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 Ihres konkreten Falls konsultieren Sie bitte eine Rechtsanwältin oder einen Rechtsanwalt bzw. Ihre Datenschutzbeauftragte.