Die Illusion der Datensouveränität: Warum „Local Zones“ nicht ausreichen

Die Geografie einer Lüge

In den eleganten, verglasten Konferenzräumen von Frankfurt, Paris und Amsterdam hat sich eine tröstliche Fiktion festgesetzt. Es ist die Fiktion der „Local Zone“. Sie erzählt CIOs und Regierungsministern gleichermaßen eine einfache, beruhigende Geschichte: Wenn Sie Ihre Daten in einem Rechenzentrum speichern, das physisch auf europäischem Boden steht (vielleicht eine unscheinbare Lagerhalle am Stadtrand von Dublin oder ein Bunker in der Nähe von Frankfurt), sind Sie geschützt. Sie sind konform. Sie sind souverän.

Diese Geschichte wird von den größten Hyperscalern der Welt erzählt: Amazon Web Services, Microsoft Azure, Google Cloud. Sie wird von Beschaffungsbeauftragten wiederholt, von teuren Beratern bestätigt und von Compliance-Teams abgezeichnet, die verzweifelt versuchen, ein Häkchen zu setzen. Sie ist das Fundament von IT-Ausgaben in Milliardenhöhe in der gesamten Europäischen Union.

Sie ist außerdem, um es ganz offen zu sagen, eine gefährliche Illusion.

Im Jahr 2025 ist der physische Standort der unwichtigste Faktor für Datensouveränität. Er ist ein Relikt aus einer Zeit, als Daten noch physisches Papier in einem Aktenschrank waren. Im digitalen Zeitalter mag das physische Laufwerk, auf dem Ihre Daten ruhen, in einem Server-Rack in Dublin stehen, aber wenn das Identitätsmanagementsystem, das den Zugriff darauf steuert, in Virginia läuft, sind Sie nicht souverän. Wenn das Support-Team, das den Server repariert, einem Manager in Seattle untersteht, sind Sie nicht souverän. Und wenn die Verschlüsselungsschlüssel, die Ihre Daten sperren, letztlich von einer US-Einheit verwaltet werden können, die dem CLOUD Act unterliegt, sind Sie ganz sicher nicht souverän.

Wir bauen unsere kritische Infrastruktur (unsere Energienetze, unsere Gesundheitssysteme, unsere Bankbücher, unsere Verteidigungslogistik) auf einem Fundament aus Sand. Wir haben „Datenhaltung“ mit „Souveränität“ verwechselt. Und in einer Welt zunehmender geopolitischer Instabilität könnte uns diese Verwechslung unsere Unabhängigkeit kosten.

Die Anatomie der Cloud: Muskel vs. Gehirn

Um zu verstehen, warum das „Local Zone“-Modell scheitert, muss man hinter die Marketingbroschüren blicken und die Architektur der modernen Public Cloud verstehen. Wir neigen dazu, die Cloud als eine Ansammlung von Servern (Rechenleistung) und Festplatten (Speicher) zu betrachten. Aber das sind nur die Muskeln. Das „Gehirn“ der Cloud ist die Control Plane (Steuerungsebene).

Die Control Plane ist die zentrale Softwareschicht, die alles orchestriert. Sie entscheidet, wer eine virtuelle Maschine starten darf. Sie entscheidet, wer auf eine Datenbank zugreifen darf. Sie verwaltet die Abrechnung. Sie pusht die Software-Updates. Sie hält die Hauptschlüssel. Und entscheidend ist: Bei den großen US-Hyperscalern ist diese Control Plane ein globales, einheitliches System. Sie ist nicht föderiert; sie ist zentralisiert. Und sie wird fast ausnahmslos von den Vereinigten Staaten aus gesteuert.

Wenn eine europäische Bank ihr Kernbankensystem in einer „souveränen“ Region eines US-Hyperscalers bereitstellt, mietet sie im Grunde ein Zimmer in einem riesigen Hotel. Sie kann die Tür zu ihrem Zimmer abschließen, sicher. Sie kann ihre eigenen Möbel mitbringen. Aber der Vermieter kontrolliert das Sicherheitssystem des Gebäudes, den Strom, das Wasser, die Aufzüge und (entscheidend) den Generalschlüssel, der alle anderen außer Kraft setzt.

