Claude DSGVO-konform betreiben: Azure, AWS oder Anthropic

Claude DSGVO-konform zu betreiben ist keine Eigenschaft des Modells, sondern das Ergebnis einer einzigen Vorentscheidung: über welchen Weg Sie Claude beziehen. Denn Verarbeitungsort, Speicherort und Vertragspartner fallen völlig unterschiedlich aus, je nachdem, ob Sie über Microsoft Foundry, AWS Bedrock, Google Vertex AI, direkt bei Anthropic oder über Microsoft 365 Copilot einsteigen. Wer nach einer pauschalen Ja/Nein-Antwort sucht, überspringt genau die Frage, an der die Antwort tatsächlich hängt - was Anthropics DPA, Zero Data Retention und die vorhandenen Zertifizierungen im Einzelnen leisten, ordnen wir separat ein.

Wer sich auf einen Anbieter-Blogpost oder eine einzelne Marketingseite verlässt, bekommt selten das vollständige Bild - meist weil dort genau der eigene Weg im besten Licht dargestellt wird. Dieser Artikel ordnet die vier direkten Betriebswege sowie Copilot als Sonderfall so ein, wie sie sich aus den offiziellen Dokumentationen von Microsoft, AWS, Google und Anthropic tatsächlich ergeben - inklusive der Stellen, an denen die Wege heute noch an Grenzen stoßen. Ein Hinweis vorab: Dieser Artikel ersetzt keine Rechtsberatung. Er ordnet die technische und vertragliche Ausgangslage ein, damit Sie mit Ihrem Datenschutzbeauftragten oder einer Kanzlei auf einer fundierten Grundlage weiterarbeiten können.

Verarbeitungsort und Speicherort: der Unterschied, der über alles entscheidet

Bevor es an die einzelnen Wege geht, lohnt sich eine Begriffsklärung, die in vielen Diskussionen durcheinandergerät: Verarbeitungsort und Speicherort sind zwei unterschiedliche Dinge.

Der Speicherort (Data at rest) beschreibt, wo Ihre Daten dauerhaft liegen - etwa in einer bestimmten Azure-Geografie oder auf einem AWS- bzw. Google-Server. Der Verarbeitungsort beschreibt dagegen, wo die eigentliche Inferenz stattfindet, also wo Ihr Prompt tatsächlich verarbeitet wird, während die Antwort generiert wird. Microsoft formuliert das für Foundry sehr klar: Bei einem „Global”-Deployment kann die Verarbeitung in jeder Azure-Region der Welt stattfinden, selbst wenn die Daten at rest in einer EU-Region gespeichert sind. Nur bei einem „Data Zone”-Deployment ist die Verarbeitung auf die angegebene Zone begrenzt. Diese Unterscheidung - „meine Daten liegen in der EU” ist nicht dasselbe wie „meine Daten werden nur in der EU verarbeitet” - zieht sich durch alle vier Betriebswege in diesem Artikel.

Die zweite zentrale Frage ist: Wer ist eigentlich Ihr Auftragsverarbeiter - also die Partei, die in Ihrem Namen personenbezogene Daten verarbeitet und mit der Sie einen Auftragsverarbeitungsvertrag (AVV/DPA) benötigen? Das ist keine triviale Frage, denn sie unterscheidet sich je nach Betriebsweg fundamental: Bei Microsoft Foundry ist es - trotz „Hosted on Azure” - Anthropic, nicht Microsoft. Bei AWS Bedrock und Google Vertex AI ist es der jeweilige Hyperscaler, nicht Anthropic. Nur wenn Sie Claude direkt bei Anthropic beziehen, ist Anthropic selbst Ihr Auftragsverarbeiter mit eigenem DPA. Anthropic formuliert diese Abgrenzung im eigenen Regelwerk sogar explizit: „On Amazon Bedrock and Google Cloud’s Agent Platform, the cloud provider is the data processor; refer to those platforms’ data retention and compliance documentation.” Wer also prüfen will, wessen DPA für eine konkrete Verarbeitung gilt, muss zuerst klären, über welchen Weg Claude überhaupt läuft - nicht andersherum.

Weg 1: Claude in Microsoft Foundry - warum Anthropic der Auftragsverarbeiter ist

