Digitale Souveränität in der Cloud: Warum „einfach zu einem europäischen Anbieter wechseln“ die falsche Vorstellung ist

Executive Summary

Europa hat ein Problem mit digitaler Souveränität. Aber es ist ein anderes Problem, als die verkürzte Diskussion über „amerikanische Cloud gegen europäische Cloud“ vermuten lässt.

Natürlich spielt es eine Rolle, wo Daten liegen. Es spielt auch eine Rolle, welchem Recht ein Anbieter unterliegt. Aber spätestens wenn man eine moderne Cloud-Anwendung auseinanderbaut, merkt man ziemlich schnell, dass ein Rechenzentrum in Frankfurt allein noch keine Souveränität erzeugt.

Da ist die eigentliche Anwendung.

Darunter Kubernetes oder virtuelle Maschinen.

Daneben Datenbanken, Object Storage, Messaging und Observability.

Dann kommen Identity, Secrets und Key Management.

Darunter Hypervisor, Betriebssysteme und Firmware.

Noch eine Etage tiefer CPUs, GPUs, Netzwerkkarten, Storage-Controller und Management-Chips.

Und vor diesem gesamten Stack stehen DNS, CDN, Zertifikate, Internet-Transit, Telekommunikationsanbieter und Unterseekabel.

Dazu kommen SaaS-Dienste, Security-Produkte, Developer-Plattformen und inzwischen zunehmend KI-Modelle, deren eigentliche Infrastruktur wiederum aus Cloud, Modellen, GPUs, Frameworks und proprietären APIs besteht.

Das Bild aus dem bereitgestellten Ausgangsmaterial, Europa wohne digital gewissermaßen „zur Miete“, trifft deshalb einen wichtigen Punkt. Die entscheidende Frage ist nicht nur, wo das Haus steht, sondern wem es gehört, wer einen Schlüssel besitzt, wer den Hausmeister stellt, welche Technik im Keller verbaut ist und ob man überhaupt noch ausziehen kann.

Und genau an diesem Punkt ist die politische Debatte inzwischen erheblich weiter, als man häufig denkt.

Die Europäische Kommission definiert technologische Souveränität ausdrücklich nicht als völlige Abschottung. Europa soll in der Lage sein, Schlüsseltechnologien, Daten und Infrastruktur selbst zu kontrollieren, kritische Abhängigkeiten zu reduzieren und trotzdem offen mit Partnern zusammenzuarbeiten. [1] [3]

Seit Juni 2026 verfolgt die EU diesen Gedanken mit einem zusammenhängenden Technology-Sovereignty-Paket. Cloud, KI, Halbleiter und Open Source werden nicht mehr als voneinander getrennte Politikfelder behandelt. Das Paket umfasst den vorgeschlagenen Cloud and AI Development Act, Chips Act 2.0, eine neue Open-Source-Strategie und weitere industriepolitische Maßnahmen. [2]

Das ist wichtig, weil damit politisch langsam genau das passiert, was technisch längst offensichtlich ist:

Digitale Souveränität ist eine Eigenschaft des gesamten Stacks und nicht des Standorts einer Festplatte.

Der Cloud and AI Development Act geht sogar noch weiter und schlägt vier unterschiedliche Souveränitätsstufen vor. Auf der ersten Ebene reicht Datenverarbeitung in der EU. Auf höheren Ebenen werden Unabhängigkeit von Drittstaaten, Software-Lieferketten, europäische Eigentums- und Kontrollstrukturen und schließlich vollständige Kontrolle über die Software Supply Chain sowie Schutz vor Drittstaateneinfluss relevant. [8]

Parallel zwingt der bereits geltende Data Act Cloudanbieter, Wechselbarrieren abzubauen. Er verlangt unter anderem offenere Schnittstellen und Datenexportmöglichkeiten. Ab dem 12. Januar 2027 sollen auch die eigentlichen Switching Charges einschließlich entsprechender Data-Egress-Gebühren wegfallen. [5]

DORA zwingt den Finanzsektor dazu, Abhängigkeiten von ICT-Drittanbietern, Konzentrationsrisiken und Exit-Szenarien systematisch zu betrachten. NIS2 behandelt Supply-Chain-Security und Business Continuity inzwischen als Teil der Cybersecurity. Die 2026 veröffentlichte EU ICT Supply Chain Security Toolbox empfiehlt sogar ausdrücklich Multi-Vendor-Strategien, die Bewertung kritischer Lieferanten und Maßnahmen gegen Abhängigkeiten von Hochrisikoanbietern. [6] [7] [13]

Das Joint Research Centre geht noch einen Schritt weiter. Es hat 2026 einen Digital Sovereignty Self-Assessment, einen Digital Sovereignty Canvas und ein eigenes Digital Sovereignty Metrics Framework entwickelt. Dabei werden Abhängigkeit, Kontrolle, Fähigkeiten, strategische Bedeutung und Resilienz über mehrere Ebenen hinweg bewertet. [14] [15] [16]

Wir reden also nicht mehr nur über politische Absichtserklärungen.

Es entstehen konkrete Messmodelle, Beschaffungslogiken, Vertragsregeln, Risikomodelle und Architekturkonzepte.

Und das halte ich für entscheidend.

Denn die sinnvollste Definition digitaler Souveränität lautet aus meiner Sicht nicht:

Wir brauchen keine Technologie mehr aus den USA oder China.

Das wäre weder realistisch noch sinnvoll.

Die bessere Definition lautet:

Wir müssen unsere Abhängigkeiten kennen, ihren möglichen Schaden begrenzen und im entscheidenden Moment noch eine Alternative besitzen.

Oder noch kürzer:

Souveränität ist die Fähigkeit, Nein sagen zu können.

Souveränität ist mehr als der Standort eines Rechenzentrums

Die einfache Gleichung lautet häufig:

europäischer Anbieter + Rechenzentrum in Europa = digitale Souveränität

Das ist ein Anfang.

Aber eben nur ein Anfang.

Denn selbst die EU verabschiedet sich zunehmend von dieser binären Betrachtung. Das Joint Research Centre beschreibt digitale Souveränität ausdrücklich als strategische Handlungsfähigkeit in einem weiterhin offenen und international vernetzten System. Vollständige Isolation ist nicht das Ziel. [3]

Das passt auch zu einer Erkenntnis, die im Cloud-Alltag ziemlich banal klingt und trotzdem häufig vergessen wird.

Jede IT erzeugt Abhängigkeiten.

Man kann AWS verlassen und anschließend von OpenStack abhängig sein.

Man kann Microsoft SQL Server gegen PostgreSQL austauschen und ist danach von PostgreSQL-Know-how abhängig.

Man kann VMware verlassen und Proxmox einsetzen.

Man kann Azure Key Vault verlassen und OpenBao plus HSM betreiben.

Die Abhängigkeit verschwindet nicht.

Sie verändert nur ihre Form.

Deshalb würde ich digitale Souveränität zunächst in sieben Kernschichten zerlegen.

Diese sieben Ebenen sind eng miteinander verbunden. Genau deshalb sollte man Souveränität nicht als einzelnes Zertifikat behandeln.

Control Plane gegen Data Plane

Das ist eine der wichtigsten Unterscheidungen überhaupt.

Das Data Plane ist dort, wo Workloads ausgeführt und Daten verarbeitet werden.

Die Control Plane entscheidet dagegen über Provisionierung, Konfiguration, Identitäten, Policies, Updates, APIs, Schlüssel, Telemetrie und teilweise administrative Eingriffe.

Ein Datenbankserver kann physisch in Frankfurt stehen.

Wenn allerdings seine Control Plane, zentrale Administratoren, Update-Infrastruktur oder Schlüsselverwaltung außerhalb Europas liegen, besteht weiterhin eine relevante operative Abhängigkeit.

Deshalb sollte eine souveräne Architektur immer fragen:

• Was passiert, wenn die externe Control Plane nicht erreichbar ist?
• Laufen bestehende Workloads weiter?
• Kann ich lokal administrieren?
• Kann ich Identitäten noch authentifizieren?
• Kann ich Schlüssel verwenden?
• Kann ich neue Ressourcen provisionieren?
• Kann ich Security Policies ändern?
• Kann ich Backups wiederherstellen?

Das ist eine wesentlich bessere Souveränitätsprüfung als die Postleitzahl des Rechenzentrums.

Identity ist möglicherweise der unterschätzteste Lock-in überhaupt

Viele Unternehmen diskutieren stundenlang darüber, ob ihre Kubernetes-Cluster portable sind.

Gleichzeitig hängen:

• Mitarbeiteridentitäten,
• Geräte,
• Single Sign-on,
• Conditional Access,
• MFA,
• Anwendungsrollen,
• B2B-Zugriffe,
• Machine Identities
• und privilegierte Accounts

vollständig an einem einzigen Identity Provider.

Dann kann der Kubernetes-Cluster theoretisch umziehen.

Die Organisation aber nicht.

Eine Architektur mit hoher Souveränität sollte deshalb Identity separat betrachten. Standards wie OIDC, OAuth 2.0 und SAML helfen. Systeme wie Keycloak können für bestimmte Einsatzfälle eine offene Alternative darstellen. Trotzdem ist auch der Identity-Wechsel ein komplexes Projekt.

Schlüsselhoheit ist wichtiger als Marketingbegriffe

Bei besonders sensiblen Workloads reicht es nicht zu fragen, ob Daten „verschlüsselt“ sind.

Die relevantere Frage lautet:

Wer kontrolliert den Schlüssel?

Provider Managed Keys sind etwas anderes als Customer Managed Keys.

Customer Managed Keys innerhalb derselben Providerplattform wiederum etwas anderes als extern kontrollierte Schlüssel.

Und externe Schlüssel sind noch einmal etwas anderes als ein eigenes HSM mit vollständig eigener Schlüsselhoheit.

Je kritischer ein System ist, desto interessanter werden Konzepte wie Bring Your Own Key, Hold Your Own Key oder External Key Management.

Dabei gilt allerdings auch hier:

Je mehr Kontrolle ich selbst übernehme, desto mehr Verantwortung übernehme ich.

Wer seine Schlüssel vollständig selbst kontrollieren möchte, sollte ziemlich genau wissen, wie Key Rotation, Recovery, HSM-Backup und Desaster Recovery funktionieren.

Sonst kann aus maximaler Souveränität erstaunlich schnell maximaler Datenverlust werden.

DNS, CDN und Zertifikate gehören ebenfalls zur Architektur

