Datenresidenz am Golf: Was wirklich gilt

„Müssen die Daten im Land bleiben?“ ist eine der ersten Fragen, wenn eine Organisation am Golf über Cloud-, Analyse- oder KI-Infrastruktur nachdenkt.

Es ist zugleich eine der Fragen, die man am leichtesten zu stark vereinfacht.

Eine Plattform kann ihre primäre Datenbank in einer nationalen Cloud-Region halten, während sensible Informationen anderswo über einen KI-Endpunkt verarbeitet, in ein Backup im Ausland kopiert, einem internationalen Support-Team zugänglich gemacht oder über Telemetrie- und Sicherheitswerkzeuge exportiert werden. Aus Sicht eines einfachen Hosting-Diagramms liegen die Daten lokal. Aus Sicht von Souveränität, operativer Kontrolle und regulatorischer Exposition kann das Bild ganz anders aussehen.

Die gegenteilige Annahme ist genauso problematisch: dass jede Golf-Rechtsordnung eine pauschale Regel habe, die den Grenzübertritt von Informationen verbietet.

Es gibt keine einheitliche „Golf-Datenresidenzverordnung“. Die Anforderungen unterscheiden sich zwischen Ländern, Sektoren und Sonderrechtsordnungen, und Programme für staatliche oder national kritische Systeme können Kontrollen unterliegen, die weit über das allgemeine Datenschutzrecht hinausgehen.

Der richtige architektonische Ausgangspunkt ist deshalb nicht die Cloud-Region.

Es sind die Klassifizierung der Information, der regulatorische Anwendungsbereich der Einrichtung und der vollständige Weg, auf dem diese Information gespeichert, verarbeitet, abgerufen und wiederhergestellt werden kann.

Datenresidenz und Datensouveränität sind unterschiedliche Kontrollziele

Bei Residenz geht es im Kern um den Ort. Bei Souveränität geht es um Kontrolle.

Eine ernsthafte Architekturprüfung sollte deshalb mehr klären als den Ort des primären Speicherdienstes. Sie sollte verstehen, wo verarbeitet wird, wo Backups und Wiederherstellungskopien liegen, wohin Logs und Observability-Daten wandern, aus welchen Rechtsordnungen privilegierte Administratoren zugreifen können, wer die Schlüssel kontrolliert, welche Control Planes die Umgebung ändern können und wie Daten fließen, wenn die primäre Region ausfällt.

Bei KI werden diese Fragen besonders wichtig, weil die Verarbeitung zunehmend über Dienste verteilt ist.

Eine lokal gehostete Anwendung kann einen Kundendatensatz aus einer inländischen Datenbank holen und dann ausgewählte Informationen an ein externes Modell senden. Ein Vektorspeicher im Land kann von einer Embedding-API im Ausland abhängen. Lokale Inferenz kann dennoch Telemetrie für einen globalen Monitoring-Dienst erzeugen. Sicherheitswerkzeuge können Logs mit personenbezogenen oder betrieblichen Informationen exportieren.

Keiner dieser Wege wird sichtbar, wenn die Architekturprüfung beim Speicherort aufhört.

Souveränität braucht deshalb ein durchgängiges Modell der Daten- und Kontrollflüsse.

Für Saudi-Arabien ist eine mehrstufige Prüfung erforderlich

Saudi-Arabien zeigt, warum es gefährlich ist, eine Infrastrukturantwort aus einer einzigen Vorschrift abzuleiten.

Auf der Ebene personenbezogener Daten bilden das saudische Datenschutzgesetz und die Verordnung über die Übermittlung personenbezogener Daten aus dem Königreich einen kontrollierten Rahmen für internationale Übermittlungen. Der aktuelle Rahmen erkennt unter anderem geeignete Garantien, Standardvertragsklauseln und verbindliche gemeinsame Regeln in den einschlägigen Fällen an. Er stellt zudem klar, dass Übermittlungen die nationale Sicherheit oder wesentliche Interessen Saudi-Arabiens nicht beeinträchtigen dürfen.

Die richtige Auslegung lautet also nicht schlicht „Saudische personenbezogene Daten dürfen Saudi-Arabien nie verlassen“.

Das Datenschutzrecht ist jedoch nur ein Teil der saudischen Architektur.

