Azure OpenAI Datenresidenz: Global Standard vs. Data Zone

Ein Deployment in germanywestcentral oder westeurope anlegen und sich damit DSGVO-seitig auf der sicheren Seite wähnen - dieser Schluss liegt nahe und ist in vielen Projekten schon Grundlage für eine Datenschutz-Folgenabschätzung geworden. Er ist trotzdem falsch, wenn der gewählte Deployment-Typ „Global Standard” heißt. Über die Azure OpenAI Datenresidenz entscheidet nicht die Region, in der eine Ressource liegt, sondern ein eigener Parameter beim Deployment: der Deployment-Typ.

Für IT-Admins und Datenschutz-Verantwortliche, die Azure-KI-Deployments konfigurieren oder abnehmen, ist das mehr als Wortklauberei. Wer den Unterschied zwischen Data-at-rest und Verarbeitung nicht kennt, kann eine Konfiguration produktiv schalten, die dokumentiert korrekt aussieht - Region korrekt gewählt, Ressourcengruppe korrekt benannt - und trotzdem Prompts außerhalb der EU verarbeitet. Dieser Artikel ordnet die Deployment-Typen ein, zeigt die Nuancen, die in Kickoff-Meetings gern untergehen, und liefert eine konkrete Governance-Maßnahme, mit der sich der Fehler technisch ausschließen lässt.

Reicht eine EU-Region für Azure OpenAI Datenresidenz?

Microsoft formuliert das in der eigenen Dokumentation zu den Deployment-Typen unmissverständlich - und diese Formulierung ist der wichtigste Satz in diesem Artikel:

„Data stored at rest remains in the designated Azure geography. However, inferencing data is processed as follows: Global types: May be processed in any Azure region. Data Zone types: The service processes data only within the Microsoft-specified data zone (US, EU, or Asia Pacific (APAC)). Standard (single region) types: The service processes data in the deployment region.”

Der erste Satz ist der, der die meisten Projektbeteiligten beruhigt: Data at rest bleibt in der gewählten Azure-Geografie. Das stimmt. Nur beantwortet das nicht die Frage, die bei einer Datenschutz-Folgenabschätzung eigentlich interessiert: Wo werden die Prompts und die generierten Antworten verarbeitet, während die Anfrage läuft? Bei einem Global-Standard-Deployment lautet die Antwort: irgendwo. Microsoft behält sich ausdrücklich vor, die Inferenz in jeder beliebigen Azure-Region durchzuführen - unabhängig davon, in welcher Region die Ressource angelegt wurde.

Ein Global-Standard-Deployment in germanywestcentral ist also technisch korrekt konfiguriert, liefert aber keine EU-Verarbeitungszusage. Das ist kein Bug und keine Grauzone, sondern exakt so dokumentiert. Der Fehler entsteht, wenn niemand im Projekt diese Doku-Stelle gelesen hat, bevor die Vertragsunterlagen oder die Freigabe des Datenschutzbeauftragten formuliert wurden.

Data at rest oder Verarbeitung: Was die Region tatsächlich festlegt

Die Unterscheidung zwischen Data at rest und Verarbeitung ist keine akademische Feinheit von Azure OpenAI, sondern gilt für alle Foundry-Modelle gleichermaßen - auch für Modelle von Partnern wie Anthropic oder Meta, die über Foundry angeboten werden (warum die Plattform heute Microsoft Foundry heißt, ordnet ein eigener Artikel ein). Microsoft formuliert es dort praktisch deckungsgleich: „For global deployments, Microsoft processes prompts and responses in any Azure region where you deploy the model.” Und für Data Zone: „Microsoft processes prompts and responses anywhere within the specified data zone: United States […], European Union (data processed within any EU member nation), or Asia Pacific.”