Man kann eine vollständig europäische Cloud betreiben und trotzdem kritische Dienste von wenigen globalen DNS-, CDN-, Domain- und Zertifikatsanbietern abhängig machen.

Fällt DNS aus, hilft einem der hervorragend redundante Kubernetes-Cluster nur begrenzt.

Kann ein Zertifikat nicht erneuert werden, wird es ebenfalls interessant.

Ist der Domain Registrar gesperrt oder kompromittiert, kann die komplette Anwendung praktisch verschwinden.

Und wenn sämtliche externen Anwendungen über denselben CDN- oder DDoS-Anbieter laufen, entsteht dort der nächste zentrale Kontrollpunkt.

Auch das Internet selbst besitzt Lieferketten

Das wird gern vergessen, weil „Cloud“ sich so virtuell anhört.

Cloud braucht Glasfaser.

Carrier.

Peering.

Internet Exchanges.

Unterseekabel.

Strom.

Wasser.

Kühlung.

Rechenzentren.

Im September 2025 warnte Microsoft beispielsweise vor erhöhten Azure-Latenzen, nachdem Unterseekabel im Roten Meer beschädigt worden waren und Verkehr umgeleitet werden musste. [31]

Ein souveränes Rechenzentrum ohne resiliente Netzwege ist deshalb ungefähr so sinnvoll wie ein hervorragend gesichertes Haus ohne Straße.

Das JRC betrachtet inzwischen sogar Energie und Materialverfügbarkeit ausdrücklich als Bestandteil digitaler Souveränität. Ohne ausreichende Energie- und Rohstoffinfrastruktur bleiben digitale Systeme strukturell verwundbar. [18]

Und dann gibt es noch SaaS

Das ist vielleicht der größte blinde Fleck der ganzen Cloud-Souveränitätsdebatte.

Wir beschäftigen uns mit AWS, Azure und Google Cloud.

Aber wo liegen:

• E-Mail,
• Dokumente,
• Videokonferenzen,
• CRM,
• HR,
• Ticketing,
• Quellcode,
• CI/CD,
• Security-Telemetrie,
• Passwörter,
• Geräteverwaltung
• und Unternehmensidentitäten?

Sehr häufig in SaaS-Plattformen.

Ein Kubernetes-Cluster ist unter Umständen leichter umzuziehen als zehn Jahre SharePoint, Teams, Exchange, Entra ID und Power Platform.

Dasselbe gilt für Salesforce, ServiceNow, GitHub, Atlassian und viele andere Plattformen.

Wer Souveränität wirklich bewerten möchte, braucht deshalb kein Cloud-Inventar.

Er braucht ein Dependency-Inventar.

Und Security-Software gehört ebenfalls hinein

Der CrowdStrike-Ausfall vom Juli 2024 hat ziemlich eindrucksvoll demonstriert, dass ausgerechnet ein Produkt, das Systeme schützen soll, selbst zu einem globalen Single Point of Failure werden kann. Ein fehlerhaftes Falcon-Update legte Windows-Systeme in Airlines, Banken, Krankenhäusern und Behörden lahm. Reuters verwies anschließend ausdrücklich auf die Risiken hoher Konzentration bei wenigen zentralen Technologieanbietern. [29]

Das bedeutet:

• EDR,
• SIEM,
• SOAR,
• IAM,
• PAM,
• Threat Intelligence,
• Vulnerability Management,
• DNS Security
• und Cloud Security

gehören genauso in eine Souveränitätsanalyse wie Compute und Storage.

Eine vereinfachte Darstellung des tatsächlichen Abhängigkeits-Stacks sieht deshalb eher so aus:

• Geschäftsprozess und Anwendung
• SaaS, AI und Managed Services
• Identity, KMS, Secrets, Security
• Kubernetes, VMs, Datenbanken, Storage
• Cloud Control Plane und Provider APIs
• OS, Hypervisor, Treiber, Firmware
• CPU, GPU, NIC, SSD, HSM
• Rechenzentrum, Energie, Kühlung, Wasser
• DNS, CDN, Zertifikate
• Carrier, Peering, Unterseekabel
• Jurisdiktion, Eigentum, Sanktionen, Exportkontrollen
• Menschen und Know-how
• Lieferketten

Und genau deshalb ist die unbequeme Frage:

Wie souverän ist eine europäische Cloud wirklich, wenn wesentliche Komponenten weiterhin außerhalb Europas entwickelt oder hergestellt werden?

Die ehrliche Antwort lautet:

Sie kann trotzdem sehr souverän sein. Nur eben nicht autark.

Die Cloud ist Teil der Anwendung geworden – und genau dort beginnt der Lock-in

Vor zwanzig Jahren war der Infrastrukturprovider oft erstaunlich austauschbar.

Linux-Server.

Apache.

Eine Datenbank.

Ein paar IP-Adressen.

DNS.

Vielleicht ein Loadbalancer.

Der Umzug war lästig.

Aber man zog im Wesentlichen Infrastruktur um.

Moderne Cloudarchitektur funktioniert anders.

AWS, Azure und Google Cloud verkaufen heute nicht primär virtuelle Maschinen.

Sie verkaufen Plattformen.

Managed Databases.

Serverless.

Messaging.

Eventing.

IAM.

KMS.

Secrets.

Data Warehouses.

Machine Learning.

AI.

Security.

Observability.

Developer Services.

Und das ist nicht schlecht.

Im Gegenteil.

Genau darin steckt ein großer Teil des Mehrwerts dieser Plattformen.

Ein Managed PostgreSQL-Service bedeutet, dass jemand anderes Hochverfügbarkeit, Patching, Backup, Monitoring und Teile des Lifecycle Managements übernimmt.

Ein Serverless-Dienst nimmt einem Infrastrukturarbeit ab.

Managed Kafka nimmt einem einen ganzen Stapel operativer Schmerzen ab.

Das Problem entsteht erst dann, wenn man diese Komfortentscheidung mit Portabilität verwechselt.

Die einfache Regel lautet

Je weiter oben im Stack ich eine proprietäre Funktion nutze, desto wahrscheinlicher wird aus einer Infrastrukturmigration ein Softwareprojekt.

Eine Linux-VM ist relativ portabel.

Ein Container ebenfalls.

Kubernetes grundsätzlich auch.

PostgreSQL ist gut portierbar.

Bei Managed Kafka wird es bereits interessanter.

Bei IAM sehr interessant.

Bei KMS ebenfalls.

Bei Serverless Functions, proprietären Eventsystemen und serverlosen Datenbanken kann ein Wechsel erhebliche Umbauten erfordern.

Und bei vollständig cloudnativen Daten- und AI-Plattformen kann das Wort „Migration“ irgendwann ziemlich euphemistisch werden.

Dann reden wir über Reengineering.

Der Data Act löst einen Teil des Problems – aber nicht die Architektur

Der seit 12. September 2025 geltende Data Act verpflichtet Anbieter von Datenverarbeitungsdiensten dazu, Wechselbarrieren abzubauen. PaaS- und SaaS-Anbieter sollen offene Interfaces bereitstellen und Daten zumindest in gebräuchlichen maschinenlesbaren Formaten exportierbar machen. Für IaaS geht es unter anderem darum, bei einem Wechsel funktional vergleichbare Ergebnisse für gemeinsame Funktionen zu ermöglichen. [5]

Ab dem 12. Januar 2027 entfallen außerdem die eigentlichen Switching Charges einschließlich der betreffenden Data-Egress-Gebühren. [5]

Das ist ein echter Fortschritt.

Aber der Data Act kann eines nicht.

Er kann Architektur nicht wegregulieren.

Eine AWS-Lambda-Funktion wird nicht automatisch zu Knative.

DynamoDB wird nicht automatisch PostgreSQL.

Azure Logic Apps werden nicht automatisch zu Temporal oder Camunda.

Google BigQuery wird nicht automatisch ClickHouse.

Und aus einer tief integrierten Entra-ID-Landschaft wird nicht per Gesetz Keycloak.

Die EU kann die Tür des Hauses öffnen.

Den Umzug müssen wir immer noch selbst organisieren.

Ein praktisches Portabilitätsmodell

Die folgende Tabelle ist bewusst keine Behauptung, dass die jeweilige Alternative funktional identisch ist. Gerade das wäre wieder zu einfach. Sie zeigt vielmehr, welche offenen oder breiter verfügbaren Technologien eine Portabilitätsschicht schaffen können.

OpenStack, Kubernetes, OpenTofu, PostgreSQL, Ceph, Keycloak und OpenBao sind deshalb nicht interessant, weil „Open Source gut und proprietär schlecht“ wäre. Sie sind interessant, weil sie unter bestimmten Voraussetzungen mehr Betreiberwahl ermöglichen. [45]– [51]

Aber auch hier gilt:

Open Source ist kein magischer Souveränitätsknopf.

Wer von RDS zu PostgreSQL auf eigener Infrastruktur wechselt, hat vielleicht seinen Plattform-Lock-in reduziert.

Dafür besitzt er jetzt eine PostgreSQL-Betriebsorganisation.

Wer eine kommerzielle Identity-Plattform gegen Keycloak ersetzt, gewinnt Kontrolle und gleichzeitig Verantwortung.

Und wer seine eigene Cloud auf OpenStack und Ceph baut, sollte Menschen beschäftigen, die OpenStack und Ceph tatsächlich beherrschen.

Souveränität ist nicht kostenlos.

Sie wird mit Geld, Personal, Komplexität und manchmal etwas weniger Komfort bezahlt.

Das ist keine Kritik.

Es ist der Preis einer Option.

Ein konkretes Migrationsbeispiel

Nehmen wir eine typische Anwendung auf AWS.

• EKS.
• RDS PostgreSQL.
• S3.
• ElastiCache.
• MSK.
• Secrets Manager.
• KMS.
• CloudWatch.
• Application Load Balancer.
• Route 53.

Die Applikation selbst läuft überwiegend in Containern.

Auf der PowerPoint-Folie könnte der Umzug zu einem europäischen Provider so aussehen:

• EKS wird Managed Kubernetes.
• RDS wird Managed PostgreSQL.
• S3 wird S3-kompatibler Storage.
• Redis wird Valkey.
• MSK wird Kafka.
• CloudWatch wird OpenTelemetry, Prometheus und Grafana.
• Secrets Manager wird OpenBao.
• Terraform wird OpenTofu.

Fertig.

In der Realität beginnt jetzt die eigentliche Arbeit.