Die National Cybersecurity Authority unterhält einen nationalen Kontrollrahmen für die von ihr erfassten Einrichtungen. Die aktuellen Essential Cybersecurity Controls, ECC 2-2024, legen eine nationale Cybersicherheits-Basislinie fest, während gesonderte Kontrollen unter anderem Cloud Computing, Betriebstechnik und Datensicherheit behandeln.

Wo das Programm national kritische Systeme betrifft, führen die NCA Critical Systems Cybersecurity Controls eine spezifischere Ebene ein. Der CSCC-Rahmen ist ausdrücklich als Erweiterung der Essential Cybersecurity Controls für national kritische Systeme angelegt und deckt Cybersicherheits-Governance, Abwehr, Resilienz sowie Cybersicherheit bei Dritten und in der Cloud ab.

Diese Unterscheidung zählt.

Eine kommerzielle Kundenplattform, ein staatlicher Digitaldienst und ein national kritisches System können alle in Saudi-Arabien betrieben werden und dennoch erheblich unterschiedliche Sicherheits-, Resilienz- und Hosting-Anforderungen haben.

Eine hochwertige Architektur sollte deshalb zuerst klären, in welche Kategorie die tatsächliche Last fällt, statt „saudische Residenz“ als eine universelle Regel anzuwenden.

Für den saudischen Finanzsektor gelten zusätzliche sektorspezifische Vorgaben

Finanzdienstleistungen erfordern eine zusätzliche Analyse.

Das Cyber Security Framework der saudischen Zentralbank gilt für SAMA-regulierte Mitgliedsorganisationen und legt Erwartungen an Cybersicherheits-Governance und -Kontrollen über Informationswerte, Anwendungen, Netze, Dritte und zugehörige Infrastruktur fest.

Der Cloud-Rahmen ist für die Architektur besonders relevant. Er verlangt Risikobewertung und Due Diligence vor der Nutzung hybrider oder öffentlicher Cloud-Dienste und behandelt vertragliche Kontrollen, Sicherheit und Datenstandort. Der Rahmen hält fest, dass Cloud-Dienste grundsätzlich in Saudi-Arabien liegen sollen und dass eine ausdrückliche Genehmigung der SAMA erforderlich ist, wenn nach diesem Rahmen Cloud-Dienste außerhalb Saudi-Arabiens genutzt werden sollen.

Das ist eine weit stärkere Einschränkung als eine allgemeine Auslegung des PDPL allein.

Es zeigt, warum die Sektorklassifizierung vor der Infrastrukturauswahl stehen muss.

Ist der Kunde ein reguliertes Finanzinstitut, kann eine Architektur, die für ein gewöhnliches saudisches Unternehmen tragfähig wäre, ein anderes Cloud-, Datenfluss-, Genehmigungs- und Betriebsmodell verlangen.

Auch in den VAE ist eine Prüfung nach Emirat und Rechtsraum erforderlich

Die VAE haben einen eigenen föderalen Datenschutzrahmen. Das Bundesdekretgesetz Nr. 45 von 2021 regelt den Schutz personenbezogener Daten und enthält Mechanismen für die grenzüberschreitende Übermittlung, die zwischen Zielen mit angemessenem Schutzniveau und Fällen unterscheiden, in denen andere Garantien oder Bedingungen nötig sind.

Doch „VAE-Datenschutz“ ist selbst nicht immer präzise genug.

Finanzfreizonen können eigene Regime haben. Der Abu Dhabi Global Market etwa arbeitet unter seinen Data Protection Regulations 2021 und unterhält einen eigenen Rahmen für internationale Übermittlungen. ADGM erkennt benannte angemessene Rechtsordnungen sowie Mechanismen wie Standardvertragsklauseln und verbindliche Unternehmensregeln für geeignete Fälle an.

Daraus ergibt sich eine Architekturfolge, die oft übersehen wird.

Eine Übermittlung ist nicht nur ein geplanter Datenbankexport. Fernzugriff, Verarbeitung über einen externen Dienst und andere Formen der Verfügbarkeit für einen Empfänger außerhalb der maßgeblichen Rechtsordnung können für die Datenschutzanalyse relevant sein. Die ADGM-Leitlinien behandeln internationale Übermittlungen ausdrücklich als eigenen Compliance-Bereich und sehen dafür spezifische Mechanismen und Garantien vor.