Zwei unabhängige Stellen in der Microsoft-Dokumentation kommen also zum gleichen Ergebnis - im Detail beschreiben sie die EU-Zusage allerdings unterschiedlich: einmal als „Azure EU Data Boundary”, einmal als „any EU member nation” (dazu der Abschnitt zu den Nuancen weiter unten). Für die Praxis heißt das: Wer eine Aussage zur Datenresidenz treffen will, muss immer zwei Dinge dokumentieren - die Region der Ressource und den Deployment-Typ. Die Region allein sagt nichts über die Verarbeitung aus. Und selbst mit geklärter Residenz bleibt eine zweite Frage offen: ob Microsoft Prompts für das Abuse Monitoring speichert - das ordnet der Artikel zu Zero Data Retention und Abuse Monitoring ein.

Die Deployment-Typen im Überblick (Bereitstellungstypen)

Microsoft Foundry unterscheidet im Kern drei Verarbeitungs-Geografien - Global, Data Zone, Einzelregion - die jeweils in einer Pay-per-token- und einer Provisioned-Variante (reservierter Durchsatz) sowie teils als Batch existieren (Stand: August 2026).

Deployment-Typ	Data at rest	Verarbeitung	Geeignet für
Global Standard / Provisioned / Batch	gewählte Azure-Geografie	jede Azure-Region weltweit	Standard-Workloads, höchste Quota, günstigster Einstieg
Data Zone Standard / Provisioned / Batch	gewählte Azure-Geografie	innerhalb der Data Zone (US, EU oder APAC)	Compliance-Anforderungen auf Geografie-Ebene
Standard (Einzelregion) / Regional Provisioned	gewählte Azure-Geografie	ausschließlich die Deployment-Region	harte regionale Zusage, z. B. „nur Deutschland”
Developer (`DeveloperTier`)	-	jede Azure-Region	nur Fine-Tuning-Evaluierung; kein SLA, keine Datenresidenz-Zusage

Global Standard: höchste Quota, keine Residenz-Zusage

Global Standard ist der Deployment-Typ, den die meisten Quickstarts und Tutorials als Erstes anzeigen - pay-per-token, breiteste Modellverfügbarkeit, höchste Quota. Der Preis für diese Verfügbarkeit ist die fehlende Verarbeitungszusage: Prompts können in jeder Azure-Region landen, in der Microsoft gerade Kapazität hat. Für öffentliche oder unkritische interne Daten ist das meist unproblematisch. Für personenbezogene Daten mit DSGVO-Bezug ist Global Standard ohne zusätzliche vertragliche Absicherung die falsche Wahl.

Data Zone Standard: EU-Verarbeitung, aber nicht EU-Region

Data Zone Standard grenzt die Verarbeitung auf eine benannte Geografie ein - US, EU oder APAC - statt auf eine einzelne Region. Für Kunden mit DSGVO-Anforderungen ist das meist die richtige Balance zwischen Compliance und Verfügbarkeit: Die Quota ist üblicherweise großzügiger als bei Einzelregion-Deployments, weil Microsoft die Last über mehrere Regionen innerhalb der Zone verteilen kann. Der Preis dafür: Man weiß weiterhin nicht, in welcher konkreten EU-Region die Verarbeitung stattfindet - nur, dass es irgendeine ist, die zur EU-Zone zählt (siehe nächster Abschnitt zu den Nuancen).

Standard / Regional Provisioned: die harte Einzelregion-Zusage

Wer eine Zusage auf eine einzelne, benannte Region braucht - etwa weil ein Vertrag „Verarbeitung ausschließlich in Deutschland” fordert - , landet beim Standard-Deployment oder, für planbaren hohen Durchsatz, beim Regional Provisioned Deployment. Beide verarbeiten Daten ausschließlich in der gewählten Deployment-Region. Der Trade-off: Diese Deployment-Typen kommen bei neuen Modellen zuletzt, sind bei aktuellen Modellgenerationen deutlich dünner verfügbar als Global oder Data Zone, und der Ausfall der einen Region betrifft den gesamten Traffic ohne Failover in eine andere Region.

