Wichtigste Erkenntnisse
- Datenresidenz (wo Daten liegen) und Datensouveränität (wessen Recht sie kontrolliert) sind unterschiedliche Probleme — eine "EU-Region" eines US-Anbieters löst nur das erste, adressiert das zweite aber nur teilweise.
- Schrems II (EuGH, 2020) bedeutet: In den USA ansässige Cloud- und KI-Anbieter bleiben für US-Überwachungsrecht (CLOUD Act, FISA 702) erreichbar, selbst wenn ihre Server physisch in der EU stehen.
- DSGVO Art. 44-49 regeln jede Übermittlung personenbezogener Daten außerhalb der EU/des EWR — dazu zählen auch API-Aufrufe an einen Nicht-EU-Inferenz-Endpunkt, nicht nur Massenexporte.
- Es gibt drei reale Architekturoptionen: selbstgehostete/On-Prem-Inferenz, US-Hyperscaler-EU-Region-Cloud und eine in der EU ansässige "souveräne Cloud" — jede hat ein anderes Sub-Auftragsverarbeiter- und Gerichtsbarkeitsprofil.
- Multinationale Unternehmen sollten in der Regel Pro-Region-Inferenz-Cluster als Standard wählen, sofern kein validierter Übermittlungsmechanismus den regionsübergreifenden Fluss konkret abdeckt.
- Chinas PIPL und Data Security Law schaffen über CAC-Sicherheitsbewertungen ein drittes, eigenständiges Übermittlungsregime — es gilt aber für gehostete APIs, nicht für ein chinesisches Open-Weight-Modell, das Sie einmal herunterladen und selbst hosten.
- Open-Weight-Modelle generell (Llama, Mistral, Qwen, DeepSeek und andere) erlauben es, den Modellanbieter durch Self-Hosting vollständig aus der laufenden Verarbeitungskette zu entfernen — eine strukturell stärkere Souveränitätsposition, als nur die "richtige" Region eines Anbieters zu wählen.
- Kein Bereitstellungsmodell ist pauschal "DSGVO-konform" — das hängt von Ihren konkreten Verarbeitungstätigkeiten, der Rechtsgrundlage und der DSFA ab. Dieser Artikel ist keine Rechtsberatung; wenden Sie sich an Ihren Datenschutzbeauftragten oder Rechtsberater.
Was Datensouveränität für KI-Workloads wirklich erfordert
"Datensouveränität" wird oft locker verwendet, reduziert sich für eine Enterprise-KI-Bereitstellung aber auf drei konkrete Fragen: Wo werden die Daten physisch verarbeitet und gespeichert, welche Sub-Auftragsverarbeiter berühren sie unterwegs, und welche Regierung kann rechtlich Zugriff darauf erzwingen — unabhängig davon, wo die Server stehen.
Datenresidenz beantwortet nur die erste Frage — eine Aussage über den physischen oder logischen Standort ("diese Daten liegen in Frankfurt"). Datensouveränität beantwortet die dritte Frage — eine Aussage über Rechtszuständigkeit und Durchsetzbarkeit ("welches Land erreicht diese Daten und diesen Anbieter mit seinen Gerichten und Geheimdienstzugriffsgesetzen"). Ein in den USA ansässiger Cloud-Anbieter kann volle EU-Datenresidenz bieten (EU-Rechenzentren, EU-Support, eine EU-Gesellschaft als Vertragspartner) und dennoch strukturell durch US-Recht erreichbar bleiben, weil die Muttergesellschaft selbst nach US-Recht eine "US person" ist, unabhängig davon, wo ein bestimmtes Server-Rack physisch steht.
Für KI-Inferenz ist das relevant, weil die betroffenen "Daten" nicht nur Trainingsdaten sind — es sind jeder Prompt, jedes abgerufene Dokument in einer RAG-Pipeline, jede Modellausgabe und jeder Log-Eintrag Ihres Observability-Stacks. Eine Verarbeitungsort-Analyse muss die gesamte Kette nachverfolgen: den Inferenz-Endpunkt, den Embedding-/Vektordatenbank-Dienst bei RAG, den Logging-/Observability-Anbieter und jeden Drittanbieter für Fine-Tuning oder Evaluation. Jeder davon ist ein potenzieller Sub-Auftragsverarbeiter mit eigener Gerichtsbarkeit, und Art. 28 DSGVO verlangt für jeden einen Auftragsverarbeitungsvertrag.
Unternehmen, die SOC-2- und ISO-27001-Bereitschaft für selbstgehostete LLM-Bereitstellungen bewerten, erkennen dieses Muster wieder — Audit-Bereitschaft und Datensouveränitätsanalyse starten beide bei derselben Sub-Auftragsverarbeiter-Karte, nur für unterschiedliche regulatorische Fragen.
Open-Weight-Modelle sind der Grund, warum die Zeile "Selbst-Hosting" in dieser Sub-Auftragsverarbeiter-Karte tatsächlich kurz ausfällt. Ein Closed-Weight-Modell — selbst eines aus einer EU-Region — erfordert für jeden Inferenzaufruf weiterhin eine laufende API-Beziehung zum Modellanbieter als Sub-Auftragsverarbeiter. Ein Open-Weight-Modell (Metas Llama, Modelle von Mistral, Alibabas Qwen, DeepSeek oder andere offen lizenzierte Gewichte), das einmal heruntergeladen und vollständig auf eigener Infrastruktur betrieben wird, entfernt den Modellanbieter nach diesem einmaligen Download aus der Verarbeitungskette — es gibt dann überhaupt keinen laufenden Inferenz-API-Aufruf mehr zu erfassen, unabhängig davon, in welchem Land das Modell ursprünglich trainiert wurde.
📍 In einem Satz
Datensouveränität für KI bedeutet: Die Rechtsordnung, die den Zugriff auf Ihre Daten kontrolliert, ändert sich nicht automatisch, nur weil die Server eines Anbieters in Ihrem Land stehen — wer Zugriff erzwingen kann, zählt genauso wie der Speicherort.
💬 In einfachen Worten
Datenresidenz = wo die Bytes physisch liegen. Datensouveränität = wessen Recht den Zugriff auf diese Bytes kontrolliert, einschließlich ausländischer staatlicher Zugriffsforderungen. Eine "EU-Region" eines US-Unternehmens kann EU-Residenz haben, unterliegt für den rechtlichen Zugriff aber weiter US-Souveränität — das ist das Schrems-II-Problem in einem Satz.
Schrems II und DSGVO Art. 44-49: Die Grundlagen grenzüberschreitender Übermittlung
Das Schrems-II-Urteil des EuGH von 2020 erklärte den EU-US Privacy Shield für ungültig, mit der Begründung, dass US-Überwachungsrecht (insbesondere FISA Section 702 und die Reichweite des CLOUD Act) keinen "im Wesentlichen gleichwertigen" Schutz wie EU-Recht für personenbezogene Daten bietet, auf die US-Behörden zugreifen können. Die praktische Konsequenz für Enterprise-KI-Einkäufer: Die Nutzung eines in den USA ansässigen KI-Anbieters — selbst mit EU-gehostetem Endpunkt — löst das vom Urteil identifizierte Zugriffsrisiko nicht automatisch. Standardvertragsklauseln (SCCs) bleiben nach Schrems II ein gültiger Übermittlungsmechanismus, der EuGH verlangt aber ergänzende technische und organisatorische Maßnahmen, wo das Recht des Zielstaats den SCC-Schutz sonst aushebeln könnte, sowie eine dokumentierte Transfer-Impact-Assessment.
DSGVO Art. 44-49 sind die maßgeblichen Regeln: Art. 44 legt den Grundsatz fest, dass jede Übermittlung personenbezogener Daten in ein Drittland den Bedingungen dieses Kapitels entsprechen muss. Art. 45 betrifft Angemessenheitsbeschlüsse (die EU hat für manche Länder angemessenen Schutz festgestellt — für die USA besteht aktuell kein allgemeiner Angemessenheitsbeschluss, nachdem sowohl Safe Harbor als auch Privacy Shield für ungültig erklärt wurden). Art. 46 betrifft Übermittlungen mit geeigneten Garantien, vor allem SCCs. Art. 47-49 betreffen verbindliche interne Datenschutzvorschriften und enge Ausnahmen für Einzelfälle.
Was Enterprise-KI-Einkäufer am häufigsten übersehen: Diese Regeln gelten für *jede* Übermittlung personenbezogener Daten außerhalb der EU/des EWR, nicht nur für Massenexporte. Ein einzelner API-Aufruf, der das Support-Ticket eines EU-Kunden an einen in den USA gehosteten Inferenz-Endpunkt sendet, ist eine Übermittlung im Sinne der Art. 44-49, selbst wenn die Antwort in Millisekunden zurückkommt und nichts im klassischen Sinne "gespeichert" wird. Dasselbe gilt für Telemetrie, Fehlerprotokolle und Analytics-Ereignisse, die personenbezogene Daten enthalten und an eine Nicht-EU-Observability-Plattform gesendet werden.
Für einen Vergleich konkreter Modellanbieter zu genau diesem Risikoprofil siehe den DSGVO-Risikovergleich zwischen Qwen, DeepSeek, Llama und Claude — dieser bewertet einzelne Modell-/API-Entscheidungen; dieser Artikel konzentriert sich auf die übergeordnete Architekturfrage der Bereitstellung.
Selbstgehostet vs. EU-Region-Cloud vs. souveräne Cloud
Drei Architekturmuster decken die meisten Enterprise-Optionen ab. Keines ist automatisch "konform" — jedes verändert, welche Sub-Auftragsverarbeiter und Rechtsordnungen betroffen sind, und genau das muss Ihr Datenschutzbeauftragter bewerten.
Ansatz | Datenstandort | Souveränitätsprofil | Aufwand | Am besten für |
|---|---|---|---|---|
| Selbstgehostet / On-Prem in EU | EU/EWR, eigene Infrastruktur | Geringstes Risiko — kein Dritter im Inferenzpfad | Hoch (Hardware, Betrieb, Skalierung) | Regulierte/kritische Daten, max. Kontrolle |
| US-Hyperscaler EU-Region | EU-Rechenzentren, US-Anbieter | Mittel — Schrems-II-Risiko über Mutterkonzern bleibt | Niedrig (Managed Service) | Tempo, Daten mit geringerem Risiko, valide TIA |
| EU-souveräne Cloud | EU/EWR, EU-Anbieter | Niedrig — EU-Recht, EU-AVV standardmäßig | Niedrig-mittel (Managed, kleineres Ökosystem) | Managed-Komfort ohne US-Rechtszugriff |
Multinationale Architektur: Pro-Region-Cluster vs. zentralisiert
Ein multinationales Unternehmen, das Enterprise-KI ausrollt, steht vor einer strukturellen Entscheidung, die nichts mit Modellqualität zu tun hat: Wird die personenbezogenen Daten jeder Region durch einen physisch und rechtlich in dieser Region ansässigen Inferenz-Cluster verarbeitet, oder läuft alles über einen zentralen Cluster (meist dort, wo das KI-Plattformteam sitzt)?
Ein zentralisierter Cluster ist betrieblich einfacher — eine Bereitstellung, eine Modellversion, ein Observability-Stack. Aber jede regionale personenbezogene Datenmenge überquert damit eine Grenze, sobald sie die API erreicht, was für EU-Daten, die zu einem Nicht-EU-Cluster fließen, direkt DSGVO Art. 44-49 auslöst — und in anderen Regionen entsprechende Regelwerke (LGPD in Brasilien, PDPL in Saudi-Arabien und den VAE, PIPL in China — siehe unten). Jeder dieser grenzüberschreitenden Datenflüsse braucht einen eigenen validierten Übermittlungsmechanismus und eine eigene TIA — und der Mechanismus muss standhalten, wenn sich der Angemessenheitsstatus einer Rechtsordnung oder die Überwachungsgesetzgebung ändert, was mit Privacy Shield bereits einmal passiert ist.
Eine Pro-Region-Architektur — ein EU-Cluster für EU-Daten, ein US-Cluster für US-Daten und so weiter — tauscht betriebliche Einfachheit gegen einen deutlich kleineren grenzüberschreitenden Fußabdruck: Nur echte regionsübergreifende Anwendungsfälle (etwa ein globales Support-Ticket, das mehrere regionale Teams betrifft) brauchen einen Übermittlungsmechanismus, nicht der Standardfluss jeder einzelnen Anfrage. Für die meisten multinationalen Unternehmen mit nennenswert regulierten Datenkategorien (Kunden-PII, Mitarbeiterdaten, Gesundheits- oder Finanzdaten) ist das der sicherere Standard, auch wenn er mehr Infrastruktur- und Betriebsaufwand kostet.
Unternehmen, die bereits regionale Bereitstellungen für andere Rechtsordnungen betreiben, kennen die gleiche Logik aus den entsprechenden PDPL-Analysen für Saudi-Arabien und die VAE oder dem brasilianischen LGPD-Leitfaden — der EU/DSGVO-Fall hat lediglich die umfangreichste Durchsetzungspraxis und die meistzitierte Rechtsprechung (Schrems I und II) hinter sich.
Chinas PIPL und Open-Weight-Modelle: eine dritte Rechtsordnung einplanen
China ist neben der EU, den USA, Brasilien, Saudi-Arabien und den VAE eine dritte Rechtsordnung, die in diese Analyse gehört. Chinas Personal Information Protection Law (PIPL, seit 2021 in Kraft) und das Data Security Law regeln personenbezogene Daten, die in China verarbeitet werden, sowie jede Übermittlung ins Ausland. Eine ausgehende Übermittlung erfordert in der Regel eines von drei Instrumenten: eine Sicherheitsbewertung durch die Cyberspace Administration of China (CAC), einen zertifizierten Schutzmechanismus oder CAC-Standardvertragsklauseln — ein Genehmigungsregime, das sich von den DSGVO-SCCs unterscheidet und von einer anderen Behörde nach anderen Kriterien geführt wird. Wer EU- (oder andere) personenbezogene Daten über eine in China gehostete Inferenz-API leitet, setzt sich den Übermittlungsregeln der PIPL und Chinas National Intelligence Law zum staatlichen Zugriff aus — eine eigenständige rechtliche Zugriffsfrage neben der oben beschriebenen Schrems-II-/CLOUD-Act-Analyse, kein Ersatz dafür.
Das ist ein grundlegend anderes Risiko als die Nutzung eines chinesischen Open-Weight-Modells. Alibabas Qwen und DeepSeek veröffentlichen Open-Weight-Modelldateien, die einmalig heruntergeladen und vollständig auf eigener EU-Infrastruktur betrieben werden können — nach diesem Download gibt es keinen laufenden API-Aufruf mehr an einen in China stehenden Endpunkt, und keine Daten fallen unter das PIPL-Übermittlungsregime, sofern Sie selbst hosten und jede standardmäßig aktivierte Telemetrie- oder Update-Check-Funktion des umgebenden Tools deaktivieren. Das Rechtsordnungsrisiko eines chinesischen KI-Anbieters hängt an der gehosteten API-/Service-Beziehung, nicht an den Modellgewichten selbst. Siehe Löst lokales DeepSeek das China-Datenproblem? für die Unterscheidung zwischen gehostetem Dienst und Open Weights im Detail sowie den DSGVO-Risikovergleich zwischen Qwen, DeepSeek, Llama und Claude für eine Aufschlüsselung je Modell.
Das verallgemeinert sich über China hinaus: Open-Weight-Modelle — unabhängig vom Herkunftsland — sind der strukturelle Ermöglicher der Selbst-Hosting-Zeile im obigen Bereitstellungsvergleich. Ein Closed-Weight-Modell, selbst eines aus einer EU-Region, erfordert für jeden Inferenzaufruf weiterhin eine laufende API-Beziehung zu diesem Anbieter als Sub-Auftragsverarbeiter. Ein Open-Weight-Modell, das einmal heruntergeladen und auf eigener Infrastruktur betrieben wird, entfernt den Modellanbieter nach der Bereitstellung vollständig aus der Verarbeitungskette — es gibt keinen laufenden Sub-Auftragsverarbeiter zur Inferenzzeit zu erfassen, nur einen einmaligen Download zu dokumentieren. Das ist eine strukturell stärkere Souveränitätsposition, als zu bewerten, in welcher Region die API eines Anbieters zufällig gehostet wird — weil sie die Frage beseitigt, statt sie nur günstig zu beantworten.
📍 In einem Satz
Self-Hosting eines Open-Weight-Modells entfernt den Modellanbieter vollständig aus Ihrer Verarbeitungskette; Chinas PIPL bringt ein drittes, eigenständiges Übermittlungsregime ins Spiel, das für gehostete APIs gilt, nicht für selbst gehostete Open-Weight-Dateien, unabhängig vom Herkunftsland des Modells.
💬 In einfachen Worten
Wer eine Open-Weight-Modelldatei — von einem US-, EU- oder chinesischen Unternehmen — herunterlädt und vollständig auf eigenen Servern betreibt, sendet danach keine Prompts oder Ausgaben mehr an dieses Unternehmen zurück. Das Souveränitätsrisiko entsteht durch den Aufruf der gehosteten API eines Anbieters, nicht durch das Land, in dem das Modell ursprünglich trainiert wurde.
Ein Entscheidungsrahmen für IT-Einkäufer
Arbeiten Sie diese Schritte der Reihe nach ab
- 1Daten klassifizieren
Why it matters: Bestimmen Sie, ob die beteiligten Prompts, abgerufenen Dokumente und Ausgaben personenbezogene Daten nach Art. 4 Abs. 1 DSGVO sind und ob besondere Kategorien nach Art. 9 betroffen sind. Diese Klassifizierung ändert, welche Schutzmaßnahmen rechtlich erforderlich sind — nicht nur empfehlenswert. - 2Jeden Sub-Auftragsverarbeiter in der KI-Kette erfassen
Why it matters: Der Inferenz-Host, der Vektordatenbank- bzw. RAG-Abrufdienst, der Logging-/Observability-Anbieter und jeder Fine-Tuning- oder Evaluationsdienst sind jeweils eigene Sub-Auftragsverarbeiter mit eigenem Art.-28-AVV — nicht nur der primäre Modellanbieter. - 3Prüfen, ob ein Verarbeitungsschritt die EU/den EWR verlässt
Why it matters: Ein einzelner US-basierter Logging- oder Analytics-Aufruf mit EU-personenbezogenen Daten löst DSGVO Art. 44-49 aus, selbst wenn die Kerninferenz vollständig innerhalb der EU stattfindet. Prüfen Sie die gesamte Kette, nicht nur den Modell-Endpunkt. - 4Bereitstellungsmodell pro Datenklasse wählen
Why it matters: Selbst-Hosting oder eine EU-souveräne Cloud ist der risikoärmere Standard für regulierte oder kritische Daten; eine US-Hyperscaler-EU-Region kann für Daten mit geringerem Risiko akzeptabel sein, sobald ein validierter Übermittlungsmechanismus und eine TIA vorliegen. - 5Zentralisierte vs. Pro-Region-Architektur entscheiden
Why it matters: Wählen Sie für multinationale Bereitstellungen standardmäßig Pro-Region-Cluster, sofern kein validierter Übermittlungsmechanismus den geplanten regionsübergreifenden Fluss konkret und aktuell abdeckt. - 6Bewertung dokumentieren und DSB-/Rechtsfreigabe einholen
Why it matters: Eine dokumentierte Transfer-Impact-Assessment und DSFA sind das, was Aufsichtsbehörden und Prüfer tatsächlich verlangen. Eine informelle interne Prüfung, die nirgends festgehalten wird, ist kein Nachweis für Sorgfaltspflicht.
EU-Optionen für souveräne Cloud, die einen Blick wert sind
Wenn eigene Hardware mehr Betriebsaufwand ist, als Ihr Team leisten will, bieten mehrere in der EU ansässige Anbieter verwaltete GPU-Infrastruktur unter EU-Recht mit standardmäßigem EU-AVV. Dies ist keine erschöpfende Anbieterbewertung — prüfen Sie aktuelle Preise, Zertifizierungen und AVV-Bedingungen direkt, bevor Sie sich festlegen, und sehen Sie sich den vollständigen EU-Cloud-GPU-Vergleich für eine tiefere Preis- und Funktionsübersicht über sieben Anbieter an.
- Hetzner Cloud GPU — deutsches Unternehmen, deutsche Rechenzentren, Pauschalpreise ab €184/Monat, AVV sofort nach deutschem Recht verfügbar
- Scaleway GPU Instances — französisches Unternehmen (Iliad-Tochter), Stundenabrechnung ab €0,50/h, SecNumCloud-zertifiziert
- OVHcloud — französischer Multi-Region-EU-Anbieter (Frankreich, Deutschland, Polen, UK), SLA-gestützt, HDS-zertifiziert für Gesundheitsdaten
- STACKIT — deutscher Enterprise-Anbieter, TISAX-zertifiziert, typischerweise Verträge im Enterprise-Maßstab erforderlich
- Für Audit-Bereitschafts-Tools neben jeder dieser Bereitstellungsentscheidungen siehe Vanta für Compliance-Automatisierung — nützlich, um AVV- und Sub-Auftragsverarbeiter-Dokumentation zu verfolgen, unabhängig von der gewählten Infrastruktur.
Dies ist keine Rechtsberatung
Dieser Artikel erklärt allgemeine Konzepte zu Datensouveränität und grenzüberschreitender DSGVO-Übermittlung für die KI-Bereitstellungsplanung. Er ist keine Konformitätsfeststellung für Ihr Unternehmen, und kein hier beschriebenes Bereitstellungsmodell — selbstgehostet, EU-Region-Cloud oder EU-souveräne Cloud — ist pauschal "DSGVO-konform". Konformität hängt von Ihren konkreten Verarbeitungstätigkeiten, der Rechtsgrundlage, der Sub-Auftragsverarbeiterkette, der DSFA und der Risikobewertung ab — all das kann nur Ihr Datenschutzbeauftragter oder ein qualifizierter Rechtsberater für Ihr Unternehmen bewerten. Konsultieren Sie diese, bevor Sie auf Basis dieses Inhalts Bereitstellungsentscheidungen treffen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Datenresidenz und Datensouveränität bei KI-Workloads?
Datenresidenz betrifft den physischen/logischen Standort — wo Daten gespeichert und verarbeitet werden. Datensouveränität betrifft die Rechtszuständigkeit — welches Land mit seinen Gesetzen und staatlichen Zugriffsbefugnissen diese Daten und den verarbeitenden Anbieter erreicht, unabhängig vom Serverstandort. Ein in den USA ansässiger Anbieter kann volle EU-Datenresidenz bieten, während die Muttergesellschaft weiter US-Recht unterliegt — deshalb löst Residenz allein Souveränitätsbedenken nicht auf.
Erfüllt eine EU-Region von AWS, Azure oder Google Cloud die DSGVO für KI-Inferenz?
Sie adressiert die Datenresidenz und kann mit den richtigen vertraglichen und technischen Schutzmaßnahmen Teil eines validen Compliance-Ansatzes sein, beseitigt das Schrems-II-Risiko aber nicht allein — der Anbieter bleibt eine in den USA ansässige Einheit, die US-Überwachungsrecht unterliegt. Ob das für Ihre konkreten Daten akzeptabel ist, hängt von der Risikoklassifizierung, ergänzenden Schutzmaßnahmen und einer dokumentierten TIA ab. Das ist eine Einzelfallentscheidung, keine pauschale Antwort.
Was ist Schrems II und warum ist es für LLM-APIs relevant?
Schrems II ist das EuGH-Urteil von 2020, das den EU-US Privacy Shield für ungültig erklärte, weil US-Überwachungsrecht keinen im Wesentlichen gleichwertigen Schutz zum EU-Recht bietet. Für LLM-APIs bedeutet das: Das Leiten von EU-personenbezogenen Daten durch einen in den USA ansässigen Inferenzanbieter — selbst über einen EU-gehosteten Endpunkt — bringt ein Restrisiko beim rechtlichen Zugriff mit sich, das Standardvertragsklauseln allein ohne ergänzende Maßnahmen nicht vollständig lösen.
Was regeln DSGVO Art. 44-49 und wie gelten sie für KI?
Sie regeln jede Übermittlung personenbezogener Daten außerhalb der EU/des EWR: Art. 44 legt die Grundregel fest, Art. 45 betrifft Angemessenheitsbeschlüsse, Art. 46 betrifft Garantien wie Standardvertragsklauseln, Art. 47-49 betreffen verbindliche interne Vorschriften und enge Ausnahmen. Für KI gelten sie für jeden API-Aufruf, Log-Eintrag oder Telemetrie-Ereignis mit personenbezogenen Daten, das die EU/den EWR verlässt — nicht nur für Massenexporte.
Ist Selbst-Hosting eines LLM automatisch DSGVO-konform?
Nein. Selbst-Hosting innerhalb der EU entfernt für diesen konkreten Workload das Risiko der grenzüberschreitenden Übermittlung — eine echte und bedeutsame Risikoreduktion —, adressiert aber nicht jede DSGVO-Anforderung: Rechtsgrundlage, DSFA, Datenminimierung, Aufbewahrungsfristen und Sicherheitsmaßnahmen müssen weiterhin unabhängig vom Ausführungsort korrekt gehandhabt werden.
Was ist eine "souveräne Cloud" und wie unterscheidet sie sich von einer normalen EU-Region-Cloud?
In der Praxis beschreibt "souveräne Cloud" einen Anbieter, der sowohl seinen Sitz als auch seine rechtliche Domizilierung in der EU hat (nicht nur EU-Rechenzentren betreibt), sodass die Gesellschaft selbst — nicht nur der Serverstandort — außerhalb der US-Rechtszuständigkeit liegt. Die "EU-Region" eines in den USA ansässigen Anbieters bietet EU-Datenresidenz, aber in diesem Sinne keine EU-Souveränität, weil die Muttergesellschaft weiter eine US-Rechtsperson ist.
Sollte ein multinationales Unternehmen einen zentralen oder Pro-Region-KI-Cluster betreiben?
Pro-Region-Cluster sind für jede nennenswert regulierte Datenkategorie in der Regel der sicherere Standard, weil sie das Risiko grenzüberschreitender Übermittlung auf echte regionsübergreifende Anwendungsfälle begrenzen, statt jede Anfrage zur Übermittlung zu machen. Zentralisierte Cluster sind betrieblich einfacher, benötigen aber einen validierten Übermittlungsmechanismus und eine TIA für jeden regionalen ausgehenden Datenfluss — und dieser Mechanismus muss standhalten, wenn sich die Rechtslage ändert.
Was ist eine Transfer-Impact-Assessment (TIA) und brauchen wir eine für KI-Bereitstellungen?
Eine TIA ist eine dokumentierte Bewertung, ob Standardvertragsklauseln (oder ein anderer Übermittlungsmechanismus) angesichts des Rechts des Zielstaats angemessenen Schutz bieten — nach dem Schrems-II-Urteil erforderlich, sobald personenbezogene Daten die EU/den EWR unter SCCs verlassen. Wenn irgendein Teil Ihrer KI-Bereitstellung EU-personenbezogene Daten an einen Nicht-EU-Verarbeiter sendet, brauchen Sie eine — Umfang und Format sollte Ihr Datenschutzbeauftragter oder Rechtsberater bestätigen.
Kann eine EU-Tochtergesellschaft eines US-Unternehmens KI-Workloads hosten, um Schrems-II-Probleme zu vermeiden?
Das kann das Risiko spürbar reduzieren, wenn die EU-Tochtergesellschaft für diese Verarbeitung ein wirklich eigenständiger Verantwortlicher ist und die Muttergesellschaft keinen erzwungenen Zugriff auf die Daten hat — eine Tochtergesellschaftsstruktur allein löst Schrems-II-Bedenken aber nicht automatisch, wenn die US-Mutter Zugriffsrechte behält oder die Tochter weiter extraterritorialen US-Rechtsforderungen unterliegt. Das erfordert eine konkrete rechtliche Bewertung der Konzern- und Datenzugriffsstruktur, keine allgemeine Regel.
Gilt Chinas PIPL, wenn wir ein Open-Weight-Modell wie Qwen oder DeepSeek selbst hosten?
Für die laufende Verarbeitung in der Regel nicht. Die grenzüberschreitenden Übermittlungsregeln der PIPL gelten für Datenflüsse aus China heraus, was relevant ist, wenn Sie eine in China gehostete API aufrufen — ein selbst gehostetes Open-Weight-Modell, das vollständig auf eigener Infrastruktur läuft, sendet nach dem einmaligen Download keine Daten mehr nach China. Klären Sie mit Ihrem Datenschutzbeauftragten, ob eine Telemetrie- oder Update-Check-Funktion im umgebenden Tool trotzdem noch "nach Hause telefoniert", da dies eine Übermittlung wieder einführen würde.
Machen Open-Weight-Modelle DSGVO- bzw. Datensouveränitäts-Compliance einfacher als proprietäre APIs?
Sie entfernen ein strukturelles Risiko: Ein selbst gehostetes Open-Weight-Modell hat keinen laufenden Sub-Auftragsverarbeiter für die Inferenz, was die Sub-Auftragsverarbeiter-Kette verkürzt, die Ihr Datenschutzbeauftragter nach Art. 28 DSGVO erfassen muss. Andere DSGVO-Pflichten entfallen dadurch nicht — Rechtsgrundlage, DSFA, Sicherheitsmaßnahmen und Aufbewahrungsfristen gelten unabhängig vom verwendeten Modell weiter.