Claude ist seit dem 29.06.2026 in Microsoft Foundry allgemein verfügbar (GA), mit zwei Hosting-Varianten: „Hosted on Anthropic infrastructure” (läuft außerhalb von Azure) und „Hosted on Azure” (läuft laut Microsoft „end-to-end” auf Azure-Infrastruktur). Wer daraus schließt, bei „Hosted on Azure” sei Microsoft der Datenverarbeiter, liegt falsch - und das ist der wichtigste Einzelpunkt für diesen Weg: In beiden Hosting-Varianten ist Anthropic der Auftragsverarbeiter, nicht Microsoft. Microsoft dokumentiert es wörtlich so: Anthropic ist „the seller and operator of Claude models in Microsoft Foundry” und agiert für Prompts und Outputs als „independent data processor”. Die Datenaufbewahrung richtet sich entsprechend nach Anthropics eigenem Data Processing Addendum und den Anthropic Commercial Terms of Service - nicht nach Microsofts Product Terms und DPA. Claude-Modelle sind in den Product Terms konsequent als „Non-Microsoft Products” eingeordnet.

Bei der Datenresidenz zeigt sich die zentrale Einschränkung dieses Wegs: Eine EU Data Zone für Claude existiert in Foundry nicht (Stand: August 2026). Die offizielle Regionsmatrix listet „Data Zone Standard” für Claude ausschließlich für die USA - Europa, Asia Pacific sowie Middle East & Africa stehen dort als „Not available”. Als Global-Standard-Deployment lässt sich Claude in Europa ausschließlich in der Region swedencentral deployen, und Global bedeutet laut Microsoft ausdrücklich: Verarbeitung „in any Azure region” - also gerade keine EU-Verarbeitungszusage, obwohl die Daten at rest je nach gewählter Geografie durchaus in der EU liegen können.

Ein weiterer, für den Mittelstand oft übersehener Punkt: Cloud Solution Provider (CSP)-Subscriptions sind explizit von Claude in Foundry ausgeschlossen. Wer Azure ausschließlich über einen CSP-Partner bezieht, kann Claude in Foundry aktuell nicht kaufen - unabhängig davon, wie gut die restlichen Rahmenbedingungen sonst passen würden. Details zu den beiden Hosting-Varianten, Modellen und der Abrechnung über Claude Consumption Units ordnen wir vertieft im Artikel zur Foundry-GA von Claude ein; die Deployment-Typ-Logik (Global, Data Zone, Standard) inklusive der Frage, wo sie wirklich EU-Datenresidenz liefert, erklären wir im Artikel zu den Azure-KI-Deployment-Typen.

Weg 2: Claude über AWS Bedrock - EU-Verarbeitung mit Einschränkungen

AWS Bedrock unterscheidet für jedes Modell drei Inferenzoptionen: In-Region (strikt eine einzelne Region), Geo Cross-Region (Routing innerhalb einer Geografie wie „EU”) und Global Cross-Region (weltweites Routing). Diese Unterscheidung ist wichtig, weil „verfügbar in eu-central-1” nicht automatisch „als Single-Region-Deployment in Frankfurt buchbar” bedeutet.

Und genau hier liegt eine Einschränkung, die in vielen oberflächlichen Vergleichen fehlt: eu-central-1 (Frankfurt) hat für kein aktuelles Claude-Modell echten In-Region-Support. Frankfurt lässt sich derzeit nur als Quellregion für das eu.-Geo-Profil nutzen. Eine echte Single-Region-Verarbeitung in der EU gibt es (Stand: August 2026) nur in eu-north-1 (Stockholm) und eu-west-1 (Irland) - das gilt für Claude Opus 5, Claude Sonnet 5, Claude Opus 4.8, Claude Opus 4.7 und Claude Haiku 4.5. Bei Claude Sonnet 4.6 und Claude Opus 4.6 liegt der einzige In-Region-Standort in Europa dagegen nicht in der EU, sondern in eu-west-2 (London). Wer also „Claude in Deutschland betreiben” wörtlich meint, findet das bei Bedrock aktuell nicht.