• Welche Kubernetes-Versionen werden unterstützt?
• Welche CSI-Treiber?
• Welche Storage Classes?
• Welche PostgreSQL-Extensions?
• Welche Backupmechanismen?
• Wie groß ist die Datenbank?
• Wie lange darf die Replikationsunterbrechung dauern?
• Welche S3-Funktionen nutzt die Anwendung wirklich?
• Sind Object Locks im Einsatz?
• Wie werden verschlüsselte Daten aus KMS migriert?
• Wie funktionieren Pod Identities?
• Wie werden Service Accounts aufgelöst?
• Welche Kafka-Semantik nutzt die Anwendung?
• Wie sieht die Netzwerktopologie aus?
• Welche IP-Allow-Lists existieren?
• Wie werden Zertifikate ausgestellt?
• Welche DNS-TTLs?
• Welche Security Groups müssen übersetzt werden?
• Wo liegen Auditlogs?
• Welche SIEM-Regeln hängen an den bisherigen Events?

Und irgendwann entsteht aus dem schönen Pfeil zwischen zwei Wolken ein Projektplan.

Genau so sollte es sein.

Das Problem ist nicht, dass Migration schwierig ist.

Das Problem entsteht, wenn eine Organisation jahrelang behauptet, sie könne jederzeit wechseln, ohne es jemals ausprobiert zu haben.

Ein Exit-Plan, der noch nie getestet wurde, ist kein Exit-Plan.
Er ist eine Hoffnung.

Europas Antwort ist inzwischen erstaunlich konkret

Bei all der berechtigten Kritik an Europas langsamer Digitalpolitik sollte man an dieser Stelle fair bleiben.

Die EU beschäftigt sich inzwischen ziemlich systematisch mit genau diesen Problemen.

Nicht alles ist fertig.

Nicht alles ist Gesetz.

Und nicht jeder Ansatz wird am Ende funktionieren.

Aber die Vorstellung, Europa diskutiere über digitale Souveränität lediglich in Strategiepapieren, stimmt so nicht mehr.

Stand 16. Oktober 2026 ergibt sich ungefähr folgendes Bild.

Der Data Act macht Exit zu einem regulatorischen Thema

Der Data Act ist vielleicht das unmittelbar praktischste Instrument.

Er gilt seit dem 12. September 2025.

Bei Cloud-Services verlangt die EU unter anderem transparentere Verträge, Wechselmöglichkeiten und die Beseitigung technischer beziehungsweise vertraglicher Hindernisse.

PaaS- und SaaS-Anbieter müssen offene Interfaces und Datenexport in gebräuchlichen maschinenlesbaren Formaten unterstützen. IaaS-Anbieter müssen funktionale Portabilität gemeinsamer Funktionen erleichtern. [5]

Ab 12. Januar 2027 entfallen die entsprechenden Switching Charges einschließlich einschlägiger Data-Egress-Gebühren. [5]

Interessant ist auch, was inzwischen um das Gesetz herum entsteht.

Die Kommission hat FAQs veröffentlicht, arbeitet mit Stakeholdern an der Umsetzung, hat einen Data Act Legal Helpdesk aufgebaut und Musterbedingungen beziehungsweise Standardvertragsklauseln für Cloudverträge vorbereitet. [5]

Das ist wichtig.

Denn Portabilität entscheidet sich nicht nur in Kubernetes.
Sie entscheidet sich im Vertrag.

DORA macht aus Providerabhängigkeit ein Resilienzproblem

DORA gilt seit dem 17. Januar 2025 für den Finanzsektor.

Das Regelwerk behandelt ICT-Drittanbieter nicht einfach als Lieferanten. Abhängigkeit, Konzentration und die Möglichkeit eines Ausfalls werden Teil des operationellen Risikomanagements. [6]

Besonders interessant für die Souveränitätsdiskussion sind die Anforderungen an Exit-Strategien für ICT-Dienste, die kritische oder wichtige Funktionen unterstützen.

Solche Exit-Pläne sollen dokumentiert, ausreichend getestet und regelmäßig überprüft werden. Der Wechsel soll erfolgen können, ohne Geschäftsabläufe unvertretbar zu stören oder regulatorische Pflichten zu verletzen. [6]

Eigentlich ist das genau die richtige Denkrichtung.

Nicht:

„Unser Provider besitzt ISO-Zertifikat X, also sind wir fertig.“

Sondern:

„Was machen wir, wenn wir ihn verlassen müssen?“

DORA adressiert außerdem Konzentrationsrisiken. Das ist ein Punkt, den die allgemeine Souveränitätsdebatte meiner Meinung nach noch stärker übernehmen sollte.

Denn es hilft Europa wenig, wenn wir eine amerikanische Monokultur durch eine europäische Monokultur ersetzen.

NIS2 bringt Lieferkette und Business Continuity zusammen

NIS2 erweitert die Cybersecurity-Pflichten für eine große Zahl kritischer und wichtiger Sektoren. Supply-Chain-Security, Business Continuity, Access Control, Kryptografie und sichere Beschaffung gehören zum Risikomanagement. [7]

Der Umsetzungsstand zeigt gleichzeitig, wie kompliziert europäische Regulierung ist. Die Umsetzungsfrist war der 17. Oktober 2024. Noch im Mai 2025 hatte die Kommission 19 Mitgliedstaaten wegen unvollständiger Umsetzung gerügt. Bis Juli 2026 hatte sich die Lage deutlich verbessert. Zu diesem Zeitpunkt verwies die Kommission noch Irland, Spanien, Frankreich und die Niederlande an den EuGH. [52]

Man sollte diese Unterscheidung sauber halten:

Eine Richtlinie kann europäisch beschlossen sein.
Ihre praktische Wirkung hängt trotzdem von nationaler Umsetzung und Aufsicht ab.

Der Cloud and AI Development Act ist vielleicht der spannendste neue Baustein

Der CADA-Vorschlag vom Juni 2026 geht deutlich über Datenschutz hinaus.

Die Kommission will die europäische Rechenzentrums- und Compute-Kapazität innerhalb von fünf bis sieben Jahren mindestens verdreifachen, Genehmigungen vereinfachen und Zugang zu Energie, Land, Wasser und Finanzierung verbessern. [8]

Gleichzeitig soll ein EU-weiter Souveränitätsrahmen entstehen.

Und das ist der interessante Teil.

Vier Assurance Levels sind vorgesehen. [8]

Level 1 verlangt Verarbeitung und Speicherung in EU-Infrastruktur.

Level 2 verlangt zusätzlich Unabhängigkeit von Drittstaaten sowie Transparenz der Software-Lieferkette.

Level 3 fordert unter anderem EU-Eigentum und EU-Kontrolle sowie zusätzliche Anforderungen an Personal und Governance, wobei bestimmte Drittstaatenanbieter anerkannt werden können.

Level 4 verlangt vollständige Transparenz und Kontrolle über die Software Supply Chain und Schutz vor Einwirkung aus Drittstaaten.

Das ist aus meiner Sicht eine ausgesprochen wichtige Entwicklung.

Souveränität ist graduell.

Ein Workload braucht vielleicht Level 1.

Ein anderer Level 2.

Ein nationales Sicherheits- oder Verteidigungssystem vielleicht Level 4.

Damit lässt sich Souveränität endlich risikobasiert statt religiös diskutieren.

CADA soll außerdem einen gemeinsamen Beschaffungsrahmen für öffentliche Verwaltungen schaffen und deren gemeinsame Marktmacht nutzen. Open Source soll dabei ausdrücklich gefördert werden. [8]

Wichtig ist der aktuelle Status.

CADA ist noch kein geltendes Gesetz.

Der Kommissionsvorschlag wird im Gesetzgebungsverfahren behandelt. Noch am 29. September 2026 stand er in der zuständigen Arbeitsgruppe des Rates auf der Agenda. [9]

Es wäre deshalb falsch, heute so zu schreiben, als seien die vier Level bereits verbindliches Recht.

Aber als politische Richtung sind sie ausgesprochen relevant.

Chips Act 2.0 erweitert Souveränität unterhalb der Cloud

Der erste Chips Act war bereits ein Versuch, Europas Halbleiterkapazitäten zu stärken.

Mit Chips Act 2.0 zieht die Kommission daraus weitere Konsequenzen und verbindet Halbleiterpolitik explizit mit dem neuen Technologiesouveränitätspaket. [2] [10]

Hier zeigt sich, dass die Diskussion inzwischen wirklich beim gesamten Stack angekommen ist.

Denn eine souveräne Cloud braucht weiterhin:

• CPUs.
• GPUs.
• Memory.
• Netzwerkchips.
• Storage Controller.
• Packaging.
• Foundries.
• Lithografie.
• Firmware.
• Treiber.

Und genau dort sind die globalen Abhängigkeiten besonders tief.

Auch Chips Act 2.0 ist Stand Oktober 2026 noch im Gesetzgebungsverfahren. Im Rat wurde Ende September bereits ein Präsidentschafts-Kompromisstext behandelt; die zuständige Arbeitsgruppe diskutierte den Vorschlag am 12. und 13. Oktober weiter, ein weiteres Treffen war für den 19. Oktober vorgesehen. [11]

Das ist ziemlich aktueller Maschinenraum europäischer Industriepolitik.

Open Source wird erstmals viel stärker als Industriepolitik verstanden

Die im Juni 2026 vorgestellte EU Open Source Strategy ist interessant, weil Open Source dort nicht primär als Kostenfrage auftaucht.

Die Strategie ist Bestandteil des Technologiesouveränitätspakets und soll Abhängigkeiten über den gesamten Technologie-Stack reduzieren. [2] [12]

Das halte ich für die richtige Perspektive.

Open Source ist nicht automatisch sicher.

Nicht automatisch europäisch.

Nicht automatisch günstig.

Aber Open Source besitzt häufig eine Eigenschaft, die proprietäre Plattformen nicht haben:

Es kann einen Anbieter überleben.

Wenn ein Unternehmen verschwindet, kann theoretisch ein anderes den Betrieb übernehmen.

Wenn ein kommerzieller Betreiber seine Strategie ändert, existiert weiterhin Code.

Wenn eine Plattform forkbar ist, gibt es zumindest eine technische Eskalationsstufe.

Das ist keine Garantie.

Aber es ist eine Option.

Und Optionen sind der Kern von Souveränität.

Die ICT Supply Chain Security Toolbox zeigt, dass es auch um politische Lieferkettenrisiken geht

