Beschaffungsabteilungen in der EU und am Golf fragen inzwischen, ob ein KI-System souverän ist, und Anbieter antworten mit dem Namen einer Region. Die beiden Aussagen betreffen nicht dasselbe, und in der Lücke dazwischen werden sich die meisten Compliance-Fehler der KI-Beschaffung der nächsten Jahre finden.
Lokalisierung beschreibt, wo Daten physisch liegen. Souveränität beschreibt, welches Rechtsregime Zugriff erzwingen kann. Operative Souveränität beschreibt, wer den Stack administrieren darf und von wo. Ein Anbieter kann das Erste vollständig erfüllen und an den beiden anderen scheitern, und ein Deployment, das nur das Erste erfüllt, wird von regulierten Käufern zunehmend abgelehnt. 2026 hat sich die praktische Definition von souverän auf lokale Speicherung plus lokale Verarbeitung plus kontrollierte Administration plus minimierte fremde Rechtsreichweite verdichtet, mit prüfbaren Nachweisen statt Anbieterzusicherungen in regulierten Branchen.
Für ein Unternehmen, das aus Europa heraus eine in den USA gehostete LLM-API bewertet, hat diese Unterscheidung unmittelbare Folgen. Den Dienst aus Europa zu nutzen macht daraus keine inländische Verarbeitung. Die maßgeblichen Fragen sind, wer auf die Daten zugreifen kann, wo die Verarbeitung tatsächlich stattfindet und ob der Anbieter fremdem Offenlegungsrecht unterliegt.
Die DSGVO- und Schrems-Lage bei US-gehosteten APIs
Übermittlungsregeln greifen, sobald personenbezogene Daten eine in den USA gehostete LLM-API erreichen. Ausschlaggebend ist nicht der Standort des Servers, sondern ob die Daten aus einer Drittstaatsjurisdiktion zugänglich sind, unter ihr verarbeitet werden oder von ihr herausverlangt werden können. Ein Anbieter oder Unterauftragsverarbeiter, der Zugriffen nach dem CLOUD Act oder FISA 702 unterliegt, erzeugt ein Schrems-Risiko auch dann, wenn der Endpunkt europäisch ist, denn der Übermittlungsmechanismus muss ein im Wesentlichen gleichwertiges Schutzniveau sicherstellen, und erzwungener Drittstaatszugriff verträgt sich damit schlecht.
Käufer behandeln Lokalisierung deshalb inzwischen als notwendig und nicht hinreichend. Die härtere Anforderung ist, ob der Anbieter Daten außerhalb fremder Zwangszugriffspfade halten kann und ob er ein Transfer Impact Assessment samt ausdrücklichem Übermittlungsmechanismus vorlegen kann, sei es Standardvertragsklauseln, Binding Corporate Rules oder, wo einschlägig, das Data Privacy Framework.
Wo diese Konstruktionen tatsächlich brechen, verdient eine genaue Benennung, denn es ist fast nie der primäre Inferenz-Endpunkt. Es sind Fallback- und Retry-Pfade, Observability- und Logging-Pipelines, Support-Zugriff und Feedback-Schleifen. Jeder davon kann Prompts, Ausgaben oder Logs aus der deklarierten Region bewegen, während der Hauptanfragepfad vollständig konform bleibt, und jeder wird üblicherweise von einem Engineering-Team konfiguriert, das den Vertrag nie gesehen hat.
Was die KI-Verordnung von Betreibern verlangt
Die meisten Unternehmen, die KI einkaufen, sind Betreiber und nicht Anbieter, und die Praxis 2026 legt die operative Compliance klar auf den Betreiber: rechtmäßige Nutzung wählen, die Betriebsanweisungen führen und befolgen, Risiken dokumentieren und die für den Anwendungsfall erforderlichen Protokolle und Aufzeichnungen aufbewahren.
Bei Hochrisiko-Anwendungen müssen Betreiber grundsätzlich sicherstellen, dass die menschliche Aufsicht echt und nicht nominell ist, das System gemäß den Anweisungen des Anbieters betreiben, die Leistung im Einsatz überwachen und technische wie operative Aufzeichnungen vorhalten, die für Prüfung und Vorfallbearbeitung ausreichen. Nichts davon gelingt, wenn Sie nicht in das System hineinsehen können, und das ist ein Grund, warum Fragen zu Observability und Souveränität in der Beschaffung gemeinsam auftauchen.
Das vertragliche Muster, das sich herausgebildet hat, verlangt vier Dinge: benannte EU-Regionen für Daten im Ruhezustand, in der Übertragung und in der Verarbeitung; Weitergabe der Lokalisierungspflichten an Unterauftragsverarbeiter, damit die Zusage die eigene Lieferkette des Anbieters übersteht; Prüfrechte an Protokollen, Incident Response und Zugriffskontrollen; und eine klare Aufteilung der Pflichten zwischen Anbieter und Betreiber, damit der Betreiber operative Kontrolle nachweisen und nicht nur behaupten kann.
Der letzte Punkt bleibt am häufigsten vage, und Vagheit ist dort teuer. Sind die Betriebsanweisungen eines Anbieters dünn, erbt der Betreiber die Unklarheit zusammen mit der Pflicht.
Das Bild am Golf: VAE und Saudi-Arabien
Die Beschaffung am Golf hat sich in dieselbe Richtung bewegt, mit anderer Gewichtung. Gefragt wird, ob der Workload im Land liegt und wer auf ihm arbeiten darf, nicht, ob er in einer regionalen Cloud-Zone gelandet ist.
Der GCC-Markt bewegt sich auf sektorspezifische Souveränitätsanforderungen zu, wobei Gesundheit, Verteidigung und Teile des öffentlichen Sektors souveräne Overlays jenseits gewöhnlicher kommerzieller Cloud-Regionen verlangen. Für die VAE wie für Saudi-Arabien geht die Richtung 2026 zu Verarbeitung im Land für sensible und staatsnahe Workloads, wobei die Beschaffung Nachweise für Lokalität, Betreiberkontrolle und eingeschränkten Fernzugriff verlangt.
Daraus folgen zwei Konsequenzen für jeden, der eine Architektur für Kunden am Golf entwirft. Eine Region in einer benachbarten Geografie erfüllt eine In-Country-Anforderung nicht, wie gut die Latenz auch sei. Und eine Region im Land erfüllt sie ebenfalls nicht, wenn Supportpersonal, Administrationsebenen, Backups oder der Modellbetrieb außerhalb der Jurisdiktion bleiben. Die operative Ebene ist genau das, was diese Anforderungen zunehmend erfassen sollen, und sie ist die Ebene, die die meisten Cloud-Architekturen standardmäßig global lassen.
Eine Souveränitätszusage lesen
Anbieter vermarkten inzwischen souveräne Cloud- und Datengrenz-Angebote, deren Umfang sich erheblich unterscheidet. Microsoft etwa erklärt, dass seine Zusagen zur KI-Datenverarbeitung EU-Kundendaten innerhalb der EU Data Boundary halten, ausschließlich in der EU gespeichert und verarbeitet, sofern der Kunde nichts anderes anweist. Das ist eine substanzielle Zusage, und es ist eine Zusage zu Lokalisierung und Verarbeitung. Sie ist nicht dasselbe wie jurisdiktionelle Abschottung von fremdem Recht, und sie wird auch nicht so dargestellt.
Der nützliche Test für jede solche Zusage besteht darin, das Versprochene in die drei Ebenen einzusortieren.
- Lokalisierung heißt, Daten liegen in einer gewählten Geografie. Sie sagt nichts darüber, wer zugreifen kann und wo Verarbeitung und Support stattfinden.
- Souveränität heißt, Daten und Verarbeitung unterliegen der Rechtsordnung der gewählten Jurisdiktion. Sie bedeutet nicht automatisch lokalen Betrieb und auch keine Immunität gegen Ansprüche fremden Rechts gegenüber einer Muttergesellschaft.
- Operative Souveränität heißt, Administration, privilegierter Zugriff und Incident Response werden lokal erbracht und sind prüfbar. Sie hält Daten für sich genommen nicht in einer Jurisdiktion, sofern das nicht gesondert vertraglich und architektonisch durchgesetzt wird.
Eine Zusage ist Fassade, wenn sie eine EU- oder GCC-Region benennt und grenzüberschreitenden Support, Fernadministration, Zugriff der ausländischen Mutter oder nicht lokale Unterauftragsverarbeiter unbeantwortet lässt. Das ist kein seltenes Muster, sondern das übliche, und es hält sich, weil Käufer aufhören zu fragen, sobald die Region genannt ist.
Die Fragen, die vertragliche Antworten erzeugen
Behandeln Sie bei jeder LLM-Beschaffung in der EU oder am Golf das Hosting in der Region als Eintrittsbedingung und lassen Sie sich Folgendes im Vertrag zusichern statt im Vertriebsgespräch.
- Wo Prompts, Ausgaben, Protokolle, Embeddings, feinabgestimmte Gewichte und Backups jeweils liegen. Führen Sie sie einzeln auf, denn sie werden häufig von unterschiedlichen Systemen verwaltet, und nur die ersten beiden sind von einer Lokalisierungserklärung üblicherweise erfasst.
- Ob eine ausländische Stelle aus der Ferne oder unter erzwungener Offenlegung darauf zugreifen kann, einschließlich der Mutter des Anbieters und seiner Unterauftragsverarbeiter.
- Welcher Übermittlungsmechanismus gegebenenfalls gilt und ob ein Transfer Impact Assessment existiert und geteilt werden kann.
- Ob Support- und Betriebspersonal lokal oder remote arbeitet und was mit dieser Antwort bei einem Vorfall außerhalb der Geschäftszeiten geschieht.
- Ob der Anbieter Regionsnachweise und Prüfbelege auf Anforderung liefern kann statt nach bestem Bemühen.
Wo der Workload sensible personenbezogene Daten, Daten regulierter Branchen oder eine Nutzung im öffentlichen Sektor betrifft, ist die sichere Annahme, dass Sie eine souveräne Architektur brauchen und keine als souverän vermarktete Region. Das ist der Punkt, an dem ein privates Deployment aufhört, die teure Alternative zu sein, und zur einfacheren wird, denn ein Modell auf Infrastruktur unter Ihrer Kontrolle beantwortet alle fünf Fragen strukturell statt vertraglich.
Wie wir vorgehen
Beginnen Sie mit der Klassifizierung der Daten statt mit der Bewertung von Anbietern. Die meisten Unternehmen haben einen kleinen Anteil Material, der wirklich souveräne Behandlung braucht, und einen großen Anteil, der das nicht tut; alles auf der höchsten Stufe zu behandeln erzeugt eine Architektur, die niemand bezahlen kann, und ein Programm, das stillsteht. Die Aufteilung richtig zu treffen ist das, was ein hybrides Design verteidigungsfähig macht.
Zeichnen Sie danach die tatsächlichen Pfade einer einzelnen repräsentativen Anfrage nach: wo sie verarbeitet wird, was protokolliert wird, wohin die Protokolle gehen, wer sie lesen könnte und was beim Fallback passiert. Machen Sie das als Diagramm, bevor Sie Anbieterdokumentation lesen, denn es sagt Ihnen, welche Fragen zu stellen sind, und es macht eine unvollständige Antwort sichtbar.
Formulieren Sie die Anforderung entlang der drei Ebenen statt entlang einer Region. Eine Ausschreibung, die nach Lokalisierung fragt, bekommt Lokalisierung. Eine Ausschreibung, die fragt, wer den Stack administrieren darf, von wo aus und mit welchem Nachweis, bekommt bewertbare Antworten, und sie filtert die Anbieter heraus, deren Souveränitätszusage immer nur eine Rechenzentrumsadresse war.
Häufige Fragen
Unser Anbieter garantiert Verarbeitung ausschließlich in der EU. Reicht das für die DSGVO?
Es adressiert die Lokalisierung, und die ist die erste Ebene, nicht die ganze Frage. Unter der DSGVO geht es nicht nur darum, wo der Server steht, sondern ob die Daten aus einer Drittstaatsjurisdiktion zugänglich sind, unter ihr verarbeitet werden oder von ihr herausverlangt werden können. Ein Anbieter mit US-Mutter, der EU-Regionen betreibt, kann weiterhin unter Zugriffe nach dem CLOUD Act oder FISA 702 fallen, weshalb ein Transfer Impact Assessment und ein ausdrücklicher Übermittlungsmechanismus nötig sind. Fragen Sie gezielt nach Support-Zugriff, Unterauftragsverarbeitern und dem Ort der Administration.
Wo verlassen in der EU gehostete LLM-APIs üblicherweise die deklarierte Region?
Selten am primären Endpunkt, den alle prüfen. Die üblichen Schwachstellen sind Fallback- und Retry-Routing in eine andere Region bei einem Kapazitätsereignis, Observability- und Logging-Pipelines, die zentral aggregieren, Support-Zugriff, bei dem ein Techniker außerhalb der Region eine Sitzung zur Fehlersuche öffnet, sowie Feedback- oder Fine-Tuning-Schleifen, die Prompts und Ausgaben in eine Trainings- oder Qualitätspipeline bewegen. Fragen Sie jeden Punkt namentlich ab und lassen Sie sich die Antwort in den Vertrag schreiben.
Genügt eine souveräne Cloud-Region für sensible Workloads in den VAE oder Saudi-Arabien?
Oft nicht. Die Beschaffung am Golf fragt 2026 zunehmend, wer auf den Daten arbeiten darf, und nicht nur, wo sie landen; Workloads aus Gesundheit, Verteidigung und dem öffentlichen Umfeld können souveräne Overlays jenseits einer gewöhnlichen kommerziellen Region verlangen. Eine Region in einer benachbarten Geografie fällt bei einer In-Country-Anforderung glatt durch, und selbst eine Region im Land fällt durch, wenn Supportpersonal, Administrationsebenen, Backups oder der Modellbetrieb außerhalb der Jurisdiktion liegen.