Für die meisten Kunden praktikabler ist das eu.-Cross-Region-Inference-Profil: Es routet Anfragen dynamisch innerhalb der Geografie „EU”. Beim Preis lohnt eine genaue Lesart, weil sie oft verdreht wird: AWS berechnet für das Geo-Profil den Standardpreis und weist für das globale Profil stattdessen „approximately 10% savings” aus - einen Routing-Aufpreis gibt es nicht, der Preis richtet sich nach der Quellregion (Stand: August 2026). Der ökonomische Anreiz zeigt also in Richtung des residenzlosen Profils, nicht umgekehrt. AWS sichert zu, dass Anfragen an ein geografisch gebundenes Profil „innerhalb dieser Geografie” bleiben, und dass sich die Ziel-Regionenliste eines solchen Profils nicht mehr ändert. Das Modellkarten-Zitat für Claude Opus 5 bringt es auf den Punkt: „Keeps data within EU regions.”

Hier lohnt sich eine eigene, nüchterne Einordnung, die AWS selbst so nicht formuliert: Die Ziel-Regionenliste des eu.-Profils umfasst neben klassischen EU-Staaten auch eu-west-2 (London) und eu-central-2 (Zürich) - beides Standorte außerhalb der EU/des EWR. „EU geo” ist bei AWS also geografisch Europa, nicht rechtlich EU. Für eine saubere DSGVO-Argumentation mit Drittlandbezug ist das relevant und sollte in einer Risikobewertung nicht unter den Tisch fallen.

Ein Sonderfall verdient besondere Aufmerksamkeit: Claude Fable 5 ist in allen EU-Regionen ausschließlich über das Global-Profil verfügbar - kein In-Region, kein EU-Geo. Wer Fable 5 aus Frankfurt aufruft, verlässt also zwangsläufig die europäische Geografie. Zusätzlich verlangt Anthropic für Fable 5 eine Aufbewahrung von Inputs und Outputs bis zu 30 Tage sowie ein verpflichtendes Opt-in zur Weitergabe der aufbewahrten Daten an Anthropic zur Missbrauchserkennung - inklusive der Möglichkeit einer menschlichen Sichtung. Global-only-Routing, 30-Tage-Retention und Pflicht-Opt-in zusammen machen Fable 5 für regulierte EU-Workloads über Bedrock faktisch ungeeignet. Fairerweise gehört dazu: AWS verweist für diese Modelle auf die Möglichkeit, über das eigene Account-Team volle Zero Data Retention zu beantragen - am Global-only-Routing ändert das aber nichts (Stand: August 2026).

Für die Governance-Praxis ein konkreter Tipp: Klassische Region-Deny-Regeln über Service Control Policies (SCPs) mit fest benannten Regionen greifen bei Global Cross-Region Inference nicht, weil AWS dafür aws:RequestedRegion auf den Sonderwert "unspecified" setzt. AWS liefert dafür eine eigene Deny-SCP:

{"Effect":"Deny","Action":"bedrock:*","Resource":"*",
 "Condition":{"StringEquals":{"aws:RequestedRegion":"unspecified"},
 "ArnLike":{"bedrock:InferenceProfileArn":"arn:aws:bedrock:*:*:inference-profile/global.*"}}}

Wer Global Cross-Region Inference organisatorisch ausschließen will, sollte genau diese Policy als Baustein einplanen - eine reine Regionsliste reicht nicht aus.

Auf der positiven Seite: Amazon Bedrock arbeitet standardmäßig mit einem Zero-Operator-Access- und einem Zero-Data-Retention-Modell - Bedrock speichert Modell-Inputs und -Outputs standardmäßig nicht, und Anthropic-Personal hat laut AWS keinen Zugriff auf die zugrunde liegende Infrastruktur oder auf Kundenprompts. Technisch abgesichert ist das über sogenannte Model Deployment Accounts, die ausschließlich vom Bedrock-Serviceteam betrieben werden.

Weg 3: Claude über Google Vertex AI in der EU-Multi-Region

Eine Vorbemerkung zur Terminologie: Google hat Vertex AI zwischenzeitlich umbenannt - aus „Vertex AI Platform” wurde „Gemini Enterprise Agent Platform”, und Claude läuft in Googles Sprachgebrauch heute „on Google Cloud’s Agent Platform”. Wir bleiben im Text beim geläufigeren Namen Vertex AI; in der aktuellen Dokumentation begegnet Ihnen die neue Bezeichnung (Stand: August 2026).