Provisioned- und Batch-Varianten: Durchsatz und Kosten, nicht Residenz

Die Provisioned-Varianten (GlobalProvisionedManaged, DataZoneProvisionedManaged, ProvisionedManaged) ändern an der Datenresidenz-Zusage des jeweiligen Typs nichts - sie reservieren Kapazität und bieten dafür garantierten Durchsatz und geringere Latenzschwankungen statt Best-Effort-Service. Batch-Varianten (GlobalBatch, DataZoneBatch) laufen mit 50 Prozent Rabatt und einem 24-Stunden-Zielzeitfenster für asynchrone Massenverarbeitung (kein Echtzeit-SLA; die Fertigstellung kann länger dauern, Stand: August 2026) - auch hier gilt weiterhin die Verarbeitungs-Geografie des zugrunde liegenden Global- bzw. Data-Zone-Typs. Der Developer-Deployment-Typ (DeveloperTier) schließlich ist ausschließlich für Fine-Tuning-Evaluierung gedacht, lebt 24 Stunden, hat kein SLA und macht keine Datenresidenz-Zusage - für produktive Workloads ungeeignet.

Umfasst die EU Data Zone wirklich nur die EU?

„EU Data Zone” ist nicht deckungsgleich mit „EU”. Die EU Data Zone folgt der Azure EU Data Boundary - und die umfasst laut Microsoft zusätzlich zu den EU-Mitgliedstaaten auch die Länder der Europäischen Freihandelsassoziation (EFTA): Island, Liechtenstein, Norwegen und die Schweiz (Stand: August 2026). Die Deployment-Typen-Doku nennt davon ausdrücklich Norwegen und die Schweiz. Wer vertraglich exakt „nur EU-Mitgliedstaaten” oder gar „nur Deutschland” zusagen muss, braucht ein Standard- bzw. Regional-Provisioned-Deployment, nicht Data Zone.

Microsoft darf die Zone ohne Vorankündigung erweitern. Wörtlich: „Microsoft can add regions to either data zone without prior notice to improve capacity and availability.” Eine einmal dokumentierte Data-Zone-Definition ist also kein statischer Vertragsbestandteil, sondern kann sich ändern, ohne dass der Kunde vorab informiert wird. Für eine Datenschutz-Folgenabschätzung bedeutet das: Die Data-Zone-Zusage regelmäßig neu prüfen, nicht einmalig abhaken.

Neue Modelle kommen zuerst als Global, dann als Data Zone, zuletzt als Einzelregion. Microsoft dokumentiert diese Reihenfolge explizit: „New deployment types become available in a set order: Global, then Data Zone, then single region. Single-region deployment types arrive last, have no guaranteed availability date, and depend on capacity that frees up as older models retire.” Wer das neueste Modell und gleichzeitig eine harte Einzelregion-Zusage will, wird strukturell enttäuscht - Datenresidenz läuft der Modell-Aktualität grundsätzlich hinterher, nicht nur zufällig.

Global Standard per Azure Policy verbieten

Die bisherigen Abschnitte beschreiben, was bei der Konfiguration passieren kann. In der Praxis reicht das nicht: Wenn EU-Verarbeitung Pflicht ist, sollte ein Global-Standard-Deployment technisch gar nicht erst anlegbar sein

unabhängig davon, ob eine Entwicklerin oder ein Deployment-Skript es versehentlich probiert.

