Azure OpenAI und Amazon Bedrock unter der DSGVO: So bleiben Modellanfragen in der EU

Welche Azure-OpenAI-Deployment-Typen die Verarbeitung in der EU halten

Nur zwei Arten von Azure-Deployments halten die Inferenz in der EU-Datenzone, die laut Microsoft auch EFTA-Staaten umfassen kann: Data-Zone-Deployments in einer Ressource in einer EU-Region sowie Standard- oder Regional-Provisioned-Deployments in einer EU-Geografie. Jeder Global-Typ kann Prompts außerhalb der EU verarbeiten, auch wenn die Ressource selbst in einer EU-Region liegt.

Die Microsoft-Seite zu den Deployment-Typen, zuletzt aktualisiert am 12. August 2026, trennt zwei Dinge, die oft vermischt werden. Gespeicherte Daten (at rest), etwa hochgeladene Dateien, bleiben bei jedem Deployment-Typ in der Azure-Geografie der Ressource. Die Verarbeitung, also die Inferenz, die Ihren Prompt liest und die Antwort erzeugt, richtet sich nach dem Deployment-Typ. Eine Ressource in einer EU-Region mit einem Global-Standard-Deployment speichert Daten also in der EU, kann sie aber überall verarbeiten. Hinter den meisten Fragen der Art „Wir haben doch eine EU-Region gewählt, warum verlassen die Daten sie?“ steckt genau diese Kombination.

Zwei Details gehören in Ihre Dokumentation. Laut der Datenschutzseite von Microsoft darf ein Deployment in der EU-Datenzone Prompts in jedem EU-Mitgliedstaat verarbeiten. Die Seite zu den Deployment-Typen ergänzt, dass die EU-Datenzone der EU Data Boundary folgt, die auch EFTA-Staaten wie Norwegen und die Schweiz umfassen kann, und dass Microsoft einer Datenzone ohne Vorankündigung Regionen hinzufügen kann. Verlangt Ihre Vorgabe ein bestimmtes Land statt der EU, kommt nur ein Standard-Deployment in der Geografie dieses Landes in die Nähe, und auch dieses kann Last zwischen Regionen innerhalb der Geografie verschieben.

Nicht jedes Modell gibt es in jedem Deployment-Typ und jeder Region. Prüfen Sie vor der Festlegung auf ein Modell die aktuelle Verfügbarkeit bei Microsoft für Data Zone Standard und Standard in Ihrer Region. Ein Modell, das nur als Global Standard angeboten wird, scheidet unter einer EU-only-Vorgabe aus, wie gut es auch sein mag.

Wer Ihre Prompts bei Azure sehen kann

Bei Modellen, die Microsoft in Foundry verkauft, einschließlich der Azure-OpenAI-Modelle, erhält OpenAI Ihre Prompts nicht, und sie werden nicht für Training genutzt. Bei Claude in Foundry ist das anders, und am Abuse Monitoring können Microsoft-Beschäftigte beteiligt sein. Die Datenschutzseite von Microsoft, zuletzt aktualisiert am 5. Juni 2026, sagt, dass Prompts und Antworten weder OpenAI noch anderen Anbietern der von Azure verkauften Modelle zur Verfügung stehen, von diesen nicht zur Verbesserung ihrer Modelle genutzt werden und ohne Ihre Erlaubnis oder Anweisung nicht zum Training generativer Basismodelle dienen. Außerdem sind die Modelle zustandslos und interagieren nicht mit Diensten, die OpenAI betreibt, etwa ChatGPT oder der OpenAI API.

Claude-Modelle in Foundry sind ein eigener Fall. Der Hosting-Vergleich von Microsoft, zuletzt aktualisiert am 22. September 2026, sagt, dass Anthropic Claude in Foundry verkauft und betreibt und für Prompts und Ausgaben als unabhängiger Auftragsverarbeiter handelt, auf Grundlage des Data Processing Addendum und der Commercial Terms von Anthropic. Auf Azure gehostetes Claude gibt es als Global Standard und Data Zone Standard (US). Bei Anthropic gehostetes Claude gibt es nur als Global Standard, und Daten können außerhalb von Azure verarbeitet werden. Stand 7. November 2026 gibt es für Claude in Foundry keine EU-Datenzone. Unter einer EU-only-Vorgabe scheidet es dort also aus.