Diese Zentralisierung schafft zwei unterschiedliche Risiken: das technische Risiko und das rechtliche Risiko.

Das technische Risiko: Die Abhängigkeit von US-East-1

Die technische Verwundbarkeit dieser Architektur ist nicht theoretisch; sie wurde immer wieder unter Beweis gestellt. Erfahrene Cloud-Ingenieure kennen den Witz: „Wenn US-East-1 niest, bekommt das Internet eine Erkältung.“ US-East-1 (Northern Virginia) ist die primäre Region für viele AWS-Dienste und hostet oft die globale Control Plane für spezifische Funktionen.

Wir haben mehrere Fälle erlebt, in denen Ausfälle in Virginia Dienste in EU-West (Irland) oder EU-Central (Frankfurt) lahmgelegt haben. Warum? Weil die lokale Region in Europa keine Benutzer authentifizieren oder keine neuen Ressourcen bereitstellen konnte, da sie den Kontakt zum „Mutterschiff“ in den USA verloren hatte. Wenn ein Glasfaserschnitt, ein Softwarefehler oder ein Cyberangriff in Virginia Ihr Geschäft in Berlin stoppen kann, ist Ihr Geschäft nicht souverän. Sie hängen am Tropf.

Wahre Souveränität erfordert den „Internet-Stecker-Test“. Wenn Sie die Glasfaserkabel kappen würden, die Europa mit den Vereinigten Staaten verbinden: Würde Ihre digitale Infrastruktur weiterhin funktionieren? Für die meisten europäischen Unternehmen, die auf US-Clouds laufen, lautet die Antwort erschreckenderweise „Nein“. Sie würden die Möglichkeit verlieren, sich einzuloggen (Identity and Access Management ruft oft zu Hause an), zu skalieren (Control Plane nicht erreichbar) und möglicherweise Daten zu entschlüsseln (Key Management Service nicht erreichbar).

Das rechtliche Risiko: Der lange Arm des US-Gesetzes

Die rechtliche Dimension ist noch gravierender als die technische, und genau hier bricht das „Local Zone“-Marketing vollständig zusammen. Die Vereinigten Staaten haben einen rechtlichen Rahmen, der die Idee der Datensouveränität aufgrund des physischen Standorts explizit ablehnt.

Der CLOUD Act

Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act), verabschiedet 2018, hat die Spielregeln verändert. Er wurde entwickelt, um ein spezifisches Problem für die US-Strafverfolgung zu lösen: Sie wollten Daten, die von Microsoft in Irland gespeichert wurden, und Microsoft weigerte sich, diese herauszugeben, mit dem Argument, sie unterlägen der irischen Gerichtsbarkeit. Der CLOUD Act machte dieses Argument hinfällig.

Nach dem CLOUD Act können US-Strafverfolgungsbehörden jedes in den USA ansässige Technologieunternehmen (oder jedes Unternehmen mit einer „ausreichenden Verbindung“ zu den USA) zwingen, Daten herauszugeben, die sie kontrollieren, unabhängig davon, wo diese Daten gespeichert sind. Es spielt keine Rolle, ob der Server in Paris steht. Es spielt keine Rolle, ob die Tochtergesellschaft, die die Daten hält, eine irische Limited Liability Company ist. Wenn die Muttergesellschaft amerikanisch ist, sind die Daten für US-Gerichte greifbar.

Dies ist gesetzlich festgeschriebene Exterritorialität. Sie behandelt amerikanische Technologieunternehmen als verlängerten Arm des amerikanischen Staates, mit der Macht, in fremde Gerichtsbarkeiten einzugreifen und Informationen zu extrahieren, ohne den traditionellen Weg über Rechtshilfeabkommen (MLAT) zu gehen.