Microsoft liefert dafür einen ansetzbaren Hebel: Jeder Deployment-Typ wird technisch über den Parameter sku.name auf der Ressource Microsoft.CognitiveServices/accounts/deployments abgebildet (GlobalStandard, DataZoneStandard, Standard, GlobalProvisionedManaged und so weiter). Microsoft stellt eine Beispiel-Policy bereit, die den Zugriff auf einen bestimmten Deployment-Typ über sku.name abschaltet; das veröffentlichte Beispiel zeigt allerdings nur die if-Bedingung - den Effekt (deny) ergänzen Sie selbst. Eine Built-in-Policy-Definition für Deployment-Typen gibt es nicht (Stand: August 2026). Governance-seitig heißt das konkret: eine Azure-Policy-Definition mit deny-Effekt auf sku.name = GlobalStandard (und, je nach Anforderung, auch auf GlobalProvisionedManaged und GlobalBatch), zugewiesen auf die Ressourcengruppe oder Subscription, in der personenbezogene Daten verarbeitet werden. Damit wird aus einer Empfehlung im Onboarding-Dokument eine technische Kontrolle, die auch bei Terraform-Applies oder direkten Portal-Deployments greift.

Das ist der Punkt, an dem sich diese Konfigurationsfrage von einer einmaligen Entscheidung in eine dauerhafte Governance-Aufgabe verwandelt - und genau da setzt Governance in Azure-Umgebungen (Azure Policy, Terraform) an: nicht nur den richtigen Deployment-Typ empfehlen, sondern ihn organisatorisch absichern. Die gleiche Denkweise - technische Kontrollen statt Vertrauen auf korrekte Konfiguration - trägt auch jenseits von Datenresidenz, etwa bei Zero-Trust-Prinzipien für KI-Agenten.

Gilt das auch für Claude in Microsoft Foundry?

Alles bisher Beschriebene gilt für Foundry-Modelle allgemein - für die GPT-Modellfamilie von OpenAI ist die EU Data Zone inzwischen breit verfügbar (Stand: August 2026). Für Claude-Modelle in Microsoft Foundry sieht die Lage anders aus (Stand: August 2026): Es gibt für Claude bislang keine Data-Zone-Deployments in Europa. Die Regionsmatrix von Microsoft listet für Claude unter „Data Zone Standard” für Europa, Asia Pacific sowie Middle East & Africa jeweils „Not available” - verfügbar ist Data Zone Standard für Claude ausschließlich in US-Regionen, und auch dort nur für einen Teil der Modelle (claude-opus-5, claude-opus-4-8, claude-sonnet-5).

Als Global-Standard-Deployment lässt sich Claude in Europa ausschließlich in swedencentral anlegen (Stand: August 2026) - germanywestcentral, westeurope und francecentral sind für Claude-Modelle in der Regionstabelle leer. Und selbst swedencentral liefert, wie oben beschrieben, keine EU-Verarbeitungszusage, weil es sich um ein Global-Standard-Deployment handelt: Verarbeitung „in any Azure region”, nicht innerhalb der EU. Anthropics eigene Regional-Compliance-Übersicht führt Microsoft Foundry für Europa als „Coming 2026”, ohne konkretes Datum zu nennen.

Wer Claude-Modelle mit einer belastbaren EU-Verarbeitungszusage betreiben will, kommt aktuell über Microsoft Foundry nicht ans Ziel - dafür braucht es einen anderen Weg. Was genau GA-Status, Hosting-Varianten und Abrechnung von Claude in Microsoft Foundry heute bedeuten, behandeln wir in einem eigenen Artikel ausführlicher; eine Gesamteinordnung aller Wege zu einem DSGVO-konformen Claude-Betrieb liefert der Pillar-Artikel zum DSGVO-konformen Claude-Betrieb.

Entscheidungshilfe: Welcher Typ passt zu welcher Datenklasse

Eine pauschale Empfehlung „nehmen Sie immer Data Zone” wird der Realität nicht gerecht - die Wahl hängt an der Datenklasse und am tatsächlichen vertraglichen Bedarf, nicht an einem Reflex.

Für öffentliche oder unkritische interne Daten - etwa Zusammenfassungen öffentlich zugänglicher Dokumente, interne Wissensdatenbanken ohne Personenbezug - ist Global Standard in der Regel die richtige Wahl. Die höhere Quota und die breitere Modellverfügbarkeit überwiegen den fehlenden Residenz-Vorteil, den man an dieser Stelle ohnehin nicht braucht.