Für Architekten lautet die praktische Botschaft: „gehostet in Abu Dhabi“ oder „gehostet in Dubai“ ist keine vollständige Data-Governance-Antwort. Rechtsträger, Freizonenstatus, Sektor, Informationsart und externe Auftragsverarbeiter müssen alle erfasst werden.

KI schafft zusätzliche Datenflüsse, die klassische Infrastrukturprüfungen häufig übersehen

Generative KI macht das besonders wichtig, weil eine scheinbar einfache Nutzeranfrage Informationen durch mehrere Dienstleister bewegen kann.

Ein Beschäftigter einer Behörde stellt eine Frage. Die Anwendung authentifiziert die Identität, ruft Dokumente ab, erzeugt Embeddings oder fragt einen bestehenden Vektorspeicher ab, baut den Modellkontext, ruft einen Inferenz-Endpunkt auf, wendet einen Moderationsdienst an, zeichnet eine Evaluationsspur auf und protokolliert Leistungsdaten.

Jede Stufe kann einen eigenen Verarbeitungsort, Auftragsverarbeiter oder Verwaltungsbereich darstellen.

Ein Vertrag, der festhält, dass Prompts nicht zum Modelltraining verwendet werden, ist wertvoll, beantwortet aber nicht alle Architekturfragen. Wo findet die Inferenz statt? Wie lange werden Inhalte aufbewahrt? Welche Unterauftragsverarbeiter sind beteiligt? Wo werden Missbrauchs-Monitoring-Logs verarbeitet? Können Beschäftigte im Ausland privilegierten Zugriff erhalten? Kann der Kunde diesen Zugriff eigenständig entziehen?

Bei sensiblen staatlichen oder kritischen Workloads gehören diese Punkte zum Systementwurf und nicht in Fußnoten der Beschaffung.

Am sichersten ist eine vollständige Datenflusskarte über Quelle, Retrieval, Kontextaufbau, Inferenz, Werkzeuge, Logging, Backup und Support — und die Anwendung der Klassifizierungsanforderungen auf jede Grenze.

Verschlüsselung klärt die Souveränitätsfrage nicht

„Die Daten sind verschlüsselt“ ist notwendig, aber unvollständig.

Wichtiger sind die Fragen, wem die Schlüssel gehören und wer sie verwaltet, wo die Schlüsselverwaltungs-Infrastruktur läuft, ob der Dienstleister während der Verarbeitung auf Klartext zugreifen kann, wer die Schlüsselrichtlinie ändern darf und was mit der Verwahrung bei einer Notfallwiederherstellung geschieht.

Kundenverwaltete Schlüssel können die Kontrolle deutlich stärken, schaffen aber nicht automatisch Souveränität, wenn eine externe Control Plane oder ein privilegierter Administrator die Umgebung weiterhin auf eine Weise ändern kann, die der Kunde nicht selbst verhindern kann.

Bei sehr sensiblen staatlichen Workloads muss die Verantwortung möglicherweise bewusst zwischen Infrastrukturbetreiber, Anwendungsbetreiber und Schlüsselverwahrer getrennt werden.

Für viele kommerzielle Systeme wäre diese Architektur überzogen.

Für andere ist sie genau der Punkt.

Souveränität sollte im Verhältnis zu Informations- und Bedrohungsmodell stehen und nicht als Marketing-Etikett gekauft werden.

Netzabhängigkeiten gehören zur souveränen Architektur

Physischer und logischer Standort müssen zusammen mit den Netzpfaden betrachtet werden.

Zwei Systeme können beide im Inland gehostet sein, während ihre Kommunikation von internationalem Routing, externem DNS, globalen Steuerdiensten oder Anbietern abhängt, deren Ausfall die Anwendung isolieren würde.

Für gewöhnliche Unternehmenslasten kann das ein akzeptabler Kompromiss sein.

Bei Diensten auf nationaler Ebene, im Finanzwesen oder mit kritischer Mission kann die Konnektivität selbst Teil des Resilienz- und Souveränitätsmodells werden. Wegediversität, Anbieterunabhängigkeit, Routing-Kontrolle, DDoS-Resilienz und die Fähigkeit, die Kommunikation bei teilweisem Infrastrukturausfall aufrechtzuerhalten, zählen dann neben Rechenleistung und Speicher.