Abuse Monitoring und wer es abschalten kann

Abuse Monitoring ist standardmäßig Teil des Dienstes. Automatische Klassifikatoren prüfen Prompts und Antworten, und laut Microsoft werden Inhalte, die nur automatisch geprüft werden, nicht gespeichert. Vom System markierte Inhalte können für eine menschliche Prüfung in einem Datenspeicher in der Geografie Ihrer Ressource abgelegt werden, auch bei Global- und Data-Zone-Deployments. Zugriff haben nur autorisierte Microsoft-Beschäftigte über abgesicherte Arbeitsplätze mit Just-in-Time-Freigabe, und für Modelle, die im Europäischen Wirtschaftsraum bereitgestellt sind, sitzen diese Prüfer im EWR.

Selbst abschalten können Sie es nicht. Laut der Limited-Access-Seite von Microsoft steht Modified Abuse Monitoring nur Kunden und Partnern offen, die von einem Microsoft-Account-Team betreut werden oder an einem berechtigten Programm teilnehmen, und zwar auf Antrag. Für einige fortgeschrittene Modelle gelten strengere Kriterien. Nach der Genehmigung entfallen Speicherung und menschliche Prüfung, eine automatische Prüfung kann aber weiterlaufen. Eine Aufbewahrungsdauer für den Abuse-Monitoring-Speicher nennen die aktuellen Microsoft-Seiten, die wir am 7. November 2026 geprüft haben, nicht. In Foren kursieren Angaben wie 30 Tage. Lassen Sie sich die aktuelle Dauer lieber von Microsoft schriftlich bestätigen.

Manche Funktionen speichern Inhalte bewusst. Die Responses API, Threads in der Assistants API und Stored Completions legen einen Datenspeicher für den Nachrichtenverlauf an, und Dateien für Fine-Tuning, Batch-Jobs oder Vector Stores werden in der Ressource innerhalb ihrer Geografie gespeichert. Global Batch hält die wartenden Daten in Ihrer Geografie, kann sie aber überall dort verarbeiten, wo das Modell bereitsteht.

Amazon Bedrock: Aufrufe in der EU halten und was AWS aufbewahrt

Bei Bedrock hängt die Verarbeitung in der EU von der Modellkennung ab, die Sie aufrufen: Ein Modell in einer EU-Region oder ein geografisches EU Inference Profile hält Anfragen in der EU, ein globales Profil nicht.

Der Artikel im AWS re:Post Knowledge Center zur Datennutzung sagt, dass Bedrock Ein- und Ausgabedaten von Kunden nicht speichert, nicht an externe Modellanbieter weitergibt und nicht zum Training von Modellen nutzt. Das Bedrock-Benutzerhandbuch ergänzt, dass das Modell jedes Anbieters in einem Model Deployment Account läuft, den das Bedrock-Team besitzt und betreibt und auf den der Anbieter keinen Zugriff hat. Anbieter sehen also weder Ihre Prompts noch Antworten oder Bedrock-Logs.

Diese allgemeine Aussage hat modellspezifische Ausnahmen für die Missbrauchserkennung. Stand 7. November 2026 steht auf der Abuse-Detection-Seite von Bedrock, dass bei bestimmten OpenAI-Modellen vom Klassifikator markierter Verkehr und bei Claude Fable 5 und Claude Fable 5.1 der gesamte Verkehr bis zu 30 Tage aufbewahrt wird, wobei markierter Verkehr dieser Claude-Modelle von AWS manuell geprüft werden kann. Aufbewahrte Daten bleiben bei AWS, gehen nicht an den Modellanbieter und liegen bei Cross-Region-Inferenz in der Zielregion, in der die Anfrage lief. Auf der Seite zur Datenaufbewahrung legen Sie pro Region einen Aufbewahrungsmodus fest. Im Modus none werden Anfragen an Modelle, die eine Aufbewahrung verlangen, blockiert statt gespeichert. Auch der in Forenfragen auftauchende Legacy-Modus provider_data_share gibt keine Inhalte weiter: AWS schreibt, dass Bedrock derzeit keine Inhalte mit Modellanbietern teilt.

