Souveränität entscheidest du pro Modell, nicht pro Plattform

„Läuft das in Europa?" Die Frage kommt in jedem zweiten Architektur-Workshop, meistens vom Datenschutzbeauftragten, meistens erst, wenn der Prototyp schon steht. Ich habe lange versucht, sie mit einem Satz zu beantworten. Das geht nicht, weil drei Fragen darin stecken, die unterschiedliche Antworten haben.

Vorweg: Das hier ist keine Rechtsberatung. Es ist die Sicht von jemandem, der solche Systeme baut, und die verbindliche Bewertung deines konkreten Falls liegt beim Justiziariat.

Drei Fragen, die nur zusammen eine Antwort ergeben

Die erste Frage ist die vertragliche: Unter welchen Bedingungen wird verarbeitet? Gelten die Microsoft Product Terms und die Data Protection Addendum, oder die AGB eines Dritten?

Die zweite ist die geografische: Wo läuft das Inferencing tatsächlich? Nicht wo die Daten liegen, sondern wo gerechnet wird.

Die dritte ist die operative: Wer kann im Betrieb auf das System zugreifen, und wird dieser Zugriff protokolliert?

Diese drei fallen nicht zusammen. Ein Modell kann vertraglich vollständig abgedeckt sein und trotzdem außerhalb der EU-Datengrenze rechnen. Dieser Fall ist bei Microsoft seit Januar 2026 dokumentierte Realität, und er ist der Grund, warum ich die Modellwahl als Governance-Entscheidung behandle und nicht als Entwicklerentscheidung.

Das neueste Modell ist nie das souveränste

In Microsoft Foundry entscheidest du den Verarbeitungsort über den deployment type. GlobalStandard verarbeitet in jeder Azure-Region, DataZoneStandard innerhalb der Zone (US, EU oder seit diesem Sommer APAC), Standard nur in der Region deines Deployments. Daten im Ruhezustand bleiben in allen Fällen in deiner Azure-Geografie. Es geht ausschließlich um das Inferencing.

Der Satz, der auf Microsoft Learn steht und den ich für den wichtigsten der ganzen Seite halte: Neue deployment types erscheinen in einer festen Reihenfolge, erst Global, dann Data Zone, dann Einzelregion. Und für Einzelregionen gibt es kein zugesagtes Verfügbarkeitsdatum, weil sie von Kapazität abhängen, die frei wird, wenn ältere Modelle abgekündigt werden.

Das ist kein Versehen und kein Rückstand, der irgendwann aufgeholt wird. Es ist die Bauweise. Wer das jeweils stärkste Modell will, nimmt es zwangsläufig zuerst als Global-Deployment, also mit weltweiter Verarbeitung. Wer die EU-Datenzone verlangt, arbeitet strukturell mit dem Modell der vorletzten Generation.

Dieser Trade-off gehört in die Architekturentscheidung, bevor jemand einen Prompt schreibt. Er lässt sich technisch erzwingen: Azure Policy kann Deployments nach SKU-Namen blockieren, und GlobalStandard ist genau so ein SKU-Name. Das ist ein Fünfzeiler in einer Policy-Definition und erspart dir die Diskussion, warum in Environment X plötzlich global gerechnet wird.

Seit dem 1. September steht ein Preis dran

Bis vor Kurzem war Souveränität in Foundry vor allem eine Verfügbarkeitsfrage. Seit dem 1. September 2026 ist sie auch eine Kostenposition. Microsoft hat die Preise für Data-Zone- und Regional-Deployments außerhalb der USA angepasst: Global bleibt, wie es war, die EU-Datenzone liegt neun Prozent darüber, Regional-Deployments außerhalb der USA sieben bis sechzehn Prozent, die neue APAC-Zone zwanzig.

Neun Prozent klingen nach wenig. Rechne sie trotzdem auf das prognostizierte Jahresvolumen, nicht auf den Pilotmonat. In den Kostenmodellen, die ich sehe, ist der Aufschlag nicht das Problem. Das Problem ist, dass er in keinem Business Case steht, weil die Residenz-Entscheidung erst nach der Budgetfreigabe fällt.

