Claude auf AWS vs. Azure vs. Google Cloud: DSGVO-Datenresidenz im Vergleich (2026)
Ein praxisnaher Vergleich von Claude AI auf AWS Bedrock, Azure AI Foundry und Google Vertex AI — mit DPA-Analyse, Data-Residency-Optionen und einer pragmatischen Compliance-Strategie für europäische Unternehmen.
Zuletzt aktualisiert: Februar 2026 · Lesezeit: ~20 Min.
Rechtlicher Hinweis: Dieser Artikel stellt keine Rechtsberatung dar. Er spiegelt meine persönliche Einschätzung als IT-Leiter wider, basierend auf öffentlich zugänglichen Verträgen, Dokumentationen und über einem Jahrzehnt Enterprise-IT-Erfahrung. Für verbindliche rechtliche Bewertungen wenden Sie sich an Ihren Datenschutzbeauftragten oder einen qualifizierten Rechtsberater. Jede Organisation ist anders — was für meine funktioniert, muss nicht für Ihre funktionieren.
Die wichtigsten Erkenntnisse
- AWS Bedrock ist der einzige Anbieter mit garantierter EU-Datenresidenz für Claude (über EU Inference Profile)
- Azure AI Foundry hat Claude im Preview-Status — das bedeutet eingeschränkte DPA-Garantien und keine personenbezogenen Daten
- Google Vertex AI bietet keine EU-Datenresidenz für Claude, aber volle CDPA-Garantien auch für Preview-Modelle
- PII-Filter funktionieren nur bei Klartext — sie können PDFs, Bilder und Dokumente, die Claude als multimodalen Input akzeptiert, nicht scannen
- Der CLOUD Act ermöglicht US-Behörden den Zugriff auf Daten bei allen drei Anbietern, unabhängig vom Speicherort
- Meine Empfehlung: Azure + Google Cloud deckt alle drei großen Modellfamilien ab (GPT, Gemini, Claude) — Modellabdeckung schlägt Datenresidenz als strategische Priorität
TL;DR
Claude von Anthropic ist eines der leistungsfähigsten KI-Modelle am Markt. Aber Anthropic bietet kein direktes EU-Hosting an. Claude läuft ausschließlich über AWS Bedrock, Google Vertex AI oder Azure AI Foundry. Jeder dieser Anbieter handhabt den Datenschutz anders. Wer die Unterschiede nicht versteht, riskiert entweder Compliance-Verstöße oder blockiert sein Unternehmen unnötig bei der KI-Nutzung.
Dieser Artikel zeigt, wo die tatsächlichen Risiken liegen, wo die Vertragswerke Lücken haben und wie Sie als IT-Leitung eigenständig entscheiden können — ohne für jede KI-Anfrage den Datenschutzanwalt bemühen zu müssen.
1. Warum Claude AI in Europa zu hosten kompliziert ist
Anthropic, der Hersteller von Claude, ist ein US-Unternehmen mit Sitz in San Francisco. Anders als OpenAI (über Microsoft) oder Google (eigene Cloud) bietet Anthropic keinen eigenen europäischen Cloud-Dienst an. Stattdessen ist Claude als Drittanbieter-Modell über die Marktplätze der drei großen Cloud-Anbieter verfügbar:
- AWS Bedrock — Amazons KI-Plattform
- Google Vertex AI — Googles KI-Plattform
- Azure AI Foundry — Microsofts KI-Plattform (ehemals Azure AI Studio)
Klingt nach einer Standardsituation: Cloud-Vertrag abschließen, DPA dranhängen, fertig. Ist es aber nicht. Die drei Anbieter unterscheiden sich fundamental darin, wo die Daten tatsächlich verarbeitet werden — und das ist der Kern der DSGVO-Frage.
Die Subprozessor-Kette
Bei allen drei Anbietern sieht die Vertragskette identisch aus:
Ihr Unternehmen (Verantwortlicher)
└── Cloud-Anbieter (Auftragsverarbeiter) — DPA/CDPA + SCCs
└── Anthropic (Unterauftragsverarbeiter) — Subprozessor-Vertrag
Das bedeutet: Sie haben keinen direkten Vertrag mit Anthropic. Ihr Datenschutzverhältnis zu Anthropic läuft ausschließlich über den Cloud-Anbieter. Ob das ausreicht, hängt von der Qualität der DPAs ab — und davon, was die DPAs bei genauem Hinsehen tatsächlich garantieren.
2. Deployment vs. Endpunkt vs. Data Residency — Was für die DSGVO wirklich zählt
In Gesprächen mit der Geschäftsleitung oder dem DSB kommt es regelmäßig zu einem Missverständnis, das teuer werden kann. Drei Begriffe klingen ähnlich, meinen aber völlig verschiedene Dinge:
| Begriff | Was es bedeutet | DSGVO-Relevanz |
|---|---|---|
| Deployment | Das Modell ist in einem EU-Rechenzentrum installiert | Niedrig — sagt nichts über die Datenverarbeitung |
| Endpunkt | Die API-Adresse liegt in der EU (z.B. europe-west4) | Mittel — die Anfrage geht an einen EU-Server |
| Data Residency | Die ML-Verarbeitung (Inference) findet garantiert in der EU statt | Hoch — die einzige Garantie, die zählt |
Die kritische Erkenntnis: Ein EU-Endpunkt bedeutet nicht automatisch, dass Ihre Daten in der EU verarbeitet werden. Bei „Global Standard"-Deployments kann die eigentliche KI-Berechnung in die USA oder jedes andere Land geroutet werden, in dem der Anbieter oder seine Subprozessoren Rechenzentren betreiben.
Die drei Deployment-Modi im Detail
Data Zone / Regional (EU-Garantie vorhanden):
- ML-Verarbeitung bleibt garantiert innerhalb definierter EU-Regionen
- Vertragliche Zusicherung via DPA oder Produktkonfiguration
- Beispiel: AWS Bedrock EU Inference Profile, Google Vertex AI Regional (für eigene Gemini-Modelle)
Global Standard (EU-Endpunkt, aber globale Verarbeitung):
- API-Endpunkt liegt in der EU, Daten im Ruhezustand bleiben in der EU
- Aber: ML-Verarbeitung (Inference) kann weltweit stattfinden
- Beispiel: Azure AI Foundry für Claude, Google Vertex AI für Claude
EU Inference Profile (AWS-Spezifikum):
- Spezieller Mechanismus von AWS Bedrock mit dem Präfix
eu. - Verarbeitung auf sechs EU-Regionen beschränkt: Frankfurt, Irland, Paris, Stockholm, Mailand, Spanien
- Unveränderliche Regionsliste — AWS kann die Regionen nicht einseitig ändern
3. Claude Opus 4.6 auf AWS Bedrock vs. Google Vertex AI vs. Azure AI Foundry
Hier wird es konkret. Ich habe alle drei Plattformen analysiert — nicht die Marketing-Unterlagen, sondern die tatsächliche Datenlage und die Vertragswerke. Stand Februar 2026.
Claude-Modelle: Cloud-Anbieter-Vergleich
| Kriterium | AWS Bedrock | Google Vertex AI | Azure AI Foundry |
|---|---|---|---|
| Claude Opus 4.6 verfügbar | Ja | Ja | Ja |
| Claude Sonnet 4.6 verfügbar | Ja | Ja | Ja |
| Deployment in EU | Ja | Ja | Nein* |
| EU-Endpunkt | Ja | Ja | Ja |
| Data Residency EU | Ja (EU Inference Profile) | Nein (nur Global) | Nein (Global Standard) |
| Lifecycle-Status | GA | GA | Preview |
| Retirement-Datum | — | — | 1. Juni 2026 |
| Rechtliche Absicherung | EU Data Residency | SCCs + CDPA | SCCs + DPA |
| Schrems-III-Risiko | Keins | Vorhanden | Vorhanden |
* Azure: Claude wird über Anthropic-Server in den USA verarbeitet, nicht in Azure-Rechenzentren.
Ergebnis: AWS Bedrock ist der einzige Anbieter, der für Claude eine garantierte EU-Datenresidenz bietet. Google und Azure verarbeiten Daten potenziell global — was heute legal ist (dank SCCs + DPF), aber ein Zukunftsrisiko bei Schrems III darstellt.
Zum Vergleich: Wo stehen die Wettbewerber?
Diese Tabelle zeigt auch, warum eine Multi-Cloud-Strategie sinnvoll ist:
| Modell | AWS Bedrock | Google Vertex AI | Azure OpenAI |
|---|---|---|---|
| Claude (alle Versionen) | EU Data Residency | Nur Global | Nur Global Standard |
| GPT-4o / 4o-mini | Nicht verfügbar | Nicht verfügbar | EU Data Residency (7 Regionen) |
| GPT-5.2 | Nicht verfügbar | Nicht verfügbar | Eingeschränkt (1 Region) |
| Gemini 2.5 Pro/Flash | Nicht verfügbar | EU Data Residency | Nicht verfügbar |
| Gemini 3.x | Nicht verfügbar | Nur Global (Preview) | Nicht verfügbar |
Die Erkenntnis: Kein einzelner Cloud-Anbieter bietet EU-Datenresidenz für alle Top-Modelle. Wer das beste Modell und den besten Datenschutz will, braucht mindestens zwei Anbieter.
4. DPA-Vergleich: Microsoft vs. Google vs. AWS Auftragsverarbeitungsverträge
Ich habe die aktuellen Auftragsverarbeitungsverträge aller drei Anbieter analysiert. Die Ergebnisse sind ernüchternd — und in einem Punkt überraschend.
Microsoft DPA (September 2025)
Das Microsoft DPA ist ein umfassendes Vertragswerk von 27+ Seiten. Vier Stellen sind für diesen Anwendungsfall relevant:
Datenübermittlungen (S. 19): Der Kunde autorisiert Microsoft, Daten in die USA oder jedes andere Land zu übermitteln, in dem Microsoft oder seine Unterauftragsverarbeiter tätig sind. Die Übermittlung erfolgt unter Anwendung der SCCs von 2021.
Speicherorte (S. 20): Für Kerndienste speichert Microsoft ruhende Kundendaten in bestimmten geografischen Gebieten. Für EU-Datengrenzen-Dienste werden Kundendaten und personenbezogene Daten innerhalb der EU und EFTA verarbeitet. Aber: Azure AI mit Global Standard ist kein EU-Datengrenzen-Dienst.
Unterauftragsverarbeiter (S. 22-23): Microsoft informiert den Kunden 6 Monate im Voraus über neue Unterauftragsverarbeiter. Der Kunde hat ein Widerspruchsrecht mit Kündigungsmöglichkeit.
Preview-Klausel (S. 24) — der kritische Punkt: Für Previews gelten eingeschränkte Datenschutzgarantien. Preview-Daten dürfen in die USA oder jedes andere Land übermittelt, gespeichert und verarbeitet werden. Die Speicherort-Garantien für Kundendaten gelten nicht für Previews. Microsoft empfiehlt ausdrücklich, Previews nicht zur Verarbeitung personenbezogener oder regulatorisch relevanter Daten zu verwenden.
Was das für Claude auf Azure bedeutet: Da Claude auf Azure aktuell den Preview-Status hat (Retirement-Datum: 1. Juni 2026), gelten die eingeschränkten DPA-Bedingungen. Personenbezogene Daten sollten über Azure-Claude nicht verarbeitet werden.
Google CDPA (Cloud Data Processing Addendum)
Das Google CDPA ist strukturell anders aufgebaut als das Microsoft DPA:
Datenverarbeitung (Abschnitt 10.1): Kundendaten können in jedem Land verarbeitet werden, in dem Google oder seine Unterauftragsverarbeiter Einrichtungen unterhalten. Data Residency wird über die Produktkonfiguration gesteuert, nicht über das CDPA selbst.
Unterauftragsverarbeiter (Abschnitt 11): Google informiert den Kunden 30 Tage vor dem Einsatz neuer Unterauftragsverarbeiter. Der Kunde hat 90 Tage Widerspruchsfrist mit ordentlicher Kündigung.
SCCs (Anhang 3): Google hat eine eigene SCC-Struktur mit mehreren Varianten (Controller-to-Processor, Processor-to-Processor etc.). Bei Widersprüchen haben die SCCs Vorrang vor dem CDPA.
Preview-Klausel: Keine. Das ist die Überraschung. Das Google CDPA enthält keine Einschränkung der Datenschutzgarantien für Preview- oder Beta-Modelle. Die vollen CDPA-Bedingungen gelten auch für Preview-Modelle auf Vertex AI.
AWS DPA
Das AWS GDPR Data Processing Addendum ist in die Nutzungsbedingungen integriert und gilt automatisch für alle Kunden weltweit. AWS bietet mit dem EU Inference Profile einen technischen Mechanismus, der die Datenverarbeitung auf EU-Regionen beschränkt — das ist eine technische Garantie, nicht nur eine vertragliche.
AWS ist außerdem unter dem EU-US Data Privacy Framework zertifiziert und stellt SCCs bereit. Für Claude-Modelle auf AWS Bedrock ist das Preview-Problem nicht relevant — alle Claude-Modelle haben GA-Status.
DPA-Vergleichstabelle
| Aspekt | Microsoft DPA | Google CDPA | AWS DPA |
|---|---|---|---|
| SCCs enthalten | Ja (2021) | Ja (Anhang 3, mehrere Varianten) | Ja |
| DPF-Zertifizierung | Ja | Ja | Ja |
| Preview-Einschränkung | Ja — S. 24: keine Speicherort-Garantien | Nein — volle Garantien | N/A (Claude ist GA) |
| Subprozessor-Vorlaufzeit | 6 Monate | 30 Tage | Zu prüfen |
| Widerspruchsrecht | Ja + Kündigung | Ja + Kündigung (90 Tage) | Ja |
| Data Zone im DPA verankert | Nein (Produktebene) | Nein (Produktebene) | EU Inference Profile |
| Globale Verarbeitung erlaubt | Ja (bei Global Standard) | Ja (Standard) | Ja (ohne eu.-Profil) |
| Vertragliche Datenlöschung | 90 Tage nach Vertragsende | 180 Tage (max.) | Vertragsgemäß |
5. Preview vs. GA: Warum Claudes Status für die DSGVO-Konformität entscheidend ist
Dieser Punkt wird in den meisten Unternehmen übersehen und verdient besondere Aufmerksamkeit.
Was bedeutet Preview?
Ein Modell im Preview-Status:
- Ist nicht allgemein verfügbar (keine General Availability)
- Kann jederzeit geändert oder abgeschafft werden
- Hat ein festes Retirement-Datum
- Bietet in der Regel kein SLA
Wie lange dauern Preview-Phasen typischerweise?
Preview-Phasen sind nicht unbegrenzt — sie folgen einem vorhersehbaren Muster:
| Anbieter | Typische Preview-Dauer | Weg zur GA | Beispiel |
|---|---|---|---|
| Microsoft Azure | 3–6 Monate | Microsoft setzt ein Retirement-Datum; Modell wird entweder GA oder entfernt | Claude auf Azure: Preview seit Ende 2025, Retirement-Datum 1. Juni 2026 |
| Google Cloud | 2–4 Monate | Kürzere Zyklen; Google tendiert dazu, Modelle schneller in GA zu überführen | Gemini-Modelle erreichen GA typischerweise innerhalb von Wochen bis wenigen Monaten |
| AWS | Selten relevant | AWS lanciert Modelle tendenziell direkt im GA-Status | Claude auf Bedrock: GA vom ersten Tag an |
Die praktische Konsequenz: Preview ist ein temporärer Zustand. Wenn Sie Claude auf Azure evaluieren und der Preview-Status ein Blocker für personenbezogene Daten ist, schauen Sie wahrscheinlich auf 3–6 Monate Wartezeit bis GA. Das ist keine dauerhafte Einschränkung — es ist eine Timing-Frage. Planen Sie entsprechend: Nutzen Sie Azure-Claude jetzt für nicht-personenbezogene Daten und bewerten Sie neu, sobald GA angekündigt wird.
Achtung bei Retirement-Daten. Ein Preview-Modell mit Retirement-Datum wird nicht automatisch GA — es kann auch eingestellt werden. Prüfen Sie immer die Model-Lifecycle-Seite des Anbieters, bevor Sie Produktions-Workflows auf Preview-Modellen aufbauen.
Warum ist das DSGVO-relevant?
Die Antwort hängt davon ab, bei welchem Anbieter das Modell läuft:
| Anbieter | Preview-Regelung | Konsequenz für personenbezogene Daten |
|---|---|---|
| Microsoft Azure | DPA S. 24: Eingeschränkte Garantien, Speicherort-Garantien gelten nicht | Keine personenbezogenen Daten bei Previews |
| Google Cloud | CDPA enthält keine Preview-Einschränkung | Keine vertragliche Einschränkung |
| AWS | Claude ist GA — Preview-Problem existiert nicht | Reguläre DPA-Bedingungen gelten |
Claude auf Azure ist derzeit Preview. Konkret: Die Garantien des Microsoft DPA bezüglich Speicherort und Datenverarbeitung gelten für Claude auf Azure nicht. Preview-Daten können laut DPA in die USA oder jedes andere Land übermittelt werden, ohne dass die üblichen Schutzmechanismen greifen.
Claude auf Google Vertex AI hat zwar auch keine EU-Datenresidenz, aber die vollen CDPA-Bedingungen gelten — es gibt keine Preview-Abschwächung.
Pragmatische Empfehlung
Für Preview-Modelle auf Azure gilt die einfache Regel: Nur Daten ohne Personenbezug. Das umfasst:
- Quellcode-Analyse und -Generierung
- Technische Dokumentation
- Aggregierte Geschäftsdaten ohne Namen
- Interne Wissensdatenbanken ohne Personenbezug
Nicht geeignet für Preview-Modelle auf Azure:
- Dokumente mit Sachbearbeiternamen
- Kundenkommunikation
- HR-Daten
- Alles, was direkt oder indirekt auf natürliche Personen rückführbar ist
6. PII-Schutz bei KI-Modellen: Warum Filter versagen und was stattdessen funktioniert
Das Problem
Wie verhindert man, dass personenbezogene Daten (PII — Personally Identifiable Information) in ein KI-Modell gelangen? Besonders relevant bei:
- Preview-Modellen auf Azure (wo personenbezogene Daten tabu sind)
- Dokumenten mit Sachbearbeiternamen, Ansprechpartnern, E-Mail-Adressen
- Geschäftsprozessen, die Kunden- oder Mitarbeiterdaten berühren
Der teure Weg: PII-Filter als Proxy
Technisch gibt es verschiedene Lösungen für automatische PII-Erkennung:
- Azure AI Language — PII Detection: Erkennt automatisch Namen, E-Mails, Telefonnummern und kann sie maskieren
- Microsoft Presidio (Open Source): Lokale PII-Erkennung, regelbasiert und ML-gestützt
- Azure API Management (APIM) als Gateway: Zentraler Proxy vor allen KI-Modellen mit PII-Policy
Kosten und Einschränkungen:
| Aspekt | Detail |
|---|---|
| Kosten | Ca. 1 EUR pro 1.000 Texteinheiten; bei 100k Anfragen/Monat ca. 100 EUR |
| Latenz | 50-200ms zusätzlich pro Anfrage |
| Nur Klartext | PII-Filter können ausschließlich Klartext scannen — nichts anderes |
| Blind bei Datei-Uploads | Das eigentliche Problem: Claude ist multimodal und akzeptiert PDFs, Bilder und Dokumente als Input. PII-Filter sitzen als Text-Proxy davor und können binäre Datei-Uploads überhaupt nicht scannen. Ein PDF mit Kundennamen, ein Bild eines unterschriebenen Vertrags, eine gescannte Rechnung — alles passiert den Filter völlig unerkannt. |
| Base64-Inhalte | Als Base64 kodierte Dokumente (üblich bei API-Aufrufen) sind für PII-Filter unsichtbar |
| Kein 100% Schutz | Selbst bei Klartext: Falsch-positive und falsch-negative Ergebnisse unvermeidbar |
Das ist eine fundamentale architektonische Limitierung, keine Randnotiz. PII-Filter wurden für eine reine Text-Welt entworfen. Moderne KI-Modelle wie Claude akzeptieren Rich-Media-Input — und die Filter kommen nicht hinterher. Man wiegt sich in falscher Sicherheit: Der Filter erkennt „Hans Müller" im Text-Prompt, lässt aber das PDF mit 500 Kundendatensätzen ungeprüft durch.
Der pragmatische Weg: Drei Säulen statt teurer Filter
In der Praxis hat sich eine Kombination aus drei Maßnahmen als wirksamer und günstiger erwiesen als rein technische PII-Filter:
Säule 1: Direkt in der Anwendung verhindern
Statt einen Filter nachzuschalten, bauen Sie den Schutz in Ihre Anwendung ein:
- Prompts so gestalten, dass keine personenbezogenen Daten benötigt werden
- Bei Dokumenten-Analyse: Relevante Abschnitte extrahieren statt ganzes Dokument senden
- Bei Datenbank-Abfragen: Aggregierte Daten senden statt Einzeldatensätze
- System-Prompts mit expliziter Anweisung, personenbezogene Daten in der Antwort zu vermeiden
Säule 2: IT-Richtlinie mit klaren Regeln
Eine aktualisierte IT-Richtlinie (V2) sollte enthalten:
- Klare Unterscheidung zwischen Data Zone und Global Standard
- Explizite Regelung für Preview vs. GA-Modelle
- Freigabematrix nach Deployment-Typ und Datenkategorie
- Verantwortlichkeiten für IT-Leitung, DSB und ISB
Säule 3: Schulung und Awareness
- Praktische Schulung für alle Mitarbeiter, die KI-Tools nutzen
- Konkrete Beispiele: Was darf gefragt werden, was nicht?
- Regelmäßige Updates bei Statusänderungen (Preview zu GA)
Wann lohnt sich ein technischer PII-Filter doch?
| Anwendungsfall | PII-Filter empfohlen? |
|---|---|
| Entwickler-Tools (Claude Code, IDE-Plugins) | Nein — Quellcode hat keinen Personenbezug |
| Interne Wissensdatenbank-Abfragen | Nein — wenn die Datenbank keine PII enthält |
| Dokumentenanalyse mit Kundendaten | Ja — Rechnungen, Verträge, Korrespondenz |
| Analyse von HR-Dokumenten | Ja — Lebensläufe, Zeugnisse |
| Batch-Verarbeitung großer Textmengen | Ja — wenn Personenbezug nicht ausgeschlossen |
Die Kernaussage: PII-Filter sind kein Allheilmittel. Sie funktionieren nur bei Klartext, während moderne KI-Modelle wie Claude multimodal sind — PDFs, Bilder und Dokumente akzeptieren, die PII-Filter überhaupt nicht scannen können. Dazu kommen Latenz und Kosten. Die bessere Strategie ist, den Personenbezug gar nicht erst in den KI-Workflow zu bringen — durch Anwendungsarchitektur, klare Richtlinien und Mitarbeiter-Schulung.
7. CLOUD Act und EU-Daten: Das Risiko, das kein Vertrag beseitigt
Bei allen drei Cloud-Anbietern gibt es ein Restrisiko, das weder vertragliche Klauseln noch technische Maßnahmen vollständig beseitigen können: den US CLOUD Act (Clarifying Lawful Overseas Use of Data Act).
Was ist der CLOUD Act?
Der CLOUD Act von 2018 ermächtigt US-Behörden, von US-Unternehmen die Herausgabe von Daten zu verlangen — unabhängig davon, wo diese Daten gespeichert sind. Das gilt auch für Daten in EU-Rechenzentren.
Wen betrifft es?
Alle drei Anbieter sind US-Unternehmen:
- Microsoft (Redmond, WA)
- Amazon/AWS (Seattle, WA)
- Google/Alphabet (Mountain View, CA)
Und: Anthropic als Subprozessor ist ebenfalls ein US-Unternehmen (San Francisco, CA).
Was tun die Anbieter dagegen?
Alle drei haben Gegenmaßnahmen implementiert:
| Maßnahme | Microsoft | AWS | |
|---|---|---|---|
| Kundenbenachrichtigung | Ja, soweit nicht gesetzlich verboten | Ja, soweit möglich | Ja |
| Weiterleitung an Kunden | Versucht, Behörde an Kunden zu verweisen | Fordert betroffene Person auf, sich an Kunden zu wenden | Ja |
| Rechtliche Anfechtung | Prüft Rechtsgrundlage | Prüft Rechtmäßigkeit | Prüft und wehrt ab |
| Verschlüsselung | Kundenseitige Schlüssel möglich | CMEK verfügbar | KMS mit kundenseitigem Schlüssel |
Ehrliche Bewertung
Der CLOUD Act ist ein Restrisiko, das alle US-Cloud-Anbieter betrifft. Weder EU Data Residency noch Verschlüsselung schützen vollständig gegen eine US-Gerichtsanordnung.
Aber: Dieses Risiko besteht identisch bei jeder Nutzung von Microsoft 365, Azure, AWS oder Google Workspace. Wenn Ihr Unternehmen diese Dienste bereits nutzt (was bei fast allen der Fall ist), ist das CLOUD-Act-Risiko durch Claude nicht größer als Ihr bestehendes Risiko durch die aktuelle Cloud-Nutzung.
Die pragmatische Sicht: Das CLOUD-Act-Risiko ist kein Argument gegen Claude — solange Sie Microsoft/Google/AWS bereits für andere Dienste nutzen.
8. Schrems III: Das strategische Risiko
Aktuelle Lage
Das EU-US Data Privacy Framework (DPF) ist seit Juli 2023 gültig und bildet die rechtliche Grundlage für Datentransfers in die USA. Alle drei Cloud-Anbieter sind DPF-zertifiziert.
Das Risiko
Max Schrems und seine Organisation noyb haben das DPF vor dem EuGH angefochten. Sollte der EuGH das DPF kippen (wie bereits bei Safe Harbor / Schrems I und Privacy Shield / Schrems II geschehen), hätte das folgende Auswirkungen:
| Szenario | EU Data Residency | Global Standard + SCCs |
|---|---|---|
| DPF bleibt gültig | Kein Risiko | Kein Risiko |
| DPF wird gekippt | Kein Risiko (Daten bleiben in EU) | Erhöhtes Risiko (SCCs allein sind schwächer) |
| DPF wird gekippt + SCCs verschärft | Kein Risiko | Hohes Risiko (Transfer Impact Assessment wird Pflicht) |
Die Schlussfolgerung: Wer auf EU Data Residency setzt, ist von Schrems III nicht betroffen. Wer auf Global Standard + SCCs setzt, trägt ein strategisches Risiko. Das ist kein aktuelles Compliance-Problem, aber ein Faktor für die mittelfristige Planung.
9. Freigabematrix: IT-Autonomie ohne Anwalt
Das Problem in der Praxis
In vielen Unternehmen muss die IT-Leitung für jede KI-Entscheidung den Datenschutzanwalt einschalten. Das bremst Innovation und kostet Zeit. Eine Freigabematrix löst dieses Problem, indem sie klare Regeln definiert, wann die IT eigenständig entscheiden darf.
Die Matrix
Achse 1 — Deployment-Typ:
- A: EU Data Residency / EU Inference Profile
- B: Global Standard mit DPA + SCCs (GA-Modell)
- C: Global Standard mit DPA + SCCs (Preview-Modell)
Achse 2 — Datenkategorie:
- I: Keine personenbezogenen Daten (Quellcode, Fachdaten, aggregierte Zahlen)
- II: Interne Daten mit indirektem Personenbezug (Firmendaten mit Ansprechpartnern)
- III: Personenbezogene Daten (Mitarbeiterdaten, Kundendaten)
- IV: Besondere Kategorien (Art. 9 DSGVO — Gesundheitsdaten, religiöse Überzeugungen etc.)
Entscheidungsmatrix
| Kat. I (kein PB) | Kat. II (indirekter PB) | Kat. III (PB) | Kat. IV (Art. 9) | |
|---|---|---|---|---|
| A: EU Data Residency | IT-Leitung allein | IT-Leitung allein | IT + DSB | Nicht zulässig* |
| B: Global Standard (GA) | IT-Leitung allein | IT + DSB | IT + DSB + Anwalt | Nicht zulässig* |
| C: Global Standard (Preview) | IT-Leitung allein | IT + DSB | Nicht zulässig (Azure) | Nicht zulässig* |
* Art. 9 DSGVO-Daten erfordern immer eine DSFA und explizite Rechtsgrundlage.
Farbcode:
- IT-Leitung allein = Die IT kann eigenständig entscheiden und freigeben
- IT + DSB = Abstimmung mit dem Datenschutzbeauftragten erforderlich
- IT + DSB + Anwalt = Externe datenschutzrechtliche Prüfung nötig
- Nicht zulässig = Darf unter den gegebenen Bedingungen nicht freigegeben werden
Preview-Sonderregel beachten
Diese Matrix zeigt den kritischen Unterschied: Bei Azure-Preview-Modellen ist die Verarbeitung personenbezogener Daten nicht zulässig — nicht weil es technisch unmöglich wäre, sondern weil die vertraglichen Garantien des Microsoft DPA für Previews nicht gelten.
Bei Google gibt es diese Einschränkung nicht: Das CDPA enthält keine Preview-Abschwächung, sodass die regulären Bedingungen auch für Preview-Modelle auf Vertex AI gelten.
10. Lücken in bestehenden IT-Richtlinien
Viele Unternehmen haben bereits eine IT-Richtlinie zur KI-Nutzung. Typischerweise decken diese den Freigabeprozess, Verbote für sensible Daten und eine Liste freigegebener Systeme ab.
Was typische V1-Richtlinien nicht abdecken
Nach meiner Analyse fehlen in den meisten bestehenden Richtlinien vier Punkte:
-
Keine Unterscheidung zwischen Data Zone und Global Standard. Die Richtlinie behandelt alle Cloud-Dienste gleich, obwohl der Datenschutz-Unterschied erheblich ist.
-
Keine Unterscheidung zwischen Preview und GA. Ein Modell im Preview-Status hat auf Azure andere DPA-Bedingungen als ein GA-Modell — das muss in der Richtlinie abgebildet werden.
-
Keine Berücksichtigung der Subprozessor-Kette. Wenn M365 Copilot (mit vollem Datenzugriff inklusive Art. 9 DSGVO) freigegeben ist, aber Claude als Subprozessor in Copilot integriert wird (seit Januar 2026), gilt die Freigabe implizit auch für Claude — ohne dass das geprüft wurde.
-
Claude fehlt auf der Freigabeliste. Modelle werden ständig aktualisiert, neue Anbieter kommen hinzu, Deployment-Modi ändern sich. Eine statische Liste veraltet schnell.
Empfehlung: IT-Richtlinie V2
Eine aktualisierte Richtlinie sollte:
- Die Freigabematrix aus Abschnitt 9 integrieren
- Deployment-Typen (Data Zone vs. Global Standard) als eigenständiges Kriterium führen
- Preview vs. GA als Freigabekriterium berücksichtigen
- Einen dynamischen Anhang mit der aktuellen Freigabeliste haben
- Einen regelmäßigen Überprüfungszyklus (quartalsweise) definieren
11. Prüfauftrag an den Datenschutzanwalt: Effizient und anbieterübergreifend
Den Prüfauftrag richtig formulieren
Ein häufiger Fehler: Unternehmen lassen jeden Cloud-Anbieter separat prüfen. Das ist teuer und unnötig, denn der Sachverhalt ist bei allen drei identisch:
EU-Endpunkt + Global Standard + DPA/CDPA + SCCs + US-Subprozessor
Meine These zur Prüfung
- GA + Global Standard + DPA + SCCs = DSGVO-konform — auch mit personenbezogenen Daten (unter aktueller Rechtslage)
- Preview + Global Standard + keine personenbezogenen Daten = unproblematisch — DSGVO greift nicht bei Daten ohne Personenbezug
Prüffragen für den Anwalt
- Bestätigung, dass GA-Modelle im Global Standard unter SCCs + DPA DSGVO-konform eingesetzt werden können
- Bestätigung, dass Preview-Modelle mit nicht-personenbezogenen Daten keine DSGVO-Relevanz haben
- Übertragbarkeit der Prüfung auf alle drei Anbieter (einmalige Prüfung statt dreifach)
- Notwendigkeit von Transfer Impact Assessment (TIA) und Datenschutz-Folgenabschätzung (DSFA)
- Bewertung der Subprozessor-Kette: Reicht der Vertrag über den Cloud-Anbieter?
12. Beste Cloud-Strategie für Claude AI in Europa: Azure + Google Cloud
Warum kein einzelner Anbieter ausreicht
Die Analyse zeigt: Kein einzelner Anbieter bietet für alle Modelle das optimale Datenschutzniveau. Die empfohlene Strategie kombiniert zwei Anbieter.
Die empfohlene Kombination
Primär: Azure (Microsoft) — die meisten haben es bereits
- M365 Copilot, Teams, Office sind in den meisten Unternehmen Standard
- GPT-4o/4o-mini mit EU Data Residency verfügbar
- Bestehende Vertragsbeziehung und DPA vorhanden
- Für Claude: Akzeptabel für nicht-personenbezogene Daten (Preview-Status beachten — temporär, GA voraussichtlich H2 2026)
Sekundär: Google Cloud (Vertex AI) — Gemini-Modelle aktuell vorn
- Gemini 2.5 Pro und Flash mit EU Data Residency verfügbar
- Gemini-Modelle sind aktuell bei vielen Benchmarks führend
- Claude auf Vertex AI: Global Standard, aber volle CDPA-Garantien (keine Preview-Einschränkung)
- Der strategische Vorteil: Mit Azure + Google decken Sie GPT, Gemini und Claude ab — alle drei großen Modellfamilien
Optional für strikte EU-Datenresidenz: AWS Bedrock
- Einziger Anbieter mit EU Data Residency für Claude — hinzufügen, wenn Ihre Compliance-Anforderungen garantierte EU-Verarbeitung für personenbezogene Daten mit Claude zwingend erfordern
- Für die meisten Unternehmen reicht der pragmatische Drei-Säulen-Ansatz (Anwendungsarchitektur + IT-Richtlinie + Schulung) aus
Zeitlicher Fahrplan
Sofort umsetzbar (Q1 2026):
- Azure AI Foundry einrichten für GPT-Modelle (EU Data Residency) und Claude (nicht-personenbezogene Daten)
- Google Vertex AI einrichten für Gemini-Modelle (EU Data Residency) und Claude (volle CDPA-Garantien)
- Pragmatischen PII-Ansatz starten: Anwendungsebene + IT-Richtlinie aktualisieren
Kurzfristig (Q2 2026):
- IT-Richtlinie V2 mit Freigabematrix einführen
- Prüfauftrag an Datenschutzanwalt (einmalig, anbieterübergreifend)
- Schulungsprogramm für Mitarbeiter aufsetzen
Mittelfristig (H2 2026):
- Neu bewerten, sobald Claude GA auf Azure erreicht (voraussichtlich nach Juni 2026) — das schaltet personenbezogene Anwendungsfälle frei
- Evaluieren, ob AWS Bedrock als dritte Plattform für strikte EU Data Residency benötigt wird
- Data-Zone-Entwicklung bei Azure und Google beobachten
Strategisch (2027+):
- Schrems-III-Urteil beobachten und Strategie ggf. anpassen
- Bewerten, ob Anthropic selbst EU-Hosting anbietet
- Modelllandschaft neu evaluieren — das beste Modell von heute muss nicht das von morgen sein
13. Cloud-Anbieter-Scoring: AWS vs. Azure vs. Google für Enterprise-KI
Lassen Sie mich bei der Gewichtung ehrlich sein. Nach der Analyse aller Verträge, DPAs und technischen Details bin ich zu einer pragmatischen Erkenntnis gekommen: EU Data Residency ist wichtig, aber nicht der entscheidende Faktor. Warum? Der CLOUD Act bedeutet, dass die US-Regierung jeden dieser Anbieter — Microsoft, Google, Amazon — zur Herausgabe von Daten zwingen kann, egal wo sie gespeichert sind. Ob Ihre Daten in Frankfurt oder Virginia liegen, eine US-Gerichtsanordnung sticht Ihr DPA.
Was also zählt wirklich bei der Wahl einer Cloud-Plattform? Modellabdeckung. Die KI-Landschaft bewegt sich wahnsinnig schnell. OpenAI führt ein Quartal, Anthropic das nächste, Google überrascht mit Gemini im übernächsten. Wenn Sie sich auf einen Anbieter festlegen, werden Sie abgehängt.
Cloud-Anbieter-Bewertung für Claude (Enterprise-Einsatz)
| Kriterium (Gewichtung) | AWS Bedrock | Google Vertex AI | Azure AI Foundry |
|---|---|---|---|
| Modellabdeckung (30%) | 5/10 (Claude + OSS) | 9/10 (Gemini + Claude) | 9/10 (GPT + Claude) |
| EU Data Residency (15%) | 10/10 | 3/10 | 3/10 |
| DPA-Qualität (15%) | 8/10 | 8/10 | 7/10 |
| Preview/GA-Status (10%) | 10/10 (GA) | 10/10 (GA) | 4/10 (Preview) |
| Bestehende Vertragsbeziehung (15%) | 4/10 | 5/10 | 9/10 |
| Ökosystem & Integration (10%) | 6/10 | 8/10 | 9/10 (M365, Copilot) |
| Kosten/Verfügbarkeit (5%) | 8/10 | 8/10 | 7/10 |
| Gewichtete Gesamtbewertung | 6,6/10 | 7,3/10 | 7,2/10 |
Multi-Cloud-Bewertung (alle Modelle)
| Strategie | Modellabdeckung | Datenschutz | Komplexität | Empfehlung |
|---|---|---|---|---|
| Nur Azure | Hoch (GPT + Claude) | Mittel | Niedrig | Machbar, aber kein Gemini |
| Nur Google | Hoch (Gemini + Claude) | Mittel bis Hoch | Niedrig | Machbar, aber kein GPT |
| Nur AWS | Eingeschränkt (Claude + OSS) | Hoch | Niedrig | Zu eng für die meisten |
| Azure + Google | Maximal (GPT + Gemini + Claude) | Mittel bis Hoch | Mittel | Empfohlen |
| Azure + Google + AWS | Maximal | Maximal | Hoch | Nur wenn EU Data Residency für Claude Pflicht ist |
Meine Empfehlung
Azure + Google Cloud. Punkt.
Hier die Begründung:
Azure — haben Sie wahrscheinlich schon. Microsoft 365, Teams, Copilot sind in den meisten Unternehmen Standard. GPT-4o und GPT-4o-mini kommen mit EU Data Residency. Sie haben einen bestehenden Vertrag, ein bestehendes DPA, und Ihr Einkauf kennt den Prozess. Für Claude auf Azure: Akzeptabel für nicht-personenbezogene Daten (Preview-Status im Hinterkopf behalten — er ist temporär).
Google Cloud — das ist die zweite Plattform, die Sie brauchen. Gemini 2.5 Pro und Flash sind aktuell wirklich beeindruckend und mit EU Data Residency verfügbar. Claude auf Vertex AI läuft als Global Standard, aber mit vollen CDPA-Garantien (keine Preview-Einschränkung). Und hier kommt das strategische Argument: Das KI-Modell-Rennen ist noch lange nicht entschieden. Alle paar Monate übernimmt ein anderer Anbieter die Führung. Mit Azure + Google Cloud haben Sie Zugang zu GPT, Gemini und Claude — alle drei großen Modellfamilien abgedeckt. Sie sind nie eingesperrt, nie abgehängt.
Was ist mit AWS? AWS Bedrock ist die technisch stärkste Option für EU Data Residency mit Claude — keine Frage. Wenn Ihr Compliance-Team auf garantierter EU-Verarbeitung für personenbezogene Daten mit Claude besteht, fügen Sie AWS als dritte Plattform hinzu. Aber für die meisten Unternehmen ist die zusätzliche operative Komplexität eines dritten Cloud-Anbieters nicht gerechtfertigt, wenn der pragmatische Drei-Säulen-PII-Ansatz (Verhinderung auf Anwendungsebene + IT-Richtlinie + Schulung) die Datenschutzseite effektiv abdeckt.
Das Fazit: In einer Welt, in der der CLOUD Act existiert und KI-Modelle sich jedes Quartal gegenseitig überholen, schlägt Modellabdeckung die Datenresidenz als strategische Priorität. Decken Sie Ihre Basis mit zwei Plattformen ab, die Ihnen Zugang zu allem geben, handhaben Sie personenbezogene Daten pragmatisch und übertreiben Sie es nicht auf der Compliance-Seite.
Häufig gestellte Fragen
Ist Claude DSGVO-konform? Claude selbst ist ein KI-Modell, kein Dienst — die DSGVO-Konformität hängt davon ab, wie und wo Sie es einsetzen. Auf AWS Bedrock mit EU Inference Profile verarbeitet Claude Daten ausschließlich in der EU. Auf Azure und Google Cloud können Daten global verarbeitet werden, abgesichert durch Standardvertragsklauseln.
Kann ich Claude mit personenbezogenen Daten in der EU nutzen? Ja, aber nur auf AWS Bedrock mit EU Inference Profile (garantierte EU-Datenresidenz) oder auf Google Vertex AI / Azure mit GA-Modellen unter vollen DPA-Bedingungen. Claude auf Azure ist aktuell Preview — das bedeutet, Microsofts DPA-Speichergarantien gelten nicht. Vermeiden Sie dort personenbezogene Daten bis zur GA-Freigabe.
Was ist der Unterschied zwischen Data Residency und einem EU-Endpunkt? Ein EU-Endpunkt bedeutet, dass Ihre API-Anfrage an einem EU-Server ankommt. Data Residency bedeutet, dass die eigentliche KI-Verarbeitung (Inference) in der EU stattfindet. Nur Data Residency bietet eine belastbare DSGVO-Garantie — ein EU-Endpunkt allein verhindert keine globale Verarbeitung.
Hebelt der CLOUD Act den DSGVO-Schutz aus? Der CLOUD Act erlaubt US-Behörden, US-Unternehmen (Microsoft, Google, Amazon, Anthropic) zur Herausgabe von Daten zu zwingen — unabhängig vom Speicherort. Dieses Restrisiko besteht gleichermaßen bei allen US-Cloud-Diensten, die Sie bereits nutzen. EU Data Residency und Verschlüsselung bieten Schutzschichten, können eine US-Gerichtsanordnung aber nicht vollständig verhindern.
Wie lange dauert die Preview-Phase von Claude auf Azure? Typischerweise 3–6 Monate. Claude auf Azure ist seit Ende 2025 im Preview mit Retirement-Datum 1. Juni 2026. Es kann in GA übergehen oder ersetzt werden. Prüfen Sie immer die Model-Lifecycle-Seite des Anbieters.
Welcher Cloud-Anbieter ist am besten für Claude in Europa? Für DSGVO-Datenresidenz: AWS Bedrock. Für Modellabdeckung (GPT + Gemini + Claude): Azure + Google Cloud kombiniert. Meine Empfehlung ist Azure + Google Cloud für strategische Flexibilität, mit AWS als optionale Ergänzung für strikte EU-Datenresidenz-Anforderungen.
Quellenverzeichnis
Analysierte Vertragswerke
- Microsoft DPA (Datenschutznachtrag), letzte Aktualisierung 1. September 2025
- Google CDPA (Zusatz zur Verarbeitung von Cloud-Daten)
- AWS DSGVO-Compliance Whitepaper und DPA
Cloud-Anbieter-Dokumentation
- AWS Bedrock EU Inference Profile: docs.aws.amazon.com/bedrock
- Google Vertex AI Data Residency: cloud.google.com/vertex-ai/docs/general/data-residency
- Azure AI Foundry Modellkatalog: ai.azure.com
- Azure Data Residency: azure.microsoft.com/explore/global-infrastructure/data-residency
Rechtliche Grundlagen
- EU-DSGVO (Verordnung 2016/679)
- EU-US Data Privacy Framework (Angemessenheitsbeschluss 2023)
- Standardvertragsklauseln (Durchführungsbeschluss 2021/914/EG)
- Art. 28 DSGVO (Auftragsverarbeiter)
- Art. 44-49 DSGVO (Datenübermittlung Drittländer)
Erinnerung: Dieser Artikel stellt keine Rechtsberatung dar. Siehe den Hinweis am Anfang dieses Artikels. Alle Einschätzungen basieren auf öffentlich zugänglichen Verträgen und Dokumentationen, Stand Februar 2026.