Zu geografischen Profilen schreibt AWS, dass ein an eine Geografie wie die EU gebundenes Profil Anfragen in dieser Geografie hält und seine Liste der Zielregionen sich nie ändert, während globale Profile mit der Zeit Regionen hinzugewinnen können. AWS warnt zugleich davor, sich allein auf das Präfix einer Profil-ID zu verlassen. Lesen Sie die Zielregionen des konkreten Profils aus Ihrer Quellregion aus, bevor Sie es freigeben:

# 1. Active EU profiles available from Frankfurt
aws bedrock list-inference-profiles \
    --region eu-central-1 \
    --type-equals SYSTEM_DEFINED \
    --query "inferenceProfileSummaries[?status=='ACTIVE' && starts_with(inferenceProfileId, 'eu.')].[inferenceProfileId,inferenceProfileName]" \
    --output table

# 2. Destination Regions of one profile, called from Frankfurt
aws bedrock get-inference-profile \
    --region eu-central-1 \
    --inference-profile-identifier <eu-profile-id> \
    --query 'models[].modelArn'

Welche Modelle in Frankfurt direkt oder über ein EU-Profil verfügbar sind, ändert sich häufig. Prüfen Sie deshalb die aktuelle Modellliste und die Ausgabe oben statt irgendeines Artikels, diesen eingeschlossen. Die Bedrock-Dokumentation von LiteLLM weist darauf hin, dass neuere Claude-Modelle On-Demand-Aufrufe nur über ein Inference Profile annehmen. Für diese Modelle ist das EU-Profil also die realistische EU-Option.

Wenn Ihre Organisation ungenutzte Regionen per Service Control Policy sperrt, schlägt Cross-Region-Inferenz fehl, solange Sie die Zielregionen des Profils nicht erlauben oder eine Ausnahme mit der Bedingung bedrock:InferenceProfileArn hinzufügen. AWS dokumentiert außerdem eine Policy, die globale Profile vollständig verbietet. Hängen Sie sie an jedes Konto, das Bedrock aufrufen darf:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyGlobalCrossRegionInference",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "unspecified" },
        "ArnLike": { "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/global.*" }
      }
    }
  ]
}

Schützt eine EU-Region vor dem US CLOUD Act

Für sich allein nicht. Eine EU-Region bestimmt, wo Daten verarbeitet und gespeichert werden. Beim CLOUD Act geht es darum, welchem Recht der Anbieter folgen muss. § 2713 in Titel 18 des United States Code, eingefügt durch den CLOUD Act 2018, verpflichtet Anbieter von Kommunikations- und Remote-Computing-Diensten, Daten in ihrem Besitz, ihrer Obhut oder unter ihrer Kontrolle zu sichern und herauszugeben, unabhängig davon, ob diese Daten in den USA oder außerhalb liegen. Microsoft und Amazon sind US-Unternehmen. Die Wahl von Frankfurt oder der EU-Datenzone nimmt Ihre Daten also nicht aus diesem Anwendungsbereich heraus.

Microsoft hat das in Frankreich selbst eingeräumt. In einer Anhörung der Untersuchungskommission des französischen Senats zur öffentlichen Beschaffung am 10. Juni 2025 wurde Anton Carniaux von Microsoft France gefragt, ob er unter Eid garantieren könne, dass Daten französischer Bürger, die Microsoft über die zentrale Beschaffungsstelle UGAP anvertraut wurden, nie ohne ausdrückliche französische Genehmigung an US-Behörden gehen. Er antwortete, das könne er nicht garantieren, ergänzte, es sei noch nie vorgekommen, und sagte, Microsoft verpflichte sich vertraglich, unbegründete Anfragen anzufechten.