FISA 702 und Upstream-Überwachung

Jenseits der normalen Strafverfolgung gibt es den Bereich der nationalen Sicherheit. Section 702 des Foreign Intelligence Surveillance Act (FISA) erlaubt es US-Geheimdiensten (wie der NSA), US-Anbieter elektronischer Kommunikationsdienste zur Unterstützung bei der Überwachung von Nicht-US-Personen außerhalb der Vereinigten Staaten zu verpflichten.

Hier geht es nicht darum, Kriminelle zu fangen; es geht um Auslandsaufklärung. „Foreign Intelligence“ ist ein breiter Begriff, der alles von Terrorismus bis zu Handelsverhandlungen, diplomatischen Strategien und industriellen Fähigkeiten umfassen kann. Unter FISA 702 kann ein US-Cloud-Anbieter angewiesen werden, Kommunikation oder Daten abzufangen. Entscheidend ist, dass es ihnen oft untersagt ist, die Existenz einer solchen Anordnung offenzulegen.

Der Europäische Gerichtshof (EuGH) ist sich dessen sehr wohl bewusst. Im wegweisenden Schrems II-Urteil im Jahr 2020 erklärte der EuGH das „Privacy Shield“-Datentransferabkommen zwischen der EU und den USA für ungültig. Die Begründung des Gerichts war explizit: US-Überwachungsgesetze (FISA 702, EO 12333) sind unverhältnismäßig und bieten europäischen Bürgern keine einklagbaren Rechte. Daher bieten die USA keinen „angemessenen Schutz“ für personenbezogene Daten, wie es die DSGVO verlangt.

Wir haben also eine Situation, in der europäische Unternehmen US-Clouds nutzen, um sensible Daten zu speichern, und vorgeben, diese blieben in Europa, um interne Compliance-Vorgaben zu erfüllen, während das höchste Gericht in Europa entschieden hat, dass der US-Rechtsrahmen diese Daten unsicher macht. Es ist eine kognitive Dissonanz epischen Ausmaßes. Es ist eine Compliance-Zeitbombe, die darauf wartet zu explodieren.

Die „Break Glass“-Hintertür

Cloud-Anbieter ignorieren das nicht. Sie wissen, dass es ein Verkaufshindernis ist. Also kontern sie mit „Sovereign Cloud“-Angeboten. Sie beanspruchen „Operationelle Souveränität“. Sie sagen: „Nur EU-Personal hat Zugriff auf Ihre Daten.“ Sie richten beeindruckend klingende rechtliche Strukturen, unabhängige Treuhänder und Mantelgesellschaften ein.

Aber wenn man in die Service Level Agreements (SLAs) und das Kleingedruckte der technischen Dokumentation eintaucht, findet man fast immer eine „Break Glass“-Klausel. Dies ist eine Bestimmung, die dem globalen (US-)Support-Team im Falle eines „kritischen Vorfalls“, eines „technischen Notfalls“ oder einer „Sicherheitsbedrohung“, die das lokale Team nicht bewältigen kann, Zugriff auf die lokale Infrastruktur gewährt.

Aus Sicht der Sicherheitsarchitektur ist ein „Break Glass“-Mechanismus eine Hintertür. Es ist ein privilegierter Zugriffspfad, der die Standardkontrollen umgeht. Und wer entscheidet, wann das Glas eingeschlagen wird? Der Anbieter. Wer definiert, was einen „kritischen Vorfall“ darstellt? Der Anbieter.

In einer geopolitischen Krise (vielleicht ein Handelskrieg oder ein Sanktionsstreit) wird dieser „Break Glass“-Mechanismus zu einer strategischen Schwachstelle. Eine ausländische Regierung könnte den Anbieter theoretisch zwingen, das „Glas einzuschlagen“, nicht um einen Server zu reparieren, sondern um Daten zu exfiltrieren, Sanktionen durchzusetzen oder den Betrieb zu stören.