Im Februar 2026 veröffentlichte die NIS Cooperation Group gemeinsam mit Kommission und ENISA die EU ICT Supply Chain Security Toolbox. [13]

Sie ist nicht bindend.

Das sollte man dazu sagen.

Aber sie ist politisch interessant, weil sie explizit einen All-Hazards-Ansatz verfolgt.

Dazu gehören:

• Bewertung kritischer Lieferanten,
• Multi-Vendor-Strategien,
• Reduzierung von Abhängigkeiten von Hochrisikoanbietern
• und nichttechnische Risiken wie ausländische Einflussnahme.

Die Toolbox ist ausdrücklich anbieterneutral formuliert und soll nach einem Jahr überprüft werden. [13]

Das ist genau die Diskussion, die man bei Firmware, Netzwerkgeräten, HSMs, Cloud-Control-Planes und AI-Infrastruktur braucht.

Das JRC versucht sogar, Souveränität messbar zu machen

Besonders interessant finde ich die Arbeit des Joint Research Centre.

Der Digital Sovereignty Self-assessment Tool soll Organisationen dabei helfen, kritische digitale Assets und konkrete Abhängigkeiten zu identifizieren. Dabei nennt das JRC explizit Risiken wie wirtschaftliche Verluste, fehlende Governance-Rechte und Vendor Lock-in. [14]

Danach folgt der Digital Sovereignty Canvas.

Der Canvas zwingt eine Organisation dazu, nicht nur Risiken, sondern auch den Preis größerer Unabhängigkeit zu betrachten.

Was kostet uns die heutige Abhängigkeit?

Welchen Wert schafft mehr Souveränität?

Welche Ressourcen benötigen wir dafür?

Welche Veränderungen sind realistisch?

[15]

Das gefällt mir ausgesprochen gut.

Denn genau diese ökonomische Seite fehlt häufig.

Souveränität für jeden Workload um jeden Preis wäre Unsinn.

Das Digital Sovereignty Metrics Framework betrachtet wiederum vier große Bereiche:

• digitale Governance,
• Daten, Software und Infrastruktur,
• digitale Produkte und Märkte
• sowie Menschen und digitale Fähigkeiten.

Gemessen werden unter anderem Abhängigkeit, strategische Unentbehrlichkeit, Kontrolle, Capability und Resilienz. [16]

Und genau daraus lässt sich etwas Entscheidendes lernen:

Ein einziger „Sovereignty Score“ kann die Realität eigentlich gar nicht vollständig abbilden.
Man braucht ein Profil.

Das JRC untersucht darüber hinaus digitale Souveränität in der öffentlichen Verwaltung. Ein 2026 veröffentlichtes Policy Brief betont besonders die Rolle öffentlicher Beschaffung. Behörden können ihre Marktmacht nutzen, um Märkte zu diversifizieren und eine zu starke Abhängigkeit von einzelnen Lieferanten zu reduzieren. [17]

Am 16. November 2026 soll außerdem ein JRC Science for Policy Forum weitere Forschungsergebnisse des Jahres 2026 zusammenführen. Themen sind unter anderem Infrastruktur, Open Source, AI, Daten und industrielle Souveränität. [54]

Das zeigt:

Die Arbeit ist keineswegs abgeschlossen.

Aber sie ist inzwischen ziemlich ausgereift.

Was reale Fälle über Souveränität erzählen

Politikpapiere sind wichtig.

Noch interessanter wird es, wenn man sieht, was in der realen Welt passiert.

Denn fast jede Ebene der beschriebenen Souveränität lässt sich inzwischen an einem konkreten Fall erklären.

Der ICC-Fall ist wahrscheinlich das stärkste politische Beispiel

2025 sanktionierten die USA den Chefankläger des Internationalen Strafgerichtshofs Karim Khan.

Associated Press berichtete anschließend, dass sein offizielles ICC-E-Mail-Konto nicht mehr verfügbar war und Microsoft den Dienst beendet hatte. Auch Bankkonten und andere Dienste waren betroffen. [23]

Microsoft stellte später klar, dass der ICC als Organisation nicht von Microsoft-Diensten abgeschaltet worden sei. Der konkrete sanktionierte Nutzer war davon jedoch betroffen. [25]

Diese Differenzierung ist wichtig.

Der Fall beweist nicht:

„Microsoft kann jederzeit nach Lust und Laune Europa abschalten.“

Das wäre Unsinn.

Er beweist etwas anderes:

Ein Anbieter muss sich an das Recht seiner Jurisdiktion halten – auch dann, wenn die Auswirkungen in einem anderen Land auftreten.

Im Oktober 2026 wurde das Szenario noch deutlicher.

Die USA verhängten weitreichendere Sanktionen gegen den ICC als Institution. Reuters berichtete, dass die Maßnahmen darauf abzielen, den Zugang zu Finanzdienstleistungen und kommerzieller Unterstützung einzuschränken. Gleichzeitig wurden Übergangs- und Ausnahmeregelungen vorgesehen, unter anderem für bestimmte Telekommunikations- und Softwaretransaktionen. [24]

Interessant ist auch, dass Reuters berichtete, der ICC habe sich bereits auf diese Möglichkeit vorbereitet und Computer von Microsoft-Software auf Open-Source-Alternativen umgestellt. [24]

Genau so sollte man das Beispiel lesen.

Nicht als Microsoft-Bashing.

Sondern als Illustration von Jurisdiktionsrisiko.

Der CLOUD Act ist nur ein Teil der amerikanischen Dimension

Der CLOUD Act stellt unter anderem klar, dass Unternehmen unter US-Jurisdiktion unter bestimmten rechtlichen Voraussetzungen Daten herausgeben müssen, die sich in ihrem Besitz, Gewahrsam oder ihrer Kontrolle befinden, auch wenn die Daten physisch außerhalb der USA gespeichert sind. [19]

Das bedeutet ausdrücklich nicht, dass US-Behörden freien Zugriff auf beliebige europäische Cloudserver besitzen.

Aber es bedeutet, dass:

Datenstandort und Jurisdiktion zwei unterschiedliche Dinge sind.

2025 wurde genau dieses Problem auch in Frankreich öffentlich sichtbar. Im Zusammenhang mit dem französischen Health Data Hub erklärte ein Microsoft-Verantwortlicher vor dem französischen Senat, er könne nicht garantieren, dass Microsoft einer gültigen US-Anordnung hinsichtlich französischer Daten nicht folgen müsse, auch wenn diese in Frankreich gespeichert seien. Reuters griff diesen Punkt 2026 bei der Berichterstattung über den Providerwechsel auf. [27]

Frankreich zieht den Health Data Hub tatsächlich um

Der französische Health Data Hub war seit Jahren wegen der Nutzung von Microsoft Azure umstritten.

Im April 2026 wurde Scaleway als neue Plattform ausgewählt.

Reuters zufolge betrifft die Plattform Gesundheitsdaten von mehreren zehn Millionen Menschen. Die neue Umgebung soll Ende 2026 bis Anfang 2027 produktiv werden. Scaleway musste mehr als 350 technische Kriterien erfüllen. [27]

Das Beispiel ist deshalb so wertvoll, weil es beide Seiten der Debatte zeigt.

Ja, ein Exit ist möglich.

Nein, er passiert nicht über Nacht.

2019 wurde Azure ausgewählt.

Jahre später entstand der politische und regulatorische Druck.

Dann mussten Alternativen entstehen.

Zertifizierungs- und Beschaffungsanforderungen mussten definiert werden.

Dann kam die Migration.

Genau deshalb ist ein Exit-Plan etwas anderes als eine Export-Schaltfläche.

Airbus macht daraus Industriepolitik

Noch interessanter ist Airbus.

Im Juli 2026 kündigte Airbus eine mehrjährige Partnerschaft mit Scaleway für sensible Industrie- und Verteidigungsanwendungen an.

Reuters zufolge wurden mehr als 150 technische und juristische Kriterien geprüft. Airbus nannte dabei ausdrücklich den Schutz gegen extraterritoriales Recht und sogenannte Kill-Switch-Risiken. Rund 70 kritische Anwendungen sollen bis Ende 2028 migriert werden; perspektivisch könnte das Programm bis zu 900 Anwendungen umfassen. [36]

Das ist aus meiner Sicht ein Paradebeispiel dafür, wie man das Thema richtig behandelt.

Nicht:

„Alle Anwendungen müssen sofort aus AWS raus.“

Sondern:

• Welche Anwendungen sind strategisch?
• Welche Daten sind besonders sensibel?
• Welche rechtlichen Abhängigkeiten sind akzeptabel?
• Welche nicht?
• Wo lohnt der hohe Preis einer Migration?

Das ist risikobasierte Souveränität.

AWS baut inzwischen selbst eine European Sovereign Cloud

Im Januar 2026 startete AWS seine European Sovereign Cloud.

Die erste Region wird in Brandenburg aufgebaut.

AWS investiert dafür mehr als 7,8 Milliarden Euro. Die Umgebung soll über eine deutsche Gesellschaft betrieben werden und stärker organisatorisch und technisch von den globalen AWS-Strukturen getrennt sein. Reuters zitierte AWS sogar mit der Aussage, die Plattform solle so ausgelegt sein, dass sie auch bei einer Trennung Europas vom globalen Netz oder bei US-Softwareexportbeschränkungen weiterbetrieben werden könne. [26]

Das ist bemerkenswert.

Nicht weil damit jede Souveränitätsfrage gelöst wäre.

Die Technologie bleibt AWS.

Die APIs bleiben AWS.

Die Softwareentwicklung bleibt eng mit AWS verbunden.

Das Service-Modell bleibt AWS.

Aber operative und juristische Abhängigkeiten können reduziert werden.

Man kann das als Marketing abtun.

Oder man zieht eine interessantere Schlussfolgerung:

Wenn AWS selbst geopolitische Betriebsfähigkeit als Produkteigenschaft anbietet, ist die zugrunde liegende Fragestellung offenbar real genug, um Milliarden zu investieren.

Und dann kam Anthropic

Der vielleicht klarste Beleg dafür, dass Exportkontrollen nicht nur Chips betreffen können, kam im Juni 2026.

Die US-Regierung verhängte Exportbeschränkungen gegen Anthropics damals fortschrittlichste Modelle Fable 5 und Mythos 5 und verlangte, dass ausländische Staatsangehörige keinen Zugriff erhalten.

Anthropic erklärte, dass eine Echtzeitprüfung der Staatsangehörigkeit technisch nicht zuverlässig möglich sei und deaktivierte deshalb vorübergehend den Zugang für sämtliche Nutzer. [32]