Vertraglich sauber, geografisch draußen

Der interessanteste Fall sind die Partnermodelle. Anthropic ist seit dem 7. Januar 2026 Microsoft-Subprocessor. Damit gelten die Product Terms, die DPA und das Customer Copyright Commitment auch für Claude in Microsoft 365 Copilot und in Copilot Studio. Der frühere Weg über separate Anthropic-Vertragsbedingungen ist abgekündigt. Vertraglich ist das eine deutliche Verbesserung, und die Einkaufsabteilung hat dadurch weniger Arbeit.

Nur steht in derselben Dokumentation der Nachsatz: Anthropic-Modelle sind außerhalb der EU-Datengrenze und außerhalb der In-Country-Zusagen für LLM-Verarbeitung. Für Copilot Studio bestätigt Microsoft das noch einmal separat. Für Foundry gilt dasselbe Muster, dort werden Claude-Modelle über Global- oder DataZone-Optionen verarbeitet, eine europäische Datenzone existiert für sie bisher nicht.

Vertragsstatus und Verarbeitungsort sind also zwei Schalter, nicht einer. Wenn dein Justiziariat den Subprocessor-Nachweis abhakt und daraus schließt, die Verarbeitung finde in Europa statt, ist die Prüfung an genau der Stelle falsch abgebogen.

Noch eine Stufe weiter außen liegen Anbieter, die keine Subprocessor sind. Bei xAI weist Microsoft ausdrücklich darauf hin, dass die Verarbeitung außerhalb aller von Microsoft verwalteten Umgebungen und Audit-Kontrollen stattfindet und dass Product Terms, DPA, Residenzzusagen, SLAs und das Customer Copyright Commitment nicht gelten. In Copilot Studio sind diese Modelle ohnehin nur für US-Tenants verfügbar. Der Modell-Picker sieht aus wie eine Liste gleichartiger Optionen. Rechtlich sind es drei verschiedene Kategorien.

Der Schalter, den du nicht selbst umgelegt hast

Flex Routing erlaubt, dass LLM-Inferencing für EU- und EFTA-Kunden bei Lastspitzen außerhalb der EU-Datengrenze läuft, konkret in den USA, in Kanada oder in Australien. Daten im Ruhezustand bleiben in der Datengrenze, bis auf begrenzte pseudonymisierte Daten für Sicherheit und Betrieb.

Der Punkt, den die Produktseiten nicht betonen: Für Tenants, die nach dem 25. März 2026 angelegt wurden, ist Flex Routing standardmäßig an. Bestandstenants haben ihre Einstellung über das Message Center bekommen. Wenn du den Tenant für einen neuen Mandanten, eine Ausgründung oder eine Demo-Umgebung frisch aufgesetzt hast, ist das dein Fall.

Zwei Stellen steuern das: das Microsoft 365 Admin Center für Copilot und Copilot Chat, das Power Platform Admin Center für Dynamics 365, Power Platform und Copilot Studio. Die PPAC-Einstellung folgt der aus dem M365 Admin Center, außer sie ist restriktiver. Und wer Multi-Geo gekauft oder genutzt hat, ist für Microsoft 365 gar nicht erst im Scope der EU-Datengrenze, sieht die Einstellung dort also nicht.

Prüf den Wert, statt ihn anzunehmen. Er ist in zwei Minuten nachgeschaut und gehört in dieselbe Akte wie der Nachweis der Kennzeichnungspflicht.

Wenn die Datengrenze nicht reicht

Für Fälle, in denen auch die EU-Datenzone nicht ausreicht, gibt es seit Februar 2026 die Sovereign Private Cloud: Azure Local, Microsoft 365 Local und Foundry Local, betrieben auf eigener Hardware, auf Wunsch vollständig getrennt vom Netz. Foundry Local läuft dort als Arc-Extension auf Kubernetes, seit Juni auch über mehrere Knoten und wahlweise mit vLLM statt ONNX Runtime GenAI.

Das ist ein ernstzunehmender Weg, und er kostet dich drei Dinge: die Modellauswahl, den Betriebsaufwand einer eigenen Inferenz-Plattform und den Anschluss an den Release-Takt der Cloud. Wer diesen Weg geht, sollte ihn für abgegrenzte Verfahren gehen, nicht für die gesamte Organisation.

