Digitale Souveränität in der Cloud

Digitale Souveränität ist nicht mit DSGVO-Konformität erledigt. Entscheidend ist, wer bestimmt, ob, wo und unter welchem Recht Ihre Berechnungen stattfinden — über sechs Hebel hinweg: Compute und Infrastruktur, industrielle Ökosysteme, Plattformen, Standards, Wertschöpfung und die strukturelle Position. Souveränität entsteht nicht in einer einzelnen Schicht, sondern aus deren Ausrichtung.

Die DSGVO verlangt, dass Daten die EU-Jurisdiktion nicht verlassen; der US CLOUD Act erlaubt US-Behörden den Zugriff bei US-kontrollierten Anbietern — unabhängig vom Speicherort. Microsoft erklärte im Juni 2025 vor einem französischen Gericht, Souveränität gegenüber dem CLOUD Act nicht garantieren zu können. Ein Rechenzentrum in Frankfurt löst diesen Konflikt nicht, solange der Anbieter US-Recht unterliegt.

Das EU-SEAL-Framework definiert acht gewichtete, auditierbare Sovereignty-Objectives und fünf Stufen — von SEAL 1 (Basis) über SEAL 2 (personenbezogene Daten) und SEAL 3 (kritische Infrastruktur) bis SEAL 5 (nationale Sicherheit). Der BSI-Katalog C3A v1.0 vom 27.04.2026 konkretisiert das Framework für Deutschland mit den Kriterienbereichen SOV-1 bis SOV-6. Damit lässt sich die Souveränitäts-Position eines Cloud-Einsatzes objektiv bewerten und in Ausschreibungen verankern.

Verschlüsselung schützt nur, wenn der Anbieter die Schlüssel nicht selbst hält: Für sensible Daten gehören eigene Encryption-Keys statt eines Anbieter-KMS zum Pflichtprogramm (C3A SOV-3), ergänzt um dokumentierte Exit-Pfade für Daten und Services. Die EuroStack-Initiative zeigt zugleich, dass ein europäischer Stack real existiert — von Cloud und Compute (OVHcloud, STACKIT, Scaleway) bis zu Anwendungen und KI (Mistral, Aleph Alpha).

Auf die EU-Erklärung zur digitalen Souveränität (Ende 2025) folgten der EU Cloud and AI Development Act sowie im April 2026 das SEAL-Framework samt einem Cloud-Sovereignty-Tender über 180 Mio. Euro und der BSI C3A v1.0. Souveränität wandelt sich damit vom Marketing-Begriff zur auditierbaren Kategorie. Vorsicht vor Sovereignty-Washing: „Daten bleiben in der EU“ ist kein Nachweis, wenn der Sitz des Anbieters den CLOUD Act greifen lässt.

Erstens Workloads nach Souveränitäts-Kritikalität klassifizieren (C3A SOV-1), zweitens eine Baseline gegen die Kriterienbereiche Recht, Betrieb und Lieferkette auditieren. Drittens Exit-Pläne für Daten- und Service-Pfade dokumentieren, viertens SEAL-Stufen als Vergabekriterium in RFPs verankern — etwa SEAL 2 für personenbezogene Daten und SEAL 3 für kritische Infrastruktur. Fünftens Schlüsselhoheit herstellen: eigene Encryption-Keys, kein Anbieter-KMS für sensible Daten.