Ende Juni wurden die Beschränkungen wieder aufgehoben und die Modelle anschließend erneut bereitgestellt. [32]

Man kann also sogar sagen:

Das Problem war temporär.

Gerade deshalb ist der Fall so interessant.

Denn er zeigt, dass aus einem geopolitischen Beschluss innerhalb kürzester Zeit eine API-Verfügbarkeit werden kann.

Für irgendeinen Chatbot ist das vielleicht ärgerlich.

Für eine unternehmenskritische AI-Plattform sieht die Bewertung möglicherweise anders aus.

Mistral und Microsoft zeigen wiederum, dass Souveränität nicht zwingend Trennung bedeutet

Im Juli 2026 kündigten Microsoft und Mistral eine milliardenschwere Zusammenarbeit an.

Microsoft unterstützt den Ausbau von Mistrals europäischer Compute-Infrastruktur. Gleichzeitig werden Mistral-Modelle tiefer in Microsoft Foundry, Copilot Studio und andere Microsoft-Plattformen integriert. Kunden sollen teilweise Mistral-Rechenkapazitäten in Frankreich über Microsoft nutzen können. [33]

Das ist eigentlich ein perfektes Beispiel für die ganze Diskussion.

Europäisches Unternehmen.

Europäische Rechenkapazität.

Amerikanische Vertriebskanäle.

Amerikanische Cloudtechnologie.

NVIDIA als wichtiger Hardwarelieferant.

Offene Modelle in Teilen.

Proprietäre Modelle und Services in anderen.

Ist das souverän?

Teilweise.

Und genau das ist die richtige Antwort.

Deutschland wiederum baut souveräne AI mit NVIDIA

Am 15. Oktober 2026 berichtete Reuters über eine geplante weitreichende Kooperation Deutschlands mit NVIDIA.

Sie soll unter anderem mit dem SOOFI-Projekt – Sovereign Open Source Foundation Models – zusammenhängen und leistungsfähige industrielle KI-Modelle sowie Physical-AI-Anwendungen unterstützen. Das erwartete Investitionsvolumen liegt im dreistelligen Millionenbereich. [34]

Das klingt zunächst paradox.

Sovereign Open Source Foundation Models.

Auf amerikanischen GPUs.

Aber eigentlich ist genau das die Realität.

Souveränität bedeutet nicht zwangsläufig, dass jede Schicht aus Europa kommt.

Vielleicht kontrollieren wir:

• Modell,
• Daten,
• Deployment,
• Anwendungslogik
• und Betrieb.

Die GPU kommt trotzdem von NVIDIA.

Das ist eine Abhängigkeit.

Aber eine andere als eine vollständig extern kontrollierte AI-API.

Scaleway versucht immerhin, die GPU-Abhängigkeit zu diversifizieren

Am 13. Oktober 2026 kündigte Scaleway einen AI-Supercomputer in Schweden auf Basis von AMD Instinct MI355X an.

Reuters hob besonders AMDs Open-Source-ROCm-Ökosystem als Alternative zum proprietären CUDA-Ökosystem von NVIDIA hervor. [35]

Interessanterweise kündigte Scaleway am selben Tag auch einen neuen Standort in Kopenhagen mit NVIDIA-Hardware an. [35]

Auch das ist fast schon lehrbuchhaft.

Souveränität bedeutet nicht:

NVIDIA verbieten.

Sondern:

mehr als eine Option besitzen.

CrowdStrike zeigt wiederum, dass Geopolitik gar nicht notwendig ist

Am 19. Juli 2024 legte ein fehlerhaftes CrowdStrike-Update weltweit Windows-Systeme lahm.

Airlines.

Banken.

Krankenhäuser.

Behörden.

Medien.

Der Vorfall war kein Cyberangriff. Ursache war ein fehlerhaftes Softwareupdate. [29]

Gerade deshalb ist er wichtig.

Denn ein Anbieter kann:

• vertrauenswürdig,
• westlich,
• technologisch hervorragend,
• rechtlich unproblematisch
• und sicherheitsorientiert

sein.

Und trotzdem einen Fehler machen.

Die relevante Souveränitätsfrage lautet dann:

Wie groß ist der Blast Radius?

Google erinnert uns ebenfalls daran

Am 4. September 2025 kam es zu Ausfällen verschiedener Google-Dienste in der Türkei und Teilen Europas, darunter auch Deutschland, Griechenland, Bulgarien, Serbien und Rumänien. [30]

Das war kein geopolitischer Vorgang.

Aber es verdeutlicht dasselbe Konzentrationsproblem.

Je zentraler ein Dienst wird, desto größer wird der gesellschaftliche Impact eines Fehlers.

Bei China müssen wir sauber unterscheiden

Wenn wir politische Abhängigkeiten diskutieren, dürfen wir China nicht auslassen.

Aber genauso wenig sollten wir die USA und China einfach gleichsetzen.

Das politische und rechtliche Modell Chinas unterscheidet sich fundamental von europäischen und US-amerikanischen Demokratien. Gesetze wie das chinesische Data Security Law und Foreign Relations Law binden Daten, Unternehmen und Organisationen stark an nationale Sicherheits- und Staatsinteressen. [20] [21]

Aus dieser Feststellung folgt allerdings ausdrücklich nicht:

„Chinesische Hardware bedeutet chinesische Spionage.“

Das wäre keine Risikoanalyse.

Es wäre ein Herkunftsetikett.

Was sich dagegen eindeutig dokumentieren lässt, sind staatlich zugerechnete Cyberoperationen.

Die gemeinsame CISA-Warnung aus dem Jahr 2025 beschreibt chinesische staatliche Akteure, die weltweit Telekommunikations-, Regierungs-, Transport- und militärische Netze kompromittiert haben. Die Kampagnen überschneiden sich mit dem in der Sicherheitsindustrie unter anderem als Salt Typhoon bezeichneten Aktivitätenkomplex. Die Angreifer zielten insbesondere auf Backbone- und Edge-Router und versuchten langfristige persistente Zugriffe aufzubauen. [22]

Das ist keine Hypothese.

Das ist ein dokumentiertes Cybersecurity-Risiko.

Daraus folgt aber trotzdem nicht, dass jedes chinesische Produkt kompromittiert ist.

Die richtige Schlussfolgerung lautet:

Bei kritischen Komponenten gehören Jurisdiktion, staatliche Einflussmöglichkeiten, Firmware, Updatekanäle, Lieferketten und Betreiberrechte in die Risikoanalyse.

Und genau dieselbe Logik sollte übrigens auch für amerikanische und europäische Anbieter gelten.

Nur die Risiken unterscheiden sich.

Europäische Anbieter und Open Source sind real – aber sie lösen nicht jedes Problem

Eine der seltsamsten Erzählungen in der Clouddebatte lautet immer noch:

Europa habe praktisch keine Cloudanbieter.

Das stimmt nicht.

Europa hat durchaus eine relevante Providerlandschaft.

Was Europa nicht hat, ist ein einzelnes Unternehmen mit derselben globalen Plattformbreite, Kapitalkraft und Servicevielfalt wie AWS, Microsoft oder Google.

Das ist ein Unterschied.

In Deutschland sind unter anderem STACKIT, IONOS, Open Telekom Cloud, plusserver, Hetzner und weitere Anbieter relevant.

Europaweit kommen OVHcloud, Scaleway, UpCloud, Exoscale, Infomaniak, Aruba Cloud, Cleura und andere hinzu.

Wichtig ist nur, diese Unternehmen nicht künstlich gleichzumachen.

Ein Provider mit starkem IaaS-Fokus ist etwas anderes als ein Anbieter mit tiefem PaaS- und AI-Portfolio.

Vergleich ausgewählter deutscher und europäischer Anbieter

Die folgende Matrix ist keine Zertifizierung und kein Ranking. „Lock-in“ und „Supply-Chain-Exposure“ sind analytische Einschätzungen, die stark vom konkret genutzten Service abhängen.

STACKIT beschreibt seine Kubernetes-Plattform als Managed Kubernetes und bietet inzwischen auch GPU-Unterstützung sowie S3-kompatiblen Object Storage und AI-Dienste an. [37]

IONOS bietet Managed Kubernetes, Datenbankdienste und weitere Cloudservices aus deutscher Jurisdiktion an. [38]

Die Open Telekom Cloud positioniert sich stark über OpenStack und offene Cloudarchitektur und bietet Kubernetes sowie GPU-basierte Ressourcen an. [39]

Hetzner verfolgt dagegen bewusst einen stärker IaaS- und Bare-Metal-orientierten Ansatz und bietet unter anderem S3-kompatiblen Object Storage und dedizierte GPU-Server an. [40]

pluscloud open setzt stark auf OpenStack und den Sovereign Cloud Stack und kombiniert dies mit Managed Kubernetes. [41]

OVHcloud betreibt eine große OpenStack-basierte Public Cloud und Managed Kubernetes; bestimmte französische Angebote sind inzwischen auch nach SecNumCloud qualifiziert. [42]

Scaleway bietet inzwischen ein vergleichsweise breites Managed- und AI-Portfolio mit Kubernetes und verschiedenen GPU-Plattformen. [43]

UpCloud beschreibt sich als europäisch geführten finnischen Anbieter und bietet Managed Kubernetes, Datenbanken und S3-kompatiblen Storage. [44]

Was diese Tabelle ausdrücklich nicht sagt

Sie sagt nicht:

STACKIT ist „souverän“ und AWS nicht.

Sie sagt auch nicht:

Hetzner ist besser als Azure.

Oder:

OpenStack ist grundsätzlich besser als proprietäre Cloud.

Die richtige Frage lautet immer:

Welchen Workload versuche ich zu betreiben?

Wer nur:

• Compute,
• Kubernetes,
• PostgreSQL,
• Object Storage,
• DNS,
• Loadbalancer
• und Monitoring

braucht, hat heute in Europa ziemlich viele Optionen.

Wer dagegen seine gesamte Plattform auf:

• DynamoDB,
• Lambda,
• Step Functions,
• Bedrock,
• EventBridge,
• Cognito,
• proprietäres KMS,
• CloudWatch-spezifische APIs
• und weitere AWS-Dienste

aufgebaut hat, besitzt naturgemäß weniger Optionen.

Das liegt nicht ausschließlich daran, dass europäische Provider „zu wenig können“.

Es liegt auch daran, dass die Anwendung selbst AWS geworden ist.