Ein EU-Deployment leistet trotzdem einiges. Es hält die laufende Verarbeitung und gespeicherte Daten in der EU, und bei Azure sitzen die Abuse-Prüfer für EWR-Deployments im EWR. Nach unserer Einschätzung lässt sich außerdem die Prüfung von Drittlandtransfers nach DSGVO einfacher dokumentieren. Ob das genügt, hängt von den Daten ab. Für die meisten internen Assistenten halten wir ein EU-Deployment mit den Kontrollen aus dem nächsten Abschnitt für gut vertretbar. Müssen Sie gerade den Zugriff einer ausländischen Regierung ausschließen, etwa bei manchen Daten aus öffentlicher Verwaltung, Verteidigung oder Gesundheitswesen, spricht mehr für einen Anbieter mit Sitz in der EU oder eigene Server. Dieser Leitfaden ist keine Rechtsberatung. Die Entscheidung liegt bei Ihrem Datenschutzbeauftragten und Ihrer Rechtsberatung.

EU-only-Routing für alle Teams mit einem LLM-Gateway durchsetzen

Am verlässlichsten halten Sie alle Teams auf EU-Endpunkten, wenn das Gateway der einzige Weg zu den Modellen ist und ausschließlich EU-Endpunkte als Ziel kennt. Mit LiteLLM sind das sechs Schritte:

1. 1

   Nur EU-Endpunkte eintragen

   Jeder Eintrag in model_list zeigt auf ein Data-Zone- oder Standard-Deployment in einer EU-Ressource von Azure, wobei LiteLLM azure/ gefolgt vom Deployment-Namen erwartet, oder auf ein Bedrock-Modell bzw. ein eu.-Profil mit einer EU-Region in aws_region_name. Nehmen Sie die Region in den Namen des Eintrags auf, etwa mit dem Suffix -eu, damit niemand raten muss.

2. 2

   Auf Wildcard-Einträge verzichten

   Das Wildcard-Routing von LiteLLM leitet jeden Modellnamen mit einem bestimmten Präfix an den Anbieter weiter, ohne dass er gelistet sein muss. Das ist bequem, hebelt hier aber den Zweck aus, denn ein Client könnte dann ein globales Deployment oder ein global.-Profil einfach über den Namen erreichen.

3. 3

   Schlüssel pro Team mit erlaubter Modellliste vergeben

   Legen Sie jedes Team mit einer models-Liste an und vergeben Sie seine Schlüssel unter diesem Team. LiteLLM dokumentiert, dass die models-Liste eines Schlüssels andere Modelle sowohl aus der Modellübersicht ausblendet als auch Aufrufe an sie blockiert und dass eine Team-Anfrage an ein Modell außerhalb der Liste mit einer Fehlermeldung scheitert, die die gültigen Modelle nennt.

4. 4

   Fallbacks innerhalb der EU halten

   Fallbacks führen von einem model_name zu einem anderen, Fallback-Ziele müssen im Router existieren, und LiteLLM wendet die Modellzugriffsprüfungen des aufrufenden Schlüssels und Teams auf jedes Fallback-Ziel an. Stehen nur EU-Einträge in der Liste, gibt es auch bei einem Ausfall kein globales Deployment, auf das ausgewichen werden könnte. Legen Sie fest, ob ein regionaler Ausfall die Anfrage scheitern lässt oder sie auf ein anderes EU-Deployment verschiebt, und halten Sie diese Entscheidung schriftlich fest.

5. 5

   Die Hintertüren schließen

   Halten Sie die Zugangsdaten der Anbieter nur im Secret Store des Gateways, beschränken Sie, wer in den vom Gateway genutzten Azure-Ressourcen Deployments anlegen darf, und hängen Sie die Policy von oben an die AWS-Konten. Sonst umgeht ein für einen schnellen Test angelegtes Global-Standard-Deployment oder ein Entwickler, der Bedrock direkt mit einem globalen Profil aufruft, alles Vorherige.

6. 6

   Regelmäßig prüfen

   Listen Sie einmal im Monat alle Deployments samt Deployment-Typ in den Azure-Ressourcen hinter dem Gateway sowie die genutzten Bedrock-Modelle und Profile auf und vergleichen Sie das mit der Modellliste. Eine Abweichung ist das erste Zeichen, dass jemand einen Weg aus der EU hinaus geöffnet hat.