Vertex AI bietet drei Endpunkttypen: Global (dynamisches Routing ohne Residenzgarantie, kein Preisaufschlag), Multi-Region (dynamisches Routing innerhalb einer Geografie wie „EU”, 10 % Aufschlag) und Regional (garantiertes Routing durch eine bestimmte Region). Der für EU-Kunden relevante eu-Multi-Region-Endpunkt (https://aiplatform.eu.rep.googleapis.com) wurde laut einer redaktionellen Ergänzung im Google-Cloud-Blog am 15.05.2026 allgemein verfügbar (zuvor Public Preview) - im Fließtext desselben Beitrags steht allerdings weiterhin „public preview”. Maßgeblich ist deshalb Googles Datenresidenz-Dokumentation: Sie führt die EU-Multi-Region für die aktuellen Claude-Modelle ohne Preview-Kennzeichnung (Stand: August 2026).

Ein Stolperstein, der sich in der Praxis leicht übersehen lässt: Regionale Einzelendpunkte unterstützen nur Claude Sonnet 4.6 und ältere Modelle. Neuere Modelle - also Claude Opus 5, Claude Sonnet 5 und Claude Fable 5 - sind auf Vertex ausschließlich über den globalen oder den EU-Multi-Region-Endpunkt nutzbar, nicht über einen einzelnen Regional-Endpunkt wie europe-west1. Wer für diese Modelle Provisioned Throughput mit echter Single-Region-Residenz kombinieren wollte, kann das über Vertex aktuell nicht abbilden. Und für den globalen Endpunkt formuliert Google unmissverständlich, dass er keine Residenzzusage enthält: Er route und verarbeite Daten „anywhere globally, without restricting it to a specific geographic region” und biete „no regional isolation or data residency guarantees”. Die Endpunktwahl ist damit die entscheidende Stellschraube - aber eben nur für den Verarbeitungsort, nicht für den Speicherort.

Datenverarbeiter bei diesem Weg ist Google, nicht Anthropic: Nach dem Google Cloud Data Processing Addendum ist Google Processor, der Kunde Controller (oder ebenfalls Processor), und das DPA adressiert ausdrücklich EU-DSGVO, UK-DSGVO und das Schweizer FADP.

Zwei Punkte verdienen hier einen genaueren Blick, weil sie in Vergleichen regelmäßig fehlen: der Speicherort und das Retention-Verhalten.

Beim Speicherort trennt Google sauber zwischen Ablage und Verarbeitung. Die Datenresidenz-Dokumentation formuliert es so: „Data stored at rest in the customer selected location remains at rest in that location, independent of the Agent Platform endpoint called by that customer’s request.” Der Endpunkt bestimmt also den Verarbeitungsort, nicht den Speicherort - und für den Verarbeitungsort ist die EU-Multi-Region deutlich enger gefasst, als man es von AWS kennt. Google schreibt ausdrücklich: „The European Union multi-region (eu) endpoint strictly covers data residency within EU member states. Geographies outside the European Union political boundary, including the United Kingdom and Switzerland, are excluded from this endpoint.” Genau hier liegt der praktisch wichtigste Unterschied zwischen den beiden Hyperscalern: Was bei AWS unter „EU geo” auch London und Zürich umfasst, schließt Google für die EU-Multi-Region explizit aus. Als einzelne europäische Standorte führt Googles Modelltabelle nur Belgien (europe-west1) und die Niederlande (europe-west4); für Claude-Modelle ist dort ausschließlich europe-west1 markiert - und auch das nur bis Claude Sonnet 4.6 beziehungsweise Claude Opus 4.6 (Stand: August 2026).

Beim Retention-Verhalten liegt der Unterschied zu Bedrock in der Grundeinstellung. AWS beschreibt Zero Data Retention als Auslieferungszustand („by default, Amazon Bedrock does not store model inputs or outputs”). Google formuliert es umgekehrt als Ergebnis einer Konfiguration: „To achieve zero data retention, customers must take specific actions within each of these areas.” Genannt werden unter anderem das Request-Response-Logging (standardmäßig aus, pro Modell und Projekt aktivierbar), die Interactions API, deren Parameter store ohne explizite Angabe auf true steht und für Zero Data Retention aktiv auf false gesetzt werden muss, sowie das Prompt-Logging zur Missbrauchserkennung, von dem sich Kunden unter den Google Cloud Platform Terms of Service auf Antrag ausnehmen lassen können. Den viel zitierten 24-Stunden-Cache dokumentiert Google ausdrücklich nur für Googles eigene Gemini-Modelle, nicht für Partnermodelle wie Claude; er liegt laut Doku ausschließlich im Arbeitsspeicher und lässt sich projektweit abschalten. Für Claude auf Vertex gilt damit: Zero Data Retention ist erreichbar, aber sie ist eine Konfigurationsaufgabe und kein Standardzustand (Stand: August 2026).

Weg 4: Claude direkt bei Anthropic - eigenes DPA, aber keine EU-Datenresidenz

Wer Claude direkt über die Anthropic-API, Claude for Work (Team/Enterprise) oder Claude Platform on AWS bezieht, hat mit Anthropic einen eigenen, klaren Vertragspartner: Anthropic ist Auftragsverarbeiter, der Kunde Verantwortlicher. Das Data Processing Addendum ist automatisch Teil der Anthropic Commercial Terms of Service - ein separater Unterschriftsprozess ist nicht nötig, mit Annahme der Commercial Terms gilt es. Als Datenschutz-Kontrollen bietet Anthropic zwei Parameter an: inference_geo (wo die Inferenz läuft) und workspace_geo (wo Daten at rest liegen, nach der Erstellung nicht mehr änderbar).

Und genau hier liegt der zentrale Befund dieses Wegs: Beide Parameter kennen aktuell (Stand: August 2026) ausschließlich die Werte "us" und - nur bei inference_geo - "global". Eine EU-Option existiert nicht. Anthropic selbst formuliert das unter „Current limitations” unmissverständlich: „Inference geo: Only us and global are available.” und „Workspace geo: Only us is currently available.” Der Parameter inference_geo steht zudem erst ab Claude 4.6 und neueren Modellen zur Verfügung, und reine US-Inferenz kostet einen Aufschlag von 10 % gegenüber dem Standardpreis.

Eine offizielle Ankündigung einer EU-Datenresidenz direkt bei Anthropic haben wir in der Recherche nicht gefunden - lediglich allgemeine Präsenzmeldungen wie Büroeröffnungen in Europa, aber ohne Bezug zur Datenverarbeitung selbst. Auch Anthropics eigene Compliance-Übersichtsseite hilft hier nicht weiter: Sie führt regionale Datenresidenz ausschließlich für die drei Cloud-Plattformen AWS Bedrock, GCP Vertex und Microsoft Foundry auf - ein Erstanbieter-Angebot für Europa taucht dort gar nicht erst auf (Stand: August 2026).

Das führt zur Kernthese dieses Artikels: EU-Datenresidenz und ein direktes Vertragsverhältnis mit Anthropic schließen sich derzeit gegenseitig aus. Wer heute eine belastbare EU-Verarbeitungszusage für Claude-Workloads braucht, kommt an einem Hyperscaler nicht vorbei - und muss dann akzeptieren, dass dort AWS oder Google der Auftragsverarbeiter ist, nicht Anthropic. Anthropics eigenes DPA, etwaige Zero-Data-Retention-Vereinbarungen (ZDR) und die HIPAA-taugliche Konfiguration gelten dort ausdrücklich nicht: Anthropic stellt in der eigenen Doku klar, dass diese Arrangements für die Claude API gelten, „where Anthropic is the data processor”, und auf Bedrock und Google Cloud gerade nicht greifen - dort ist der Cloud-Provider der Auftragsverarbeiter. Für Microsoft Foundry und Claude Platform on AWS hält Anthropic zusätzlich fest, dass die HIPAA-Readiness auf diesen Plattformen nicht verfügbar ist. Wer beides gleichzeitig will - ZDR-Arrangement mit Anthropic und EU-Verarbeitung - findet dafür aktuell keinen Weg.

Zur Einordnung noch ein Detail, das oft übersehen wird: Für den EWR, UK und die Schweiz benennt Anthropic mit Anthropic Ireland, Limited eine eigene Rechtseinheit als Verantwortlicher für Ihre personenbezogenen Daten. Das ändert aber nichts daran, dass die tatsächliche Verarbeitung und Speicherung laut Anthropics eigener Aussage in den USA erfolgt - eine EU-Rechtseinheit als Ansprechpartner ist etwas anderes als EU-Datenresidenz. Eine vertiefte Einordnung von DPA, Zero Data Retention und den Anthropic-Zertifizierungen (ISO 27001, ISO 42001, SOC 2) steht im Artikel zu Claudes DSGVO-Zertifizierungen.

Weg 5: Claude über Microsoft 365 Copilot - der Sonderfall

Ein fünfter, in der Praxis sehr verbreiteter Weg verdient hier nur eine kurze Einordnung, weil er einem eigenen Regelwerk folgt: In Microsoft 365 Copilot - seit der Umbenennung schlicht Microsoft Copilot, laut Microsoft ohne Änderungen an Security, Compliance und Datenschutz - ist Anthropic als Microsoft-Subprozessor eingebunden - hier gilt Microsofts DPA, nicht Anthropics. Microsoft dokumentiert ausdrücklich, dass Anthropic-Modelle in Copilot, Researcher, Copilot Studio, Power Platform und Copilot in Microsoft-365-Apps derzeit von der EU Data Boundary ausgenommen sind, weshalb Kunden in EU/EFTA/UK Anthropic-Modelle dort per Default deaktiviert vorfinden. Die genauen Admin-Schalter, eine wichtige Ausnahme (seit dem 03.04.2026 gibt es eine separate, teils standardmäßig aktive Einstellung für Copilot in Excel/PowerPoint/Word) und die Governance-Checkliste für EU-Administratoren ordnen wir vertieft im Artikel zu Claude in Microsoft 365 Copilot ein.

Welcher Betriebsweg passt zu welcher Datenklasse?

Die naheliegende Reaktion auf diesen Überblick ist oft: „Dann nehmen wir eben durchgehend die teuerste, restriktivste Option.” Das ist verständlich, aber selten die wirtschaftlich sinnvollste Antwort - und es ist auch nicht der Ansatz, den wir empfehlen. Sinnvoller ist es, die Souveränitätsanforderung an der Datenklasse festzumachen, nicht am Werkzeug insgesamt.

Für ein Brainstorming-Prompt ohne Personenbezug ist ein Global-Standard-Deployment über Microsoft Foundry oder das globale Vertex-Profil in aller Regel unproblematisch - hier zählt eher Geschwindigkeit und Modellauswahl als Residenz. Für Workloads mit Personenbezug oder besonderen Kategorien personenbezogener Daten nach Art. 9 DSGVO sieht die Bewertung anders aus: Hier führt der Weg in aller Regel zu einem Geo- oder Data-Zone-Profil mit dokumentierter EU-Verarbeitung - und zu der Frage, wer in diesem konkreten Fall Ihr Auftragsverarbeiter ist. Wie Sie das im Ergebnis bewerten, gehört in die Hände Ihres Datenschutzbeauftragten. Für hochsensible Daten, bei denen selbst „Europa” (inklusive London oder Zürich) zu weit gefasst ist, bleibt nur eine echte Single-Region-Lösung wie AWS Bedrock in Stockholm oder Irland - mit entsprechenden Einschränkungen bei Modellauswahl und Funktionsumfang.

Diese gestaffelte Betrachtung passt zu einem Grundsatz, den wir auch sonst in Beratungsprojekten vertreten: nicht pauschal die maximale Absicherung für jede Anwendung, sondern die zur jeweiligen Datenklasse passende Konfiguration - dokumentiert und begründbar, statt „vorsichtshalber überall Enterprise-Tarif”. Das reduziert Kosten, ohne bei den tatsächlich kritischen Workloads Kompromisse einzugehen.

Zum Abschluss ein Ausblick, der bewusst kein Versprechen ist. Anthropics Compliance-Seite führt eine Tabelle „Claude’s regional availability” mit den drei Plattformen AWS Bedrock, GCP Vertex und Microsoft Foundry. Für die Zeile „Europe” sind AWS Bedrock und GCP Vertex dort als verfügbar markiert; ausschließlich in der Spalte Microsoft Foundry steht „Coming 2026” - und zwar auch für Kanada und Asien-Pazifik, während für die USA alle drei Plattformen als verfügbar geführt werden (Stand: August 2026). Diese Zuordnung wird in Sekundärquellen häufig verwechselt, weil die Angabe in der reinen Textansicht am Zeilenende landet und dann so wirkt, als gälte sie für alle drei Anbieter. Sie deckt sich mit dem, was die Primärdokumentation zeigt: EU-Verarbeitung über Bedrock und Vertex existiert heute, eine EU-Option für Claude in Foundry nicht - weder als Foundry-native EU Data Zone noch über Anthropics eigene Residenz-Parameter. Ein verbindliches Datum nennt derzeit keine der beteiligten Parteien - planen Sie also mit dem heutigen Stand, nicht mit einer Ankündigung.

Häufige Fragen zu Claude und der DSGVO

Welcher Betriebsweg für Claude bietet EU-Datenresidenz?

AWS Bedrock über das eu.-Cross-Region-Profil und Google Vertex AI über den EU-Multi-Region-Endpunkt. Microsoft Foundry und Anthropic direkt bieten für Claude aktuell keine EU-Option. Wichtige Einschränkung dabei: Beide Wege liefern „Europa”, nicht zwingend „EU” im engeren Sinn - die Details dazu stehen bei den jeweiligen Wegen oben.

Läuft Claude in Frankfurt?

Nicht als echte Single-Region-Verarbeitung für aktuelle Claude-Modelle. Über AWS Bedrock lässt sich eu-central-1 (Frankfurt) nur als Quellregion für das eu.-Cross-Region-Profil nutzen; eine tatsächliche In-Region-Verarbeitung gibt es bei Bedrock nur in Stockholm (eu-north-1) und Irland (eu-west-1), bei Sonnet 4.6 und Opus 4.6 stattdessen ausschließlich in London (eu-west-2).

Wer ist bei Claude mein Auftragsverarbeiter?

Das hängt vom Betriebsweg ab: Bei Microsoft Foundry ist es in beiden Hosting-Varianten Anthropic. Bei AWS Bedrock und Google Vertex AI ist es der jeweilige Hyperscaler. Bei direktem Bezug über die Anthropic-API oder Claude for Work ist es Anthropic mit eigenem DPA. Bei Microsoft 365 Copilot ist es Microsoft, mit Anthropic als dessen Subprozessor.

Was ist der Unterschied zwischen Datenspeicherung und Datenverarbeitung in der EU?

Der Speicherort (Data at rest) und der Verarbeitungsort (wo die Inferenz läuft) sind zwei unabhängige Eigenschaften. Ein Global-Deployment kann Daten in einer EU-Geografie speichern und trotzdem die Verarbeitung in jeder verfügbaren Region weltweit durchführen. Nur ein Geo- oder Data-Zone-Deployment mit expliziter Residenzbindung garantiert, dass auch die Verarbeitung selbst innerhalb der zugesicherten Grenze bleibt.

Bietet Anthropic EU-Datenresidenz an?

Nach aktuellem Stand (August 2026) nicht. Anthropics Data-Residency-Parameter (inference_geo, workspace_geo) unterstützen ausschließlich us und global, keine EU-Option. Wer EU-Datenresidenz braucht, muss über einen Hyperscaler gehen - dort gilt dann dessen DPA, nicht Anthropics. Was Anthropics eigenes DPA und die vorhandenen Zertifizierungen sonst abdecken, ordnen wir in einem eigenen Artikel ein.

Fazit

Claude DSGVO-konform zu betreiben bedeutet in der Praxis: den Betriebsweg so wählen, dass Auftragsverarbeiter, Verarbeitungsort und Speicherort zur jeweiligen Datenklasse passen - nicht, ein einzelnes Werkzeug pauschal als „konform” oder „nicht konform” zu labeln. Microsoft Foundry liefert heute keine EU-Option für Claude, dafür saubere Azure-Integration für US- oder globale Workloads. AWS Bedrock und Google Vertex AI bieten echte EU-Verarbeitung - mit Aufschlag, mit der wichtigen Einschränkung „Europa” statt „EU”, und mit dem jeweiligen Hyperscaler statt Anthropic als Vertragspartner. Ein direktes Vertragsverhältnis mit Anthropic wiederum bringt Anthropics eigenes DPA und ZDR-Optionen - aber ausdrücklich keine EU-Datenresidenz. Wer diese Trade-offs kennt und bewusst je Datenklasse entscheidet, statt sich auf eine einzelne Anbieteraussage zu verlassen, trifft eine belastbarere Entscheidung als mit jeder Vergleichstabelle.

Quellen (Stand: August 2026):

Claude DSGVO-konform betreiben: Azure, AWS, Google oder Anthropic direkt - welche Wege heute funktionieren