Selbst ohne böse Absicht stellt das „Follow the Sun“-Supportmodell ein Risiko dar. Wenn ein komplexes Datenbank-Korruptionsproblem um 3 Uhr morgens in Frankfurt auftritt, hat das lokale Support-Team möglicherweise nicht die tiefe Expertise, es zu beheben. Sie eskalieren es an das Kern-Engineering-Team. Wo befindet sich dieses Team? Meistens in Seattle oder im Silicon Valley. Um das Problem zu beheben, benötigt der Ingenieur in Seattle Logs, Speicherabbilder und vielleicht Zugriff auf das Datenvolumen. In dem Moment, in dem dieser Zugriff gewährt wird, ist die Souveränität verletzt.

Wahre Souveränität: Die Dweve-Definition

Wir bei Dweve glauben, dass der Begriff „Souveränität“ so weit verwässert wurde, dass er bedeutungslos geworden ist. Wir müssen ihn zurückerobern. Wir brauchen eine strenge, technisch fundierte Definition von Souveränität, keine juristische.

Für uns ist ein System nur dann souverän, wenn es drei harte Kriterien erfüllt. Dies sind keine „Nice-to-haves“: Es sind binäre Bestanden/Nicht-bestanden-Tests.

1. Technische Autonomie (Der getrennte Zustand)

Das System muss in der Lage sein, ohne jegliche Verbindung zu einer zentralen, ausländischen Control Plane vollständig zu funktionieren. Das bedeutet, dass das „Gehirn“ des Systems (der Scheduler, der Identity Provider, der Key Manager) lokal im Deployment vorhanden sein muss.

Die meisten Public-Cloud-Stacks fallen bei diesem Test sofort durch. Sie benötigen eine ständige Verbindung zur globalen Control Plane für Abrechnung, Identität und Verwaltung. Dweve ist anders konzipiert. Unsere Architektur ist Edge-First und dezentralisiert. Jeder Dweve-Cluster ist ein in sich geschlossenes Universum. Er hat seinen eigenen lokalen Konsensmechanismus, seinen eigenen lokalen Identitätsspeicher und seine eigene lokale Steuerungslogik.

Sie können einen Dweve-Cluster in einem U-Boot, einem sicheren Bunker oder einer Fabrikhalle ohne Internetverbindung betreiben, und er wird unbegrenzt funktionieren. Er behandelt das Fehlen des Internets im Wesentlichen als Netzwerkpartitionierung und arbeitet weiter. Sie können neue Ressourcen bereitstellen, Modelle aktualisieren und Benutzer lokal verwalten. Wenn die Verbindung wiederhergestellt ist, kann er sich synchronisieren (wenn Sie das wollen), aber er muss es nie.

2. Rechtliche Immunität

Die Einheit, die die Infrastruktur betreibt, muss immun gegen exterritoriale Datenanfragen sein. Das bedeutet, sie darf keine Tochtergesellschaft eines Unternehmens sein, das dem CLOUD Act oder FISA 702 unterliegt. Es muss eine europäische Einheit sein, die nur europäischem Recht unterliegt.

Deshalb hat Dweve seinen Sitz in der EU, ohne US-Muttergesellschaft und ohne US-Investoren, die kontrollierende Anteile halten. Wir sind nicht antiamerikanisch: Wir lieben amerikanische Innovation. Wir sind pro-souverän. Wir können nicht von einem ausländischen Gericht gezwungen werden, unsere Kunden zu verraten, weil wir einfach nicht dessen Gerichtsbarkeit unterliegen.

3. Kryptographische Kontrolle (HYOK > BYOK)

Verschlüsselung ist nur so gut wie das Schlüsselmanagement. Der Industriestandard „Bring Your Own Key“ (BYOK) ist ein irreführender Begriff. In einem BYOK-Modell generieren Sie einen Schlüssel und laden ihn in den Key Management Service (KMS) des Cloud-Anbieters hoch. Die Software des Anbieters verwendet dann diesen Schlüssel, um Ihre Daten zu verschlüsseln und zu entschlüsseln.