Der Widerspruch, den ich nicht auflösen kann

Microsoft sagt Verarbeitung in Europa zu, Zugriffskontrolle durch in Europa ansässiges Personal über Data Guardian, Kundenschlüssel über External Key Management. Das sind reale, prüfbare Kontrollen. Am extraterritorialen Zugriff nach dem US CLOUD Act ändern sie nichts, und keine der Zusagen behauptet das. Wie stark dieses Restrisiko wiegt, ist eine Bewertungsfrage und keine technische. Ich nenne sie offen, statt sie wegzudefinieren, weil eine Architektur, die das tut, später niemanden schützt.

Was ich empfehle

1. Klassifiziere je Use Case, nicht je Plattform. Ein Tenant kann gleichzeitig Global-Deployments für unkritische Zusammenfassungen und Data-Zone-Deployments für personenbezogene Verfahren betreiben.
2. Dokumentiere für jeden Agent drei Felder: Vertragsgrundlage, Verarbeitungsort, Zugriffsmodell. Das sind drei Spalten in dem Inventar, das du ohnehin brauchst.
3. Erzwinge den Verarbeitungsort über Azure Policy auf den SKU-Namen, statt ihn in einer Guideline zu beschreiben.
4. Prüf Flex Routing in beiden Admin Centern und halte den Stand mit Datum fest.
5. Behandle die Modellwahl als Änderung mit Freigabe. Ein Modellwechsel im Picker kann den Verarbeitungsort ändern, ohne dass eine Zeile Code angefasst wird.

Der letzte Punkt ist der, den ich am häufigsten nachschieben muss. Souveränität ist bei diesen Plattformen keine Eigenschaft, die du einmal einkaufst. Sie ist eine Eigenschaft jeder einzelnen Modellzuweisung, und sie kann sich ändern, während dein System unverändert läuft.

Was ich noch nicht beurteilen kann

Ob die EU-Datenzone für Partnermodelle kommt, und wann. Es gibt dazu keine Zusage, die ich zitieren könnte, nur Nachfragen in den Foren.

Und ob der Aufschlag von neun Prozent stabil bleibt. Er wurde im Juli angekündigt und gilt seit dem 1. September, ein zweiter Datenpunkt fehlt.

Quellen

• Deployment types for Microsoft Foundry Models, Microsoft Learn, Stand 6. August 2026. Reihenfolge der deployment types, Datenresidenz je Typ, Azure-Policy-Beispiel.
• Microsoft Foundry Model Deployment Pricing Update, Microsoft Community Hub, 27. Juli 2026. Preisänderung zum 1. September 2026.
• Flex routing (EU and EFTA), Microsoft Learn, Stand 5. Mai 2026. Standardwert für Tenants nach dem 25. März 2026, Zielregionen, Zusammenspiel der beiden Admin Center.
• Data, Privacy, and Security for Microsoft 365 Copilot, Microsoft Learn. Anthropic-Modelle außerhalb der EU-Datengrenze und der In-Country-Zusagen.
• Anthropic as a subprocessor for Microsoft Online Services, Microsoft Learn. Subprocessor-Status seit 7. Januar 2026, Geltung von Product Terms, DPA und Customer Copyright Commitment.
• Allow external large language models for generative responses, Microsoft Learn. Ausschluss aus den EU-Datengrenz-Zusagen für Copilot Studio, xAI nur für US-Tenants.
• What is the EU Data Boundary?, Microsoft Learn. Scope-Regeln, Ausschluss von Multi-Geo-Kunden.
• What is Foundry Local on Azure Local?, Microsoft Learn. Arc-Extension, Engines, disconnected-Betrieb.
• What's New in Microsoft Foundry, Juni 2026, Microsoft Foundry Blog, 7. Juli 2026. Multi-Node und vLLM für Foundry Local auf Azure Local.
• Microsoft Sovereign Cloud adds governance, productivity and support for large AI models, Official Microsoft Blog, 24. Februar 2026. Sovereign Private Cloud, disconnected operations.