Genau hier wird Open Source strategisch

Ein möglicher offener Stack könnte beispielsweise so aussehen:

• Linux
• → OpenStack oder Proxmox
• → Kubernetes
• → Ceph
• → PostgreSQL
• → Valkey
• → Kafka/RabbitMQ
• → Keycloak
• → OpenBao
• → Harbor
• → OpenTofu
• → Argo CD
• → OpenTelemetry
• → Prometheus/Grafana/Loki.

Das ist kein AWS-Klon.

Und genau das ist vielleicht der Punkt.

Europa muss nicht zwangsläufig 250 proprietäre Cloud-APIs nachbauen.

Vielleicht ist eine andere Strategie interessanter:

Eine leistungsfähige Plattform anbieten, in die ein Kunde hinein – und wieder heraus – kommt.

Das wäre tatsächlich ein Differenzierungsmerkmal.

Aber Open Source ist nicht automatisch europäisch

Linux wird weltweit entwickelt.

Kubernetes ebenfalls.

PostgreSQL ist ein internationales Projekt.

OpenStack.

Ceph.

Keycloak.

OpenTofu.

Alle diese Ökosysteme sind global.

Das ist kein Nachteil.

Es zeigt nur noch einmal:

Souveränität ist nicht dasselbe wie Herkunft.

Der wichtige Unterschied liegt häufig in den Governance-Rechten.

Kann ich Code einsehen?

Kann ich ihn weiterverwenden?

Kann ich einen anderen Betreiber beauftragen?

Existiert ein Standard?

Kann ich Daten exportieren?

Kann ich die Anwendung selbst betreiben?

Das ist eine wesentlich bessere Frage als:

„Wo wurde diese Zeile Code geschrieben?“

Und darunter bleibt das amerikanische oder asiatische Innenleben

Selbst eine OpenStack-Cloud in Deutschland läuft möglicherweise auf:

• AMD EPYC oder Intel Xeon,
• NVIDIA- oder AMD-GPUs,
• Broadcom-Netzwerkkomponenten,
• internationalen SSDs,
• BMCs,
• UEFI,
• Firmware
• und Managementchips.

Das macht sie nicht wertlos.

Aber es zeigt die Grenze des Begriffs Autarkie.

Ein europäisches Rechenzentrum kann juristisch und operativ sehr souverän sein und hardwareseitig trotzdem stark global abhängig bleiben.

Die relevante Frage lautet deshalb wieder:

Wie austauschbar ist die jeweilige Abhängigkeit?

Eine CPU ist in vielen Fällen mittelfristig austauschbar.

Eine Anwendung mit 200 proprietären APIs möglicherweise nicht.

Eine GPU kann technisch austauschbar sein – bis die komplette Software an CUDA hängt.

Genau deshalb ist Scaleways AMD/ROCm-Projekt interessant. [35]

Nicht weil AMD europäisch wäre.

Sondern weil es einen zweiten technologischen Pfad eröffnet.

Vom politischen Anspruch zu einer tatsächlich souveräneren Architektur

An diesem Punkt würde ich die Diskussion weg von der Frage

„Welcher Anbieter ist souverän?“

hin zu einer anderen Frage bewegen:

„Wie souverän ist unser konkretes System?“

Denn ein Provider kann hervorragend sein.

Der Kunde kann trotzdem eine katastrophale Architektur darauf bauen.

Und andersherum kann eine Organisation auf einem großen Hyperscaler bestimmte Risiken erstaunlich gut kontrollieren, wenn sie die kritischen Abhängigkeiten bewusst begrenzt.

Souveränität muss deshalb Teil von Architektur, Einkauf, Vertragsgestaltung und Betrieb werden.

Beschaffung ist Architektur

Gerade öffentliche Verwaltung und regulierte Unternehmen sollten Souveränitätsanforderungen nicht erst nach Vertragsabschluss entdecken.

Das JRC betont inzwischen ausdrücklich, dass öffentliche Beschaffung als Markthebel genutzt werden kann, um Wettbewerb zu fördern und die Überabhängigkeit von einzelnen kritischen Lieferanten zu reduzieren. [17]

CADA schlägt sogar einen gemeinsamen EU-Beschaffungsrahmen für öffentliche Cloud- und AI-Beschaffung vor. [8]

Das ist wichtig.

Denn wer in der Ausschreibung lediglich fragt:

Preis?

ISO 27001?

Rechenzentrum Deutschland?

hat einen großen Teil der Souveränitätsfrage noch nicht gestellt.

Was ich in kritischen Cloudverträgen verlangen würde

Natürlich kann kein Vertrag einen Anbieter verpflichten, geltendes Recht oder Sanktionen zu ignorieren.

Genau deshalb sollte eine Klausel für geopolitische Konflikte nicht lauten:

„Der Anbieter darf niemals abschalten.“

Das wäre gegebenenfalls wertlos.

Sinnvoller wären Anforderungen an:

• rechtlich zulässige Vorwarnung,
• Datenherausgabe,
• Übergangsunterstützung,
• Fortbetrieb nicht betroffener Dienste,
• lokale Recovery-Möglichkeiten
• und dokumentierte Notfallverfahren.

Und jetzt zum Exit

Ich würde für kritische Systeme tatsächlich einen Begriff etablieren, der in vielen Organisationen heute fehlt:

Exit Time Objective – ETO

Wir kennen RTO.

Recovery Time Objective.

Wie schnell muss ein System nach einem Ausfall wiederhergestellt sein?

Wir kennen RPO.

Recovery Point Objective.

Wie viel Datenverlust ist akzeptabel?

Warum gibt es für strategisch wichtige Cloudplattformen nicht genauso selbstverständlich:

ETO – Wie lange darf es dauern, diesen Anbieter vollständig zu verlassen?

ETO ist hier mein vorgeschlagenes Architekturkonzept, kein offizieller EU-Begriff.

Aber es passt ausgesprochen gut zu Data Act, DORA und den JRC-Ansätzen.

Ein Beispiel könnte so aussehen:

Nicht jedes System braucht ETO 4.

Das wäre wirtschaftlicher Wahnsinn.

Ein internes Wiki darf vielleicht sechs Monate brauchen.

Eine kritische Zahlungsplattform möglicherweise nicht.

Die relevante Frage lautet nur:

Haben wir überhaupt eine Zahl?

So würde ich einen Exit testen

Nicht mit einem Workshop.

Mit Technik.

Einmal pro Jahr – bei besonders kritischen Systemen vielleicht häufiger – wird ein echter Exit-Test durchgeführt.

Man nimmt einen repräsentativen Datenbestand.

Exportiert ihn.

Spielt ihn beim alternativen Provider ein.

Deployt die Infrastruktur aus OpenTofu oder einem vergleichbaren IaC-System.

Stellt Netzwerk und Firewallregeln wieder her.

Bindet Identity an.

Importiert Secrets.

Testet Schlüssel.

Startet Anwendungen.

Stellt Monitoring her.

Testet Backups.

Schaltet einen Test-DNS-Namen um.

Misst die Zeit.

Und dann schreibt man nicht:

„Migration erfolgreich.“

Sondern:

Actual ETO: 19 Tage.

Blocker:
IAM.
KMS.
4,8 TB Object Storage.
zwei proprietäre EventBridge-Integrationen.
fehlende PostgreSQL Extension.

Das ist plötzlich eine sehr andere Qualität von Souveränität.

Control-Plane-Tests gehören ebenfalls hinein

Ich würde bei besonders kritischer Infrastruktur zusätzlich testen:

• Was passiert, wenn die globale Provider-Control-Plane nicht erreichbar ist?
• Laufen bestehende Anwendungen weiter?
• Funktioniert lokale Authentifizierung?
• Sind Break-Glass-Accounts verfügbar?
• Funktioniert die Schlüsselnutzung?
• Sind Runbooks offline vorhanden?
• Kann die Organisation Backups ohne SaaS-Ticketing-System finden?
• Kann sie kommunizieren, wenn Teams oder Slack nicht erreichbar sind?

Das klingt paranoid.

Bis ein großer Cloud- oder Identity-Provider ausfällt.

Dann nennt man es Business Continuity.

Und dann braucht Souveränität eine Messmethode

Im bereitgestellten Ausgangsmaterial wird mit ES3 – European Sovereign Stack Standard – bereits ein privatwirtschaftliches Bewertungsmodell beschrieben, das unter anderem Strategie, Rechtsraum, Daten, Betrieb, Lieferkette, Technologie, Security und AI betrachtet und Evidenzen statt bloßer Ja/Nein-Antworten verlangt.

Ich würde so ein kommerzielles Framework allerdings klar von EU-Recht oder offiziellen Standards unterscheiden.

Das interessante Prinzip dahinter ist trotzdem richtig:

Souveränität muss beweisbar werden.

Das passt inzwischen sehr gut zu den JRC-Instrumenten Self-Assessment, Canvas und Metrics. [14] [15] [16]

Ein mögliches Sovereignty Maturity Model

Ich würde fünf Stufen verwenden.

Dazu würde ich nicht einen einzigen magischen Score verwenden, sondern mehrere Dimensionen bewerten.

Zum Beispiel jeweils von 0 bis 4:

Man könnte daraus ein gewichtetes Profil berechnen.

Aber ich würde niemals nur eine Zahl veröffentlichen.

Denn ein System mit:

95 Prozent Datenkontrolle

und

null Prozent Exitfähigkeit

ist nicht automatisch „47,5 Prozent souverän“.

So funktioniert Risiko nicht.

Und genau deshalb gefällt mir die Richtung des JRC-Metrics-Ansatzes. Dort werden Abhängigkeit, Kontrolle, Capability, Resilienz und strategische Bedeutung über mehrere Ebenen hinweg betrachtet. [16]

Souveränität braucht außerdem personelle Kapazität

Das wird vielleicht der härteste Punkt für Europa.

Software kann man herunterladen.

Server kann man kaufen.

Rechenzentren kann man bauen.

Aber einen erfahrenen OpenStack-, Ceph-, Kubernetes-, PostgreSQL-, Identity- oder Security-Engineer kann man nicht mit apt install installieren.

Wenn Europa wirklich mehr technologische Kontrolle will, braucht es Betreiberkompetenz.

• Cloud Engineers.
• SREs.
• DBAs.
• Security Engineers.
• Chipdesigner.
• AI Engineers.
• Netzwerkexperten.
• Firmware-Spezialisten.

Und öffentliche Verwaltungen, die diese Leute nicht nur rekrutieren, sondern auch halten können.

Das JRC führt „people and digital skills“ deshalb völlig zu Recht als eigene Ebene seiner Souveränitätsmessung. [16] [17]

Die wirtschaftliche Seite darf man ebenfalls nicht wegromantisieren

Mehr Souveränität kostet.

Redundante Anbieter kosten.

Eigene Betriebsorganisation kostet.

Unabhängige Backups kosten.

Zweite DNS-Provider kosten.

Exit-Tests kosten.

Alternative Cloudkapazitäten kosten.

Know-how kostet.

Open Source kann Lizenzkosten sparen.

Aber Betrieb kostet trotzdem.

Deshalb halte ich eine pauschale Multi-Cloud-Pflicht ebenfalls für keine gute Idee.

Zwei Clouds gleichzeitig zu betreiben kann bedeuten:

• doppelte Skills,
• doppelte Toolchains,
• doppelte Security,
• doppelte Fehlermöglichkeiten
• und am Ende den kleinsten gemeinsamen technischen Nenner.

Das Ziel sollte deshalb nicht lauten:

Jede Anwendung muss jederzeit auf fünf Clouds laufen.

Das Ziel sollte lauten:

Für jede kritische Anwendung muss klar sein, welche Abhängigkeit wir bewusst akzeptieren.

Und bei den wirklich wichtigen Abhängigkeiten brauchen wir einen Plan B.

Fazit: Europa braucht keine digitale Insel – sondern echte Wahlfreiheit

Vielleicht ist das die wichtigste Erkenntnis nach all diesen Ebenen, Gesetzen, Anbietern und technischen Details.

Wir werden digitale Abhängigkeiten nicht abschaffen.

Der Server kann in Brandenburg stehen.

Der Betreiber kann deutsch sein.

Der Vertrag kann deutschem Recht unterliegen.

Die CPU kommt trotzdem möglicherweise von AMD oder Intel.

Die GPU von NVIDIA.

Der Chip wird in Taiwan gefertigt.

Memory kommt aus Südkorea.

Firmware aus verschiedenen internationalen Lieferketten.

Linux wird weltweit entwickelt.

Kubernetes ebenso.

Eine Dependency stammt vielleicht von einem Maintainer aus Kanada.

Der Build läuft über GitHub.

Das Monitoring verwendet ein amerikanisches SaaS-Produkt.

Und ein Unterseekabel verbindet das europäische Rechenzentrum mit einem Dienst auf einem anderen Kontinent.

Willkommen in moderner IT.

Das Problem ist nicht, dass diese Abhängigkeiten existieren.

Das Problem entsteht, wenn wir sie nicht kennen.

Oder wenn aus einer Abhängigkeit Alternativlosigkeit wird.

Und genau deshalb halte ich die europäische Entwicklung der vergangenen Jahre für interessanter, als die übliche Kritik an der langsamen EU vermuten lässt.

Der Data Act beschäftigt sich mit Wechselbarkeit. [5]

DORA mit ICT-Drittanbietern, Konzentrationsrisiken und Exit. [6]

NIS2 mit Supply Chain und Resilienz. [7]

Der Cloud and AI Development Act versucht, Souveränität in unterschiedliche Assurance Levels zu übersetzen. [8]

Chips Act 2.0 geht eine Ebene tiefer zu den Halbleitern. [10]

Die Open Source Strategy adressiert Softwareabhängigkeit. [12]

Die ICT Supply Chain Security Toolbox diskutiert Multi-Vendor, kritische Lieferanten und politische Lieferkettenrisiken. [13]

Und das Joint Research Centre baut inzwischen Self-Assessments, Canvas-Methoden und Messmodelle, mit denen Organisationen ihre tatsächlichen Abhängigkeiten untersuchen können. [14] [15] [16]

Das ist kein fertiges System.

CADA und Chips Act 2.0 sind noch in Verhandlung. [9] [11]

NIS2 ist noch nicht überall gleich umgesetzt. [52]

Der Data Act wird seine vollständige Wirkung beim Cloud Switching erst mit der nächsten Stufe im Januar 2027 entfalten. [5]

Aber man kann kaum noch behaupten, Europa habe keine Strategie.

Im Gegenteil.

Langsam entsteht etwas, das ich für ziemlich vernünftig halte.

Nicht digitale Autarkie.

Nicht „Europe only“.

Nicht die Illusion, dass ein EU-Logo auf einem Rechenzentrum sämtliche geopolitischen und technischen Risiken beseitigt.

Sondern eine Architektur aus:

• Kontrolle,
• Transparenz,
• Interoperabilität,
• offenen Standards,
• Open Source,
• Resilienz,
• Diversifizierung,
• Beschaffung,
• messbaren Abhängigkeiten
• und realen Exit-Optionen.

Und damit kommen wir zurück zu der unbequemen Frage vom Anfang.

Wie souverän ist eine europäische Cloud, wenn zentrale Komponenten weiterhin aus den USA oder Asien kommen?

Die Antwort lautet:

Sie kann sehr souverän sein.

Wenn sie uns Kontrolle über Daten gibt.

Wenn sie europäischem Recht unterliegt.

Wenn Betrieb und privilegierte Zugriffe beherrschbar sind.

Wenn Schlüssel unter unserer Kontrolle stehen.

Wenn offene Schnittstellen existieren.

Wenn wir die Software oder zumindest unsere Workloads auf eine andere Plattform bringen können.

Wenn die Control Plane nicht zum einzigen Kill Switch wird.

Wenn wir die Hardwareabhängigkeiten kennen.

Wenn wir mehr als einen technologischen Weg besitzen.

Wenn wir eigenes Know-how erhalten.

Und vor allem:

wenn wir wieder gehen können.

Eine europäische Cloud mit NVIDIA-GPUs kann deshalb unter Umständen souveräner sein als eine vollständig proprietäre Plattform mit „EU Data Residency“.

Ein Open-Source-Stack kann souveräner sein, obwohl seine Entwickler über die ganze Welt verteilt sind.

Ein amerikanischer Hyperscaler kann für einen unkritischen Workload trotzdem die wirtschaftlich und technisch beste Entscheidung sein.

Und ein europäischer Anbieter kann die falsche Entscheidung sein, wenn er eine neue unauflösbare Monokultur erzeugt.

Souveränität ist kein Herkunftszertifikat.

Sie ist auch kein Produkt.

Und sie ist definitiv keine Checkbox im Einkauf.

Sie ist eine Architektureigenschaft und eine organisatorische Fähigkeit.

Deshalb würde ich am Ende nicht fragen:

„Nutzen wir europäische Technologie?“

Ich würde fragen:

„Welche unserer heutigen Abhängigkeiten könnten uns morgen handlungsunfähig machen?“

Dann:

„Wie lange würden wir brauchen, um sie zu ersetzen?“

Und schließlich:

„Haben wir das jemals ausprobiert?“

Wenn die Antwort auf die letzte Frage Nein lautet, sind wir vielleicht weniger souverän, als unsere PowerPoint-Folie behauptet.

Die wahrscheinlich ehrlichste Definition bleibt deshalb:

Digitale Souveränität bedeutet nicht, niemanden mehr zu brauchen. Digitale Souveränität bedeutet, selbst entscheiden zu können, wen man braucht – und eine Alternative zu besitzen, wenn sich diese Entscheidung ändern muss.

Oder ganz kurz:

Souverän ist, wer noch Nein sagen kann.

Quellen und Linkliste

1. Europäische Kommission – Strengthening Europe’s Tech Sovereignty
   Grundlegende Definition und Überblick über die europäische Technologiesouveränitätsstrategie.
   https://digital-strategy.ec.europa.eu/en/policies/eu-tech-sovereignty
2. Europäische Kommission – Communication on European Tech Sovereignty and EU Open Source Strategy, COM(2026) 503, 3. Juni 2026
   Gesamtstrategie von Chips über Infrastruktur und Software bis Cloud und AI.
   https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy
3. Joint Research Centre – Digital Sovereignty as a Geopolitical Strategy, Mai 2026
   Souveränität als strategische Handlungsfähigkeit bei gleichzeitiger Offenheit und internationaler Vernetzung.
   https://publications.jrc.ec.europa.eu/repository/handle/JRC146878
4. Joint Research Centre – Open but Not Powerless: Towards a Common Understanding of EU Digital Sovereignty
   Grundlagenpapier zur mehrdimensionalen europäischen Souveränität.
   https://publications.jrc.ec.europa.eu/repository/handle/JRC144908
5. Europäische Kommission – Data Act explained
   Cloud Switching, offene Schnittstellen, funktionale Äquivalenz und Abschaffung von Switching-/Egress-Charges ab 12. Januar 2027.
   https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained
   Verordnungstext:
   https://eur-lex.europa.eu/eli/reg/2023/2854/oj
6. EU – Digital Operational Resilience Act, DORA
   Regelwerk für ICT-Risiko, Drittanbieter, Resilienz, Konzentration und Exit im Finanzsektor.
   https://eur-lex.europa.eu/eli/reg/2022/2554/oj
   Europäische Kommission – DORA-Informationen:
   https://finance.ec.europa.eu/digital-finance/digital-operational-resilience-act_en
7. EU – NIS2 Directive
   Cybersecurity-Risikomanagement einschließlich Business Continuity und Supply-Chain-Security.
   https://eur-lex.europa.eu/eli/dir/2022/2555/oj
   EU-Kommission:
   https://digital-strategy.ec.europa.eu/en/policies/nis2-directive
8. Europäische Kommission – Cloud and AI Development Act, 3. Juni 2026
   Vorgeschlagene Souveränitätslevel, Infrastrukturziele und gemeinsamer EU-Beschaffungsrahmen.
   https://digital-strategy.ec.europa.eu/en/policies/cloud-and-ai-development-act
9. Rat der Europäischen Union – laufende Beratung des Cloud and AI Development Act
   Beispiel für den Stand der Ratsarbeit am 29. September 2026.
   https://www.consilium.europa.eu/en/meetings/mpo/2026/9/working-party-on-telecommunications-and-information-society-%28370073%29/
10. Europäische Kommission – Proposal for Chips Act 2.0
    Strategische Halbleiterkapazitäten, Resilienz und Lieferketten.
    https://digital-strategy.ec.europa.eu/en/library/proposal-chips-act-20
11. Rat der Europäischen Union – Chips Act 2.0, Arbeitsgruppe Oktober 2026
    Aktueller Beratungsstand und Präsidentschafts-Kompromisstext.
    https://www.consilium.europa.eu/en/meetings/mpo/2026/10/working-party-on-competitiveness-and-growth-industry-%28370308%29/