model_list:
  # Azure OpenAI: Data Zone Standard deployment in an EU resource
  - model_name: gpt-eu
    litellm_params:
      model: azure/<data-zone-eu-deployment-name>
      api_base: https://<eu-resource-name>.openai.azure.com/
      api_key: os.environ/AZURE_EU_API_KEY
      api_version: "<api-version>"
  # Amazon Bedrock: EU geographic inference profile, called from Frankfurt
  - model_name: claude-eu
    litellm_params:
      model: bedrock/<eu-profile-id>
      aws_region_name: eu-central-1
# No wildcard entries such as azure/* or bedrock/*
# No fallbacks to models outside this list

curl -X POST "$LITELLM_URL/team/new" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"team_alias": "claims", "models": ["gpt-eu", "claude-eu"]}'

curl -X POST "$LITELLM_URL/key/generate" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"team_id": "<team-id-from-the-response>"}'

Eine kurze Checkliste für den Datenschutzbeauftragten

Der Datenschutzbeauftragte braucht die Vertragslage, die Liste der Auftragsverarbeiter und eine Übersicht aller Orte, an denen Prompts gespeichert werden. All das kann das Engineering vorbereiten:

• Auftragsverarbeitungsvertrag (AVV): Für die von Azure verkauften Modelle verweist Microsoft auf sein Products and Services Data Protection Addendum, Claude in Foundry unterliegt dem Data Processing Addendum von Anthropic, und bei Bedrock prüfen Sie die Datenverarbeitungsbedingungen Ihres AWS-Vertrags. Art. 28 Abs. 3 DSGVO verlangt einen Vertrag, der Gegenstand, Dauer, Art und Zweck der Verarbeitung festlegt.
• Unterauftragsverarbeiter: Nach Art. 28 Abs. 2 DSGVO braucht ein Auftragsverarbeiter Ihre Genehmigung, bevor er einen weiteren Auftragsverarbeiter einsetzt. Halten Sie fest, wer was verarbeitet: Microsoft oder AWS für den Modelldienst und in Foundry Anthropic als unabhängiger Auftragsverarbeiter für Claude.
• Deployment-Inventar: jedes Deployment und Profil, das das Gateway nutzt, mit Deployment-Typ bzw. Profil-ID, Region und dem Datum der letzten Prüfung.
• Abuse Monitoring und Aufbewahrung: bei Azure, wo der Speicher liegt, dass Prüfer für EWR-Deployments im EWR sitzen und ob Sie Modified Abuse Monitoring beantragt haben. Bei Bedrock, welche Ihrer Modelle eine Aufbewahrung verlangen und welchen Aufbewahrungsmodus jede Region nutzt.
• Funktionen mit Speicherung: ob jemand die Responses API, Assistants-Threads, Stored Completions, Batch-Jobs oder hochgeladene Dateien nutzt, die Inhalte bewusst speichern.
• Eigene Logs: Request-Logs des Gateways, Traces und Cloud-Logging enthalten oft vollständige Prompts, und für sie sind Sie selbst verantwortlich. Legen Sie die Aufbewahrung bewusst fest. Unser Leitfaden zur Aufbewahrung von KI-Traces beschreibt das Vorgehen.
• Prüftermin: Die Anbieterseiten, auf die sich dieser Leitfaden stützt, wurden zwischen Mai und September 2026 aktualisiert. Prüfen Sie die Quellen unten mindestens quartalsweise und bei jedem neuen Modell erneut.

Zeigt die Checkliste, dass die benötigten Modelle in der EU nicht verfügbar sind, oder schließt die Frage nach dem CLOUD Act US-Anbieter für bestimmte Daten aus, bleiben ein EU-only-Betrieb im eigenen Cloud-Konto mit weniger Modellen oder Modelle auf eigenen Servern für diese Daten.

KI im eigenen AWS- oder Azure-KontoLiteLLM-Gateway: Aufbau und BetriebOn-Premise-KI auf eigenen Servern