Für interne Daten mit moderatem Schutzbedarf, bei denen eine EU-Verarbeitung vertraglich zugesagt werden soll, aber keine Einzelregion gefordert ist, ist Data Zone Standard der pragmatische Mittelweg - solange die Nuance „EU Data Boundary kann EFTA-Staaten einschließen” im Datenschutz-Dokument mit aufgeführt und akzeptiert wird.

Für personenbezogene Daten mit hohem Schutzbedarf oder Verträgen, die eine harte Länderzusage verlangen, führt kein Weg an Standard bzw. Regional Provisioned vorbei - mit dem Wissen, dass dort die Modellauswahl kleiner ausfällt und neue Modelle später ankommen als bei Global oder Data Zone. Dieser Abwägungsprozess ersetzt keine Rechtsberatung; er ist eine technische Grundlage, auf der die eigene Rechtsabteilung oder ein Datenschutzbeauftragter aufsetzen kann.

Häufige Fragen zu den Azure-KI-Deployment-Typen

Reicht eine EU-Region für DSGVO-konforme Azure-OpenAI-Nutzung?

Nein. Die Region der Ressource bestimmt, wo Data at rest gespeichert wird. Ob die Verarbeitung ebenfalls in der EU stattfindet, entscheidet der Deployment-Typ (Global, Data Zone oder Standard/Regional) - bei Standard/Regional zusammen mit der gewählten Deployment-Region.

Was ist der Unterschied zwischen Global Standard und Data Zone Standard?

Global Standard verarbeitet Daten in jeder Azure-Region weltweit, in der Microsoft gerade Kapazität hat - ohne Zusage. Data Zone Standard grenzt die Verarbeitung auf eine benannte Geografie ein, etwa „irgendwo in der EU”. Wer eine harte Einzelregion-Zusage braucht, etwa nur germanywestcentral, landet stattdessen bei Standard (Einzelregion).

Welche Länder gehören zur EU Data Zone?

Die EU Data Zone folgt der Azure EU Data Boundary, und die umfasst neben den EU-Mitgliedstaaten die EFTA-Staaten Island, Liechtenstein, Norwegen und die Schweiz (Stand: August 2026). Zudem darf Microsoft die Zone ohne Vorankündigung um weitere Regionen erweitern.

Wie verhindere ich, dass ein Global-Standard-Deployment versehentlich angelegt wird? Über eine Azure-Policy-Definition mit deny-Effekt auf den Parameter sku.name der Deployment-Ressource, zugewiesen auf die betroffene Ressourcengruppe oder Subscription.

Gilt das auch für Claude-Modelle in Microsoft Foundry?

Teilweise anders: Für Claude gibt es (Stand: August 2026) noch keine Data-Zone-Deployments in Europa. In Europa lässt sich Claude nur als Global-Standard-Deployment in swedencentral anlegen - ohne EU-Verarbeitungszusage.

Fazit

Der Deployment-Typ, nicht die Region, entscheidet über die Verarbeitungs-Geografie eines Azure-KI-Deployments. Global Standard bringt die höchste Quota, aber keine Residenz-Zusage; Data Zone Standard grenzt die Verarbeitung auf eine Geografie ein, kann aber mehr Länder umfassen als gedacht; nur Standard bzw. Regional Provisioned liefert eine harte Einzelregion-Zusage - bei kleinerer Modellauswahl. Wer EU-Verarbeitung vertraglich zusagen muss, sollte diese Zusage nicht dem Zufall einer Portal-Konfiguration überlassen, sondern per Azure Policy technisch erzwingen. Für Claude-Modelle fehlt der Data-Zone-Weg in Europa aktuell komplett - das gehört in jede Datenklassen-Entscheidung mit hinein.

Quellen (Stand: August 2026):

Azure OpenAI Datenresidenz: Global Standard, Data Zone und Regional - welcher Deployment-Typ wirklich EU-Verarbeitung liefert