12. Europäische Kommission – EU Open Source Strategy
    Open Source als Bestandteil europäischer Technologiesouveränität.
    https://digital-strategy.ec.europa.eu/en/policies/open-source-strategy
13. EU ICT Supply Chain Security Toolbox, Februar 2026
    Kritische Lieferanten, Multi-Vendor, Hochrisikoanbieter und Supply-Chain-Risikomanagement.
    https://digital-strategy.ec.europa.eu/en/library/toolbox-improve-ict-supply-chain-security
14. JRC – Digital Sovereignty Self-assessment Tool
    Organisatorischer Selbsttest für digitale Abhängigkeiten und Vendor Lock-in.
    https://knowledge4policy.ec.europa.eu/digital-sovereignty/topic/digital-sovereignty-self-assessment-tool_en
15. JRC – Digital Sovereignty Canvas
    Analyse von Abhängigkeiten, Kosten, Nutzen und möglichen Transformationspfaden.
    https://knowledge4policy.ec.europa.eu/digital-sovereignty/topic/digital-sovereignty-canvas_en
16. JRC – Digital Sovereignty Metrics
    Messrahmen für Abhängigkeit, Kontrolle, Capability und Resilienz.
    https://knowledge4policy.ec.europa.eu/digital-sovereignty/topic/digital-sovereignty-metrics_en
17. JRC – Advancing EU Digital Sovereignty in Public Administrations, Juli 2026
    Rolle öffentlicher Beschaffung, Marktdiversifizierung, Infrastruktur und Governance.
    https://publications.jrc.ec.europa.eu/repository/handle/JRC146997
18. JRC – Environmental Dimension of Digital Sovereignty
    Energie, Rohstoffe und Nachhaltigkeit als Bestandteil digitaler Resilienz.
    https://knowledge4policy.ec.europa.eu/digital-sovereignty/topic/environmental-dimension-digital-sovereignty_en
19. U.S. Department of Justice – CLOUD Act White Paper
    Offizielle US-Darstellung zu Herausgabepflichten und Daten unter „possession, custody or control“.
    https://www.justice.gov/archives/opa/pr/justice-department-announces-publication-white-paper-cloud-act
20. People’s Republic of China – Foreign Relations Law
    Offizielle englischsprachige Veröffentlichung des chinesischen Justizministeriums.
    https://en.moj.gov.cn/2023-06/29/c_898506.htm
21. People’s Republic of China – Data Security Law
    Offizielle englischsprachige Veröffentlichung.
    https://en.spp.gov.cn/2021-06/10/c_948426.htm
22. CISA und internationale Partner – Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide, 2025
    Technische Dokumentation staatlich zugerechneter chinesischer Cyberaktivitäten einschließlich Salt-Typhoon-Überschneidungen.
    https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a
23. Associated Press – Trump’s sanctions on ICC prosecutor have halted tribunal’s work, Mai 2025
    Praktische Auswirkungen der Sanktionen auf E-Mail, Finanz- und andere Dienstleistungen.
    https://apnews.com/article/a4b4c02751ab84c09718b1b95cbd5db3
24. Reuters – US imposes sanctions on ICC, 9. Oktober 2026
    Aktuelle Ausweitung der Sanktionen gegen den Internationalen Strafgerichtshof.
    https://www.reuters.com/world/us-imposes-sanctions-international-criminal-court-hours-after-former-judge-wins-2026-10-09/
25. Microsoft – Statement regarding ICC, Mai 2025
    Klarstellung zur Behandlung des ICC und sanktionierter Einzelpersonen.
    https://news.microsoft.com/da-dk/2025/05/28/kommentar-fra-microsoft-vedr-icc/
26. Reuters – Amazon launches European Sovereign Cloud, 15. Januar 2026
    AWS European Sovereign Cloud, Brandenburg und organisatorische Separierung.
    https://www.reuters.com/business/retail-consumer/amazon-launches-new-europe-based-cloud-service-address-user-concerns-2026-01-15/
27. Reuters – France swaps Microsoft for Scaleway to repatriate Health Data Hub, 23. April 2026
    Konkreter Wechsel einer besonders sensiblen staatlichen Plattform von Azure zu Scaleway.
    https://www.reuters.com/world/europe/france-swaps-microsoft-iliads-scaleway-repatriate-health-data-hub-2026-04-23/
28. heise/c’t – Open-Source-Migration in Schleswig-Holstein
    Praxisbericht zu organisatorischen und technischen Herausforderungen.
    https://www.heise.de/hintergrund/Zwischenstand-bei-der-Migration-zu-Open-Source-in-Schleswig-Holstein-10672370.html
    Weiterer Zwischenstand:
    https://www.heise.de/hintergrund/Schleswig-Holstein-Fast-80-Prozent-der-Microsoft-Lizenzen-gekuendigt-10960941.html
29. Reuters – What caused the global cyber outage?, 19. Juli 2024
    CrowdStrike-Ausfall und Konzentrationsrisiken.
    https://www.reuters.com/technology/what-caused-global-cyber-outage-2024-07-19/
    Reuters – Backup- und Konzentrationsanalyse:
    https://www.reuters.com/technology/without-backup-plans-global-it-outages-will-happen-again-2024-07-19/
30. Reuters – Google services down in Turkey and parts of Europe, 4. September 2025
    Beispiel eines länderübergreifenden Plattformausfalls.
    https://www.reuters.com/world/middle-east/google-services-were-down-turkey-parts-europe-2025-09-04/
31. Reuters – Azure disruption after subsea cable cuts, September 2025
    Beispiel für die physische Netzabhängigkeit von Cloudservices.
    https://www.reuters.com/ar/technology/35XFIMGIARMD3KOCAYDGAMYWK4-2025-09-06/
32. Anthropic – Redeploying Fable 5, Juni 2026
    Offizielle Darstellung der US-Exportkontrolle, Abschaltung und anschließenden Wiederfreigabe.
    https://www.anthropic.com/news/redeploying-fable-5
    Reuters-Berichterstattung zur ursprünglichen Einschränkung, syndiziert:
    https://www.investing.com/news/stock-market-news/us-blocks-foreign-access-to-anthropics-most-advanced-ai-models-4740798
33. Reuters – Microsoft to fund Mistral’s European AI expansion, 21. Juli 2026
    Europäische AI-Infrastruktur in Verbindung mit Microsoft-Plattformen.
    https://www.reuters.com/business/microsoft-fund-mistrals-european-ai-expansion-multibillion-dollar-deal-2026-07-21/
34. Reuters – Germany plans AI cooperation deal with Nvidia, 15. Oktober 2026
    SOOFI, NVIDIA und industrielle AI-Infrastruktur.
    https://www.reuters.com/business/germany-plans-ai-cooperation-deal-with-nvidia-handelsblatt-says-2026-10-15/
35. Reuters – Scaleway to build AMD-powered AI supercomputer in Sweden, 13. Oktober 2026
    Hardwarediversifizierung und ROCm als Alternative im AI-Stack.
    https://www.reuters.com/business/media-telecom/scaleway-build-amd-powered-ai-supercomputer-sweden-2026-10-13/
    Scaleway/NVIDIA Kopenhagen:
    https://www.reuters.com/business/media-telecom/scaleway-open-nvidia-powered-computing-site-copenhagen-2026-10-13/
36. Reuters – Airbus picks Scaleway for AI and defence work, 16. Juli 2026
    Souveränitätskriterien, extraterritoriale Rechtsrisiken und Migration kritischer Anwendungen.
    https://www.reuters.com/legal/litigation/airbus-picks-iliads-scaleway-ai-defence-work-sovereignty-push-2026-07-16/
37. STACKIT – Produktdokumentation
    Cloud-, Kubernetes-, Storage-, Datenbank- und AI-Angebote.
    https://docs.stackit.cloud/
    https://www.stackit.de/
38. IONOS Cloud – Dokumentation
    Cloud- und Managed-Service-Angebote.
    https://docs.ionos.com/cloud/
    https://cloud.ionos.de/
39. Open Telekom Cloud – Dokumentation und Produktübersicht
    OpenStack-orientierte Cloudplattform der T-Systems.
    https://www.open-telekom-cloud.com/
    https://docs.otc.t-systems.com/
40. Hetzner Cloud
    Compute, Bare Metal, Object Storage und weitere Infrastrukturservices.
    https://www.hetzner.com/cloud/
41. plusserver / pluscloud open
    OpenStack- und Sovereign-Cloud-Stack-orientierte Infrastruktur.
    https://www.plusserver.com/produkt/pluscloud-open/
42. OVHcloud Public Cloud
    Europäische OpenStack-basierte Public Cloud, Managed Kubernetes, Datenbanken und AI-Infrastruktur.
    https://www.ovhcloud.com/de/public-cloud/
43. Scaleway
    Europäische Cloud- und AI-Plattform.
    https://www.scaleway.com/
44. UpCloud
    Finnischer europäischer Cloudanbieter.
    https://upcloud.com/
45. Kubernetes
    https://kubernetes.io/
46. OpenStack
    https://www.openstack.org/
47. OpenTofu
    https://opentofu.org/
48. Keycloak
    https://www.keycloak.org/
49. OpenBao
    https://openbao.org/
50. Ceph
    https://ceph.io/
51. PostgreSQL
    https://www.postgresql.org/
52. Europäische Kommission – aktueller NIS2-Umsetzungsstand, Juli 2026
    Kommission verweist Irland, Spanien, Frankreich und Niederlande an den EuGH.
    https://digital-strategy.ec.europa.eu/en/news/commission-refers-ireland-spain-france-and-netherlands-court-justice-failing-transpose-rules
53. Europäische Kommission – DORA und ICT-Third-Party-Concentration
    Hintergrund zum europäischen Aufsichtsrahmen für kritische ICT-Drittanbieter.
    https://finance.ec.europa.eu/regulation-and-supervision/financial-services-legislation/digital-finance/digital-operational-resilience-act_en
54. Joint Research Centre – Digital Sovereignty Science for Policy Forum, 16. November 2026
    Aktuelle Weiterarbeit zu Infrastruktur, Open Source, AI, Daten, Industrie und gesellschaftlichen Dimensionen digitaler Souveränität.
    https://knowledge4policy.ec.europa.eu/digital-sovereignty/digital-sovereignty-science-policy-forum_en

↑ Zurück nach oben