Hier werden sichere Netzarchitekturen wie SCION konzeptionell relevant. Das zugrunde liegende Prinzip reicht über eine Technologie hinaus: Ein System kann nicht als hoch souverän gelten, wenn wesentliche Abhängigkeiten außerhalb der beabsichtigten Kontrollgrenze unbekannt oder unbeherrschbar bleiben.

Notfallwiederherstellung deckt Schwächen in Residenzkonzepten auf

Viele Architekturen erfüllen ihr gewünschtes Residenzmodell nur im Normalbetrieb.

Die primäre Last liegt im Inland, das sekundäre Backup jedoch im Ausland. Lokales Personal betreibt das System normal, doch die Notfallwiederherstellung verlangt Administratoren im Ausland. Kundenkontrollierte Schlüssel schützen die Produktion, aber die Notfallwiederherstellung hängt von Zugangsdaten des Anbieters ab. Der normale KI-Endpunkt liegt im Inland, während die Ausweich-Inferenz international läuft.

Diese Widersprüche bleiben häufig unsichtbar, bis eine Kontinuitätsübung oder ein echter Vorfall sie aufdeckt.

Resilienz und Souveränität müssen deshalb gemeinsam entworfen werden.

Eine Wiederherstellungsarchitektur sollte festlegen, welche Datenklassen verschoben werden dürfen, welche Rechtsordnungen zulässig sind, wo Schlüssel unter Kontrolle bleiben, wer die Wiederherstellung ausführen darf und welche reduzierten Dienste verfügbar bleiben müssen, wenn ein grenzüberschreitendes Failover nicht akzeptabel ist.

Ein Notfallplan, der die Infrastruktur nur unter Verletzung der beabsichtigten regulatorischen oder souveränen Grenze wiederherstellen kann, ist kein tragfähiger Plan.

Internationale Normen wie ISO 22301 können eine strukturierte Basislinie für das Kontinuitätsmanagement liefern, während ISO/IEC 27001 das umgebende Informationssicherheits-Managementsystem stützt. Auch die saudischen Rahmenwerke für national kritische Systeme betonen ausdrücklich die Cybersicherheits-Resilienz und unterstreichen, dass nationale Kontrolle und Kontinuität nicht getrennt entworfen werden können.

Eine souveräne Cloud ist ein Betriebsmodell, kein reines Standortetikett

Der Begriff „souveräne Cloud“ kann nützlich sein, kann aber auch die eigentlichen Engineering-Fragen verdecken.

Eine Plattform wird erst dann sinnvoll souverän, wenn die Organisation die für ihr Bedrohungs- und Regulierungsmodell relevanten Dimensionen versteht und kontrolliert: Datenstandort, Verarbeitung, Identität, privilegierte Administration, Verschlüsselung und Schlüsselverwahrung, Netzabhängigkeit, Software-Lieferkette, Control Planes des Anbieters, Kontinuität, Gerichtsstand, Prüfbarkeit und Ausstieg.

Unterschiedliche Kunden brauchen unterschiedliche Kontrollniveaus.

Eine kommerzielle Analyseplattform sollte nicht automatisch die Architektur einer Last aus dem Bereich nationaler Sicherheit erben. Ebenso sollte ein staatliches oder kritisches Infrastrukturprogramm keine kommerzielle Cloud-Architektur akzeptieren, nur weil im Marketingmaterial das Wort souverän steht.

Der richtige Entwurf folgt Klassifizierung und Folgenabschätzung.

Deshalb lautet die nützliche Frage nicht einfach, ob Daten am Golf bleiben müssen.

Sie lautet, ob die Organisation für jede relevante Informationsklasse erklären kann, wer sie speichern, verarbeiten, übertragen, verwalten, entschlüsseln und wiederherstellen kann — aus welcher Rechtsordnung, unter welcher Befugnis und was geschieht, wenn die normale Betriebsumgebung ausfällt.

Liegen diese Antworten vor, wird Residenz zu einer Architekturentscheidung.

Davor ist sie nur ein Ort.