Die Illusion der Datensouveränität: Warum „Local Zones“ nicht genügen
Die Geografie einer Lüge
In den eleganten Konferenzräumen mit Glaswänden in Frankfurt, Paris und Amsterdam hat sich eine beruhigende Fiktion eingenistet. Es ist die Fiktion der „lokalen Zone". Sie erzählt CIOs und Regierungsministern gleichermaßen eine einfache, beruhigende Geschichte: Wenn Sie Ihre Daten in einem Rechenzentrum speichern, das sich physisch auf europäischem Boden befindet (vielleicht ein unscheinbares Lagerhaus am Stadtrand von Dublin oder ein Bunker bei 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 Einkäufern wiederholt, von teuren Beratern bestätigt und von Compliance-Teams abgesegnet, die verzweifelt einen Haken setzen wollen. Sie ist das Fundament für IT-Ausgaben in Höhe von Milliarden Euro in der gesamten Europäischen Union.
Sie ist auch, um es deutlich zu sagen, eine gefährliche Illusion.
Im Jahr 2025 ist der physische Standort der am wenigsten wichtige Faktor für die Datensouveränität. Er ist ein Relikt aus einer Zeit, als Daten physisches Papier in einem Aktenschrank waren. Im digitalen Zeitalter mag sich das physische Laufwerk, auf dem Ihre Daten ruhen, in einem Serverrack in Dublin befinden, aber wenn das Identitätsmanagementsystem, das den Zugriff darauf kontrolliert, 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-Entität 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 Bankkonten, unsere Verteidigungslogistik) auf einem Fundament aus Sand. Wir haben „Residenz" mit „Souveränität" verwechselt. Und in einer Welt zunehmender geopolitischer Instabilität könnte uns diese Verwechslung unsere Unabhängigkeit kosten.
Das ist keine paranoide Spekulation. Das ist keine anti-amerikanische Stimmung. Das ist eine nüchterne, technische Analyse darüber, wie moderne Cloud-Infrastruktur tatsächlich funktioniert und was diese Architektur für die europäische Autonomie bedeutet. Die Wahrheit ist unbequem, aber sie zu ignorieren ist weitaus gefährlicher, als sich ihr zu stellen.
Die Anatomie der Cloud: Muskeln gegen Gehirn
Um zu verstehen, warum das Modell der „Local Zones" scheitert, müssen Sie über die Marketingbroschüren hinausblicken und die Architektur der modernen Public Cloud verstehen. Wir neigen dazu, die Cloud als eine Ansammlung von Servern (Compute) und Festplatten (Storage) zu betrachten. Doch das ist nur die Muskulatur. Das „Gehirn" der Cloud ist die Control Plane.
Die Control Plane ist die zentralisierte Softwareebene, die alles orchestriert. Sie entscheidet, wer eine virtuelle Maschine starten darf. Sie entscheidet, wer auf eine Datenbank zugreifen darf. Sie verwaltet die Abrechnung. Sie verteilt die Software-Updates. Sie verwahrt die Master-Schlüssel. Und entscheidend ist: Bei den großen US-Hyperscalern ist diese Control Plane ein globales, einheitliches System. Sie ist nicht föderiert, sondern zentralisiert. Und sie wird fast ausnahmslos von den Vereinigten Staaten aus gesteuert.
Wenn eine europäische Bank ihr Kernbanksystem in einer „souveränen" Region eines US-Hyperscalers bereitstellt, mietet sie im Grunde ein Zimmer in einem riesigen Hotel. Sie können die Tür zu ihrem Zimmer abschließen, sicher. Sie können eigene Möbel mitbringen. Aber der Vermieter kontrolliert die Sicherheitsanlage des Gebäudes, den Strom, das Wasser, die Aufzüge und (entscheidend) den Generalschlüssel, der alle anderen übersteuert.
Lassen Sie uns konkret sagen, was diese Control Plane tatsächlich umfasst:
Identity and Access Management (IAM): Jede Anfrage, in der Cloud irgendetwas zu tun, erfordert Authentifizierung und Autorisierung. Wenn Sie sich anmelden, wenn Sie eine Ressource erstellen, wenn Sie auf eine Datenbank zugreifen, geht die Anfrage an das IAM-System. Bei den meisten Hyperscalern läuft dieses System in US-Rechenzentren. Selbst wenn Ihre Compute-Ressourcen in Frankfurt liegen, könnte Ihre Authentifizierungsanfrage nach Virginia und zurück reisen.
Key Management Service (KMS): Verschlüsselung ist nur so gut wie das Schlüsselmanagement. Der KMS des Hyperscalers verwahrt oder verwaltet die kryptografischen Schlüssel, die Ihre Daten verschlüsseln. Selbst „kundenverwaltete Schlüssel" laufen bei kryptografischen Operationen typischerweise durch die KMS-Infrastruktur des Anbieters.
Resource Scheduler: Das System, das entscheidet, auf welchem physischen Server Ihre Workload läuft, wie Speicher und CPU zugewiesen werden und wann Workloads zwischen Maschinen verschoben werden. Dies ist tief in die globale Plattform integriert.
Billing und Metering: Jede Ressource, die Sie nutzen, wird erfasst, gemessen und abgerechnet. Diese Telemetriedaten fließen an zentrale Systeme und geben dem Anbieter einen detaillierten Einblick in Ihre Nutzungsmuster.
Software-Updates und Patches: Der Hypervisor, die Container-Runtime, die verwaltete Datenbank-Engine: Alle erhalten automatische Updates, die von der zentralen Infrastruktur aus verteilt werden. Sie können sich nicht dagegen entscheiden, ohne Sicherheitspatches zu verlieren.
Diese Zentralisierung schafft zwei unterschiedliche Risiken: das technische Risiko und das rechtliche Risiko. Beide sind schwerwiegend. Beide werden unterschätzt. Und beiden wird es schlechter gehen, nicht besser.
Das technische Risiko: Die US-East-1-Abhängigkeit
Die technische Verwundbarkeit dieser Architektur ist nicht theoretisch; sie wurde immer wieder demonstriert. Erfahrene Cloud-Ingenieure kennen den Witz: „Wenn US-East-1 niest, erkältet sich das Internet." US-East-1 (Nord-Virginia) ist die primäre Region für viele AWS-Dienste und beherbergt oft die globale Control Plane für bestimmte Funktionen.
Wir haben mehrfach erlebt, dass Ausfälle in Virginia Dienste in EU-West (Irland) oder EU-Central (Frankfurt) lahmgelegt haben. Warum? Weil die lokale Region in Europa Benutzer nicht authentifizieren oder neue Ressourcen bereitstellen konnte, da sie den Kontakt zum „Mothership“ in den USA verloren hatte. Wenn ein Glasfaserkabelbruch, ein Softwarefehler oder ein Cyberangriff in Virginia Ihr Geschäft in Berlin stoppen kann, ist Ihr Geschäft nicht souverän. Sie sind angebunden.
Denken Sie an den AWS-Ausfall im Dezember 2021. Eine Netzwerkfehlkonfiguration in US-East-1 legte nicht nur Dienste in dieser Region lahm, sondern führte auch zu Folgeausfällen, die AWS-Kunden weltweit betrafen. Europäische Unternehmen, die „EU-only“-Bereitstellungen betrieben, konnten plötzlich nicht mehr auf ihre Dashboards zugreifen, keine neuen Ressourcen bereitstellen und sich in einigen Fällen nicht einmal bei ihren eigenen Systemen authentifizieren.
Oder denken Sie an den Azure-Ausfall im Oktober 2022, bei dem eine Konfigurationsänderung in der zentralen Infrastruktur zu Authentifizierungsfehlern in mehreren Regionen führte. Europäische Kunden konnten sich nicht beim Azure-Portal anmelden, obwohl ihre Daten- und Rechenressourcen in europäischen Rechenzentren technisch betriebsbereit waren. Der Muskel war in Ordnung; das Gehirn war offline.
Wahre Souveränität erfordert den „Internet-Pull-Test“. Wenn Sie die Glasfaserkabel, die Europa mit den USA verbinden, physisch durchtrennen würden, würde Ihre digitale Infrastruktur dann weiterhin funktionieren? Für die meisten europäischen Unternehmen, die US-Clouds nutzen, lautet die Antwort ein erschreckendes „Nein“. Sie würden die Fähigkeit verlieren, sich anzumelden (Identity and Access Management meldet sich oft in der Heimatzentrale), die Fähigkeit zu skalieren (Control Plane nicht erreichbar) und möglicherweise die Fähigkeit, Daten zu entschlüsseln (Key Management Service nicht erreichbar).
Dies ist kein abwegiges Szenario. In Zeiten geopolitischer Krisen wurden Unterseekabel beschädigt (versehentlich und absichtlich). Sanktionsregime können die Netzwerkkonnektivität kappen. Cyberangriffe können sich gegen die Backbone-Infrastruktur richten. Ein souveränes System muss in der Lage sein, durch solche Szenarien zu operieren, nicht an ihnen zu scheitern.
Das rechtliche Risiko: Der lange Arm des US-Rechts
Die rechtliche Dimension ist noch deutlicher als die technische, und genau hier scheitert das „Local Zone“-Marketing vollständig. Die Vereinigten Staaten haben einen Rechtsrahmen, der die Idee der Datensouveränität auf Grundlage des physischen Standorts ausdrücklich ablehnt.
Der CLOUD Act: Extraterritorialität kodifiziert
Der US-amerikanische CLOUD Act (Clarifying Lawful Overseas Use of Data Act), verabschiedet im Jahr 2018, war ein Wendepunkt. Er wurde entwickelt, um ein spezifisches Problem für die US-Strafverfolgung zu lösen: Sie wollten Daten, die Microsoft in Irland besaß, und Microsoft weigerte sich, sie herauszugeben, mit der Begründung, sie unterlägen der irischen Gerichtsbarkeit. Der CLOUD Act machte dieses Argument hinfällig.
Nach dem CLOUD Act kann die US-Strafverfolgung jedes in den USA ansässige Technologieunternehmen (oder jedes Unternehmen mit einer „hinreichenden Verbindung“ zu den USA) zwingen, Daten herauszugeben, die es kontrolliert, 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 erreichbar.
Dies ist Extraterritorialität, die in Gesetze gegossen wurde. Es behandelt amerikanische Technologieunternehmen als Verlängerungen des amerikanischen Staates, mit der Macht, in fremde Rechtsräume hineinzureichen und Informationen zu beschaffen, ohne den traditionellen Prozess des Mutual Legal Assistance Treaty (MLAT) zu durchlaufen.
Der CLOUD Act enthält zwar Bestimmungen für Einwände ausländischer Regierungen. Ein Anbieter kann eine Anordnung anfechten, wenn er glaubt, dass die Einhaltung gegen das Recht eines anderen Landes verstoßen würde. Diese Anfechtungen sind jedoch teuer, zeitaufwendig und oft erfolglos. Die Grundposition ist die Einhaltung des US-Rechts.
FISA 702 und Upstream-Überwachung
Über die normale Strafverfolgung hinaus gibt es den Bereich der nationalen Sicherheit. Abschnitt 702 des Foreign Intelligence Surveillance Act (FISA) erlaubt es US-Geheimdiensten (wie der NSA), US-amerikanische Anbieter elektronischer Kommunikationsdienste zu verpflichten, bei der Überwachung von Nicht-US-Bürgern außerhalb der Vereinigten Staaten zu helfen.
Hierbei geht es nicht um die Ergreifung von Straftätern, sondern um die Gewinnung ausländischer Informationen. „Ausländische Informationen" ist ein weit gefasster Begriff, der alles von Terrorismus über Handelsverhandlungen und diplomatische Strategien bis hin zu industriellen Fähigkeiten umfassen kann. Nach FISA 702 kann ein US-Cloud-Anbieter angewiesen werden, Kommunikation oder Daten abzufangen. Entscheidend ist, dass solche Anbieter oft daran gehindert werden, die Existenz einer solchen Anordnung offenzulegen.
Der Anwendungsbereich von FISA 702 ist enorm. Laut freigegebenen Berichten werden jährlich Zehntausende von Zielen überwacht. Und zu den „Zielen" können nicht nur Einzelpersonen gehören, sondern auch E-Mail-Adressen, Telefonnummern und digitale Selektoren, die mit vielen unschuldigen Kommunikationsvorgängen übereinstimmen können.
Der Europäische Gerichtshof (EuGH) ist sich dessen durchaus bewusst. In dem wegweisenden Urteil Schrems II aus dem Jahr 2020 erklärte der EuGH das Datentransferabkommen „Privacy Shield" zwischen der EU und den USA für ungültig. Die Begründung des Gerichts war eindeutig: Die US-Überwachungsgesetze (FISA 702, EO 12333) sind unverhältnismäßig und gewähren europäischen Bürgern keine einklagbaren Rechte. Daher bieten die USA keinen „angemessenen Schutz" für personenbezogene Daten, wie es die DSGVO verlangt.
Der im Jahr 2023 angenommene EU-US Data Privacy Framework versuchte, diese Bedenken auszuräumen. Kritiker argumentieren jedoch, dass er weitgehend kosmetischer Natur sei, und eine weitere Schrems-Klage (Schrems III) wird allgemein erwartet. Die grundlegende Unvereinbarkeit zwischen US-Überwachungsrecht und europäischem Datenschutzrecht ist nicht gelöst worden; sie wurde lediglich übertüncht.
So haben wir eine Situation, in der europäische Unternehmen US-Clouds zur Speicherung sensibler Daten nutzen und so tun, als blieben diese Daten zur Erfüllung interner Compliance-Anforderungen in Europa, während das höchste Gericht Europas entschieden hat, dass der US-amerikanische Rechtsrahmen diese Daten unsicher macht. Das 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 dieses Problem nicht. Sie wissen, dass es ein Verkaufshindernis ist. Also kontern sie mit „Sovereign Cloud"-Angeboten. Sie behaupten „Operational Sovereignty". Sie sagen: „Nur EU-Personal hat Zugriff auf Ihre Daten." Sie errichten beeindruckend klingende Rechtsstrukturen, unabhängige Treuhänder und Briefkastenfirmen.
Diese Angebote tragen verschiedene Namen: AWS Sovereign Regions, Azure Sovereignty Services, Google Sovereign Cloud, Oracle Sovereign Cloud. Sie versprechen reine EU-Operationen, reines EU-Personal und manchmal sogar Partnerschaften mit europäischen Unternehmen, um rechtliche Hürden gegen die US-Zuständigkeit zu schaffen.
Doch wer sich die Service Level Agreements (SLAs) und das Kleingedruckte der technischen Dokumentation genauer ansieht, wird fast immer eine „Break Glass"-Klausel finden. Dabei handelt es sich um eine Bestimmung, die es dem globalen (US-)Support-Team erlaubt, auf die lokale Infrastruktur zuzugreifen, falls ein „kritischer Vorfall", ein „technischer Notfall" oder eine „Sicherheitsbedrohung" eintritt, die das lokale Team nicht bewältigen kann.
Aus sicherheitstechnischer Sicht ist ein „Break Glass"-Mechanismus eine Hintertür. Er ist ein privilegierter Zugriffspfad, der die Standardkontrollen umgeht. Und wer entscheidet, wann das Glas gebrochen wird? Der Anbieter. Wer definiert, was ein „kritischer Vorfall" ist? Der Anbieter.
In einer geopolitischen Krise (vielleicht ein Handelskrieg oder ein Sanktionsstreit) wird dieser „Break Glass"-Mechanismus zu einer strategischen Verwundbarkeit. Eine fremde Regierung könnte den Anbieter theoretisch zwingen, das Glas nicht zur Reparatur eines Servers zu brechen, sondern um Daten abzuziehen, Sanktionen durchzusetzen oder den Betrieb zu stören.
Selbst ohne böse Absicht birgt das „Follow the Sun"-Supportmodell ein Risiko. Wenn um 3 Uhr morgens in Frankfurt ein komplexes Datenbankkorruptionsproblem auftritt, verfügt das lokale Support-Team möglicherweise nicht über das nötige Fachwissen, um es zu beheben. Es eskaliert das Problem an das zentrale Engineering-Team. Wo befindet sich dieses Team? Meist in Seattle oder im Silicon Valley. Um das Problem zu beheben, benötigt der Ingenieur in Seattle Protokolle, Speicherabbilder und möglicherweise Zugriff auf den Datenbestand. In dem Moment, in dem dieser Zugriff gewährt wird, ist die Souveränität verletzt.
Die zentralen Engineering-Teams dieser Plattformen werden nicht in Europa dupliziert. Es wäre unerschwinglich teuer, in jeder Region separate Entwicklungsteams zu unterhalten. Das Fachwissen, der Quellcode, die Debugging-Werkzeuge: Sie bleiben in den Vereinigten Staaten zentralisiert. Und diese Zentralisierung schafft eine unvermeidbare Abhängigkeit.
Der wirtschaftliche Druck: Warum dies über Compliance hinausgeht
Manche Leser denken vielleicht: „Das klingt nach einem Compliance- und Rechtsrisiko. Mein Unternehmen ist nicht in einer regulierten Branche tätig. Warum sollte mich das interessieren?"
Die Antwort ist wirtschaftlicher Natur. Und zunehmend geopolitischer Natur.
Die Bindung an einen Cloud-Anbieter erzeugt erhebliche Wechselkosten. Sobald sich Ihre Daten auf einer Plattform befinden, Ihre Anwendungen auf deren Diensten aufbauen und Ihr Team mit deren Werkzeugen geschult ist, wird ein Wechsel außerordentlich schwierig und teuer. Schätzungen zufolge kann die Migration einer größeren Cloud-Bereitstellung das Drei- bis Fünffache der jährlichen Cloud-Ausgaben kosten und Jahre in Anspruch nehmen.
Diese Bindung verschafft den Anbietern eine enorme Preissetzungsmacht. Hyperscaler haben die Preise stetig erhöht, wohl wissend, dass Kunden nur begrenzte Alternativen haben. Wenn AWS die Preise für S3-Speicher oder EC2-Instanzen erhöht, absorbieren die meisten Kunden die Kosten einfach. Die Wechselkosten sind zu hoch.
Stellen Sie sich nun vor, was passiert, wenn diese Bindung zur Waffe wird. Was, wenn die US-Regierung im Rahmen eines Handelsstreits beschließt, Beschränkungen für Cloud-Dienste für europäische Unternehmen in bestimmten Sektoren zu verhängen? Was, wenn Sanktionen gegen bestimmte Branchen oder Unternehmen verhängt werden? Was, wenn eine künftige US-Regierung beschließt, die technologische Dominanz als geopolitischen Hebel einzusetzen?
Diese Szenarien schienen vor einem Jahrzehnt noch weit hergeholt. Heute wirken sie deutlich weniger weit hergeholt. Wir haben erlebt, wie Technologie als Instrument des internationalen Drucks eingesetzt wurde (Huawei-Sanktionen, Halbleiter-Exportkontrollen, SWIFT-Ausschluss für Russland). Die Präzedenzfälle sind etabliert. Das Drehbuch existiert.
Ein Unternehmen mit souveräner Infrastruktur hat Optionen. Ein Unternehmen, das an eine ausländische Cloud gebunden ist, hat Verwundbarkeiten. Dies ist nicht nur eine Compliance-Überlegung; es ist eine Frage des strategischen Risikomanagements.
Wahre Souveränität: Die Dweve-Definition
Bei Dweve glauben wir, dass der Begriff „Souveränität" bis zur Bedeutungslosigkeit verwässert wurde. Wir müssen ihn zurückerobern. Wir brauchen eine rigorose, 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. Das sind keine „nice to haves", sondern binäre Bestehen/Nichtbestehen-Tests.
1. Technische Autonomie (Der getrennte Zustand)
Das System muss ohne jede Verbindung zu einer zentralen, externen Steuerungsebene vollständig funktionsfähig sein. Das bedeutet, dass das „Gehirn" des Systems (der Scheduler, der Identitätsanbieter, der Schlüsselmanager) lokal in der Bereitstellungsumgebung liegen muss.
Die meisten öffentlichen Cloud-Stacks scheitern sofort an diesem Test. Sie benötigen eine ständige Verbindung zur globalen Steuerungsebene für Abrechnung, Identität und Verwaltung. Dweve ist anders konzipiert. Unsere Architektur ist edge-first und dezentral. Jeder Dweve-Cluster ist ein in sich geschlossenes Universum. Er verfügt über einen eigenen lokalen Konsensmechanismus, einen eigenen lokalen Identitätsspeicher und eine eigene lokale Steuerungslogik.
Sie können einen Dweve-Cluster in einem U-Boot, einem sicheren Bunker oder in einer Fabrikhalle betreiben, der vom Internet getrennt ist, und er wird unbegrenzt funktionieren. Er behandelt das fehlende Internet im Wesentlichen als Netzwerkpartition und arbeitet einfach weiter. Sie können neue Ressourcen bereitstellen, Modelle aktualisieren und Benutzer lokal verwalten. Wenn die Verbindung wiederhergestellt ist, kann er synchronisieren (wenn Sie das möchten), aber er muss es nie.
Unsere Mesh-Architektur demonstriert dieses Prinzip in der Praxis. Dweve Mesh ist ein verteiltes KI-Ausführungsgewebe mit mehreren Knotentypen (Compute, Validator, Storage, Orchestrator), die unabhängig oder als Teil eines größeren Netzwerks arbeiten können. Jeder Knoten verfügt über vollständige lokale Fähigkeiten. Das Netzwerk erweitert die Funktionalität, ist aber für den Kernbetrieb nicht erforderlich.
2. Rechtliche Immunität
Die Einrichtung, die die Infrastruktur betreibt, muss gegenüber extraterritorialen Datenanfragen immun sein. Das bedeutet, sie darf keine Tochtergesellschaft eines Unternehmens sein, das dem CLOUD Act oder FISA 702 unterliegt. Sie muss eine europäische Einrichtung sein, die ausschließlich europäischem Recht unterliegt.
Aus diesem Grund hat Dweve seinen Sitz in der EU, ohne US-amerikanische Muttergesellschaft und ohne US-Investoren mit kontrollierenden Anteilen. Wir sind nicht anti-amerikanisch; wir lieben amerikanische Innovation. Wir sind für Souveränität. Wir können von einem ausländischen Gericht nicht gezwungen werden, unsere Kunden zu verraten, weil wir deren Gerichtsbarkeit schlicht nicht unterliegen.
Unsere Governance-Struktur ist darauf ausgelegt, diese Unabhängigkeit zu wahren. Unser Vorstand besteht aus europäischen Staatsangehörigen. Unsere Aktionärsstruktur schließt Einrichtungen aus, die ein rechtliches Risiko schaffen würden. Wir betreiben keine US-Tochtergesellschaften, die als Druckmittel dienen könnten.
3. Kryptografische 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 diesen Schlüssel dann, um Ihre Daten zu verschlüsseln und zu entschlüsseln.
Das bedeutet, der Anbieter hat den Schlüssel. Vielleicht nur für eine Millisekunde im Speicher, aber er ist da. Wenn die Software des Anbieters kompromittiert wird oder wenn er gezwungen wird, seine Software zu ändern, um den Schlüssel zu erfassen, sind Ihre Daten gefährdet. 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 Security Module (HSM), das sich in Ihren Räumlichkeiten befindet. Der Cloud-Anbieter sieht den Schlüssel nie. Kryptografische Operationen finden in einer Trusted Execution Environment (TEE) oder lokal statt.
Die Architektur von Dweve basiert auf diesem Prinzip. Unsere kryptografische Schicht umfasst Fähigkeiten zur homomorphen Verschlüsselung (BFV-Schema mit SIMD-Batching), sichere Mehrparteienberechnung (Shamir Secret Sharing), Zero-Knowledge-Beweise (Bulletproofs) und Post-Quanten-Kryptografie (Kyber KEM). Wir halten Ihre Schlüssel nicht. Wir wollen Ihre Schlüssel nicht. Wenn wir eine gerichtliche Anordnung erhalten, wollen wir ehrlich sagen können: „Wir können Ihnen nicht helfen. Die Daten sind für uns mathematisch unzugänglich."
Die strategische Notwendigkeit
Diese Diskussion wird oft als Compliance-Frage dargestellt: Wie vermeidet man GDPR-Bußgelder? Doch das ist eine kurzsichtige Sichtweise. Es geht um strategisches Überleben im 21. Jahrhundert.
Wir treten in eine Ära des "technologischen Merkantilismus" ein. Nationen nutzen Technologie-Stacks als Hebel geopolitischer Macht. Lieferketten werden als Waffe eingesetzt. Halbleiter, KI-Modelle und Cloud-Infrastruktur sind das neue Öl, der neue Stahl und die neuen Schifffahrtsrouten.
Europa hat nach der russischen Invasion in der Ukraine eine schmerzliche Lektion über Abhängigkeit bei Energie gelernt. Wir haben zu spät erkannt, dass es ein katastrophaler strategischer Fehler war, unsere gesamte industrielle Wirtschaft auf billigem Gas von einem einzigen, potenziell feindlichen Lieferanten aufzubauen. Wir haben Milliarden ausgegeben und einen massiven Wirtschaftsschock erlitten, um uns davon zu lösen.
Nun drohen wir, 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 für kritische Infrastruktur auf eine ausländische Control Plane zu verlassen, ist strategische Fahrlässigkeit.
Die Zahlen sind deutlich. Europäische Unternehmen geben jährlich über 50 Milliarden Euro für US-Cloud-Dienste aus. Das sind 50 Milliarden Euro, die die europäische Wirtschaft verlassen, Abhängigkeit schaffen und den amerikanischen Wettbewerbsvorteil ausbauen. Unterdessen haben europäische Cloud-Anbieter Mühe, mitzuhalten, da ihnen die Größe und Netzwerkeffekte der Hyperscaler fehlen.
Der AI Act, DORA (Digital Operational Resilience Act), NIS2 (Network and Information Security Directive) und andere europäische Vorschriften beginnen, diese Risiken anzugehen. Doch Regulierung allein reicht nicht. Wir brauchen echte Alternativen. Wir brauchen europäische Infrastruktur, die bei den Fähigkeiten mithalten kann und gleichzeitig Souveränität wahrt.
Der Weg nach vorn
Die "Local Zone" ist eine bequeme Illusion. Sie erlaubt uns, so zu tun, als hätten wir das Problem gelöst, ohne die harte Arbeit des Aufbaus echter Unabhängigkeit zu leisten. Doch Illusionen, so tröstlich sie auch sein mögen, zerplatzen irgendwann.
Der Weg nach vorn erfordert unbequeme Ehrlichkeit:
Für Unternehmen: Prüfen Sie Ihre Cloud-Abhängigkeiten mit Blick auf Souveränität. Wenden Sie den Internet-Pull-Test, den CLOUD-Act-Test und den Gerichtsbeschluss-Test auf Ihre Infrastruktur an. Identifizieren Sie kritische Workloads, die echte Souveränität erfordern, und entwickeln Sie Migrationspfade.
Für politische Entscheidungsträger: Gehen Sie über Anforderungen an den Datenstandort hinaus zu Anforderungen an die Datensouveränität. Erkennen Sie an, dass der physische Standort eine notwendige, aber nicht hinreichende Bedingung ist. Entwickeln Sie Zertifizierungsrahmen, die technische Autonomie, rechtliche Immunität und kryptografische Kontrolle testen.
Für die Technologiebranche: Bauen Sie echte Alternativen. Die Marktchance ist enorm und der strategische Bedarf ist dringend. Europäische digitale Souveränität erfordert europäische digitale Infrastruktur.
Es ist Zeit, Infrastruktur zu bauen, die echt ist. Infrastruktur, die auf eigenen Füßen steht. Infrastruktur, die wirklich, technisch und rechtlich souverän ist. Das ist die Mission von Dweve.
Unsere Plattform ist von Grund auf für echte Souveränität konzipiert. Europäische Rechenzentren in den Niederlanden, in Deutschland und in Frankreich. Keine ausländischen Kontrollebenen. Keine „Break Glass"-Hintertüren. Keine jurisdiktionelle Gefährdung. Volle DSGVO-Konformität von Anfang an eingebaut. Technische Autonomie, die den Internet-Pull-Test besteht. Kryptografische Architektur, die den Datenzugriff ohne Zustimmung der Kunden mathematisch unmöglich macht.
Hier geht es nicht um Nationalismus oder Protektionismus. Hier geht es um umsichtiges Risikomanagement in einer unsicheren Welt. Hier geht es um den Aufbau der digitalen Infrastruktur, die europäische Unternehmen und Bürger verdienen: Infrastruktur, die von Europäern kontrolliert wird, für Europäer, unter europäischem Recht.
Die Illusion der Local Zone hat ihren Zweck erfüllt: Sie ermöglichte es Unternehmen, schwierige Entscheidungen aufzuschieben, während sie den Anschein erweckten, sich mit Souveränitätsfragen zu befassen. Doch diese Aufschubphase endet. Die geopolitischen Spannungen nehmen zu. Die regulatorischen Anforderungen verschärfen sich. Die strategischen Risiken werden immer schwerer zu ignorieren.
Es ist an der Zeit, von der Illusion zur Realität überzugehen. Es ist an der Zeit, wirklich souveräne Infrastruktur aufzubauen.
Dweve baut wirklich souveräne KI-Infrastruktur für europäische Unternehmen. Unsere Architektur besteht alle drei Souveränitätstests: technische Autonomie (für den Betrieb ohne Verbindung geeignet), rechtliche Immunität (nur EU-Gerichtsbarkeit) und kryptografische Kontrolle (HYOK-Schlüsselverwaltung mit Post-Quantum-Bereitschaft). Unsere Mesh-Plattform bietet verteilte KI-Ausführung mit datenschutzfreundlichem föderiertem Lernen. Unser Fabric-Dashboard bietet vollständige Transparenz über KI-Abläufe. Keine „Break Glass"-Hintertüren. Keine ausländischen Kontrollebenen. Keine Illusionen. Echte Souveränität, von Grund auf entwickelt.