Das bedeutet, der Anbieter hat den Schlüssel. Er mag vielleicht nur für eine Millisekunde im Speicher sein, aber er ist da. Wenn die Software des Anbieters kompromittiert wird oder wenn er gezwungen wird, seine Software zu modifizieren, um den Schlüssel abzufangen, sind Ihre Daten offengelegt. Sie vertrauen darauf, dass der Anbieter nicht hineinschaut.

Wahre Souveränität erfordert „Hold Your Own Key“ (HYOK). In diesem Modell verlassen die Schlüssel niemals Ihr Hardware-Sicherheitsmodul (HSM), das in Ihren Räumlichkeiten verbleibt. Der Cloud-Anbieter sieht den Schlüssel nie. Kryptographische Operationen finden innerhalb einer Trusted Execution Environment (TEE) oder lokal statt.

Die Speicherschicht von Dweve basiert auf diesem Prinzip. Wir halten Ihre Schlüssel nicht. Wir wollen Ihre Schlüssel nicht. Wenn wir einen Gerichtsbeschluss erhalten, wollen wir ehrlich sagen können: „Wir können Ihnen nicht helfen. Die Daten sind für uns mathematisch unzugänglich.“

Der strategische Imperativ

Diese Diskussion wird oft als Compliance-Thema geführt: wie man DSGVO-Strafen vermeidet. Aber das ist eine kurzsichtige Sichtweise. Hier geht es um das strategische Überleben im 21. Jahrhundert.

Wir treten in eine Ära des „technologischen Merkantilismus“ ein. Nationen nutzen Technologie-Stacks als Hebel geopolitischer Macht. Lieferketten werden als Waffen eingesetzt. Halbleiter, KI-Modelle und Cloud-Infrastruktur sind das neue Öl, der neue Stahl und die neuen Schifffahrtsrouten.

Europa hat nach dem russischen Einmarsch in die Ukraine eine schmerzhafte Lektion über Abhängigkeit im Energiebereich gelernt. Wir haben zu spät erkannt, dass es ein katastrophaler strategischer Fehler war, unsere gesamte Industriewirtschaft auf billigem Gas von einem einzigen, potenziell feindlichen Lieferanten aufzubauen. Wir haben Milliarden ausgegeben und einen massiven wirtschaftlichen Schock erlitten, um uns zu entkoppeln.

Wir laufen jetzt Gefahr, genau denselben Fehler mit unserer digitalen Infrastruktur zu wiederholen. Wir bauen unsere digitale Wirtschaft (unsere KI, unsere Data Lakes, unsere Smart Cities) auf der proprietären Infrastruktur einer einzigen ausländischen Macht auf. Sich bei seiner kritischen Infrastruktur auf eine ausländische Control Plane zu verlassen, ist strategische Fahrlässigkeit.

Die „Local Zone“ ist eine bequeme Illusion. Sie erlaubt uns vorzugeben, das Problem gelöst zu haben, ohne die harte Arbeit zu leisten, wahre Unabhängigkeit aufzubauen. Aber Illusionen, so tröstlich sie auch sein mögen, zerbrechen irgendwann.

Es ist an der Zeit, eine Infrastruktur zu bauen, die real ist. Eine Infrastruktur, die auf eigenen Beinen steht. Eine Infrastruktur, die wirklich, technisch und rechtlich souverän ist. Das ist die Mission von Dweve.

Dweve baut wirklich souveräne KI-Infrastruktur für europäische Unternehmen. Unsere Architektur besteht alle drei Souveränitätstests: technische Autonomie (getrennter Betrieb), rechtliche Immunität (nur EU-Gerichtsbarkeit) und kryptographische Kontrolle (HYOK-Schlüsselmanagement). Keine „Break Glass“-Hintertüren. Keine ausländischen Control Planes. Keine Illusionen. Echte Souveränität, von Grund auf neu entwickelt.