← Zurück zu allen Artikeln
Data & Architektur

Digitale Souveränität: Mehr als die Cloud-Frage

Veröffentlicht am 18. Juni 2026 · Lesezeit: 10 Minuten

Die Debatte um digitale Souveränität wird in Europa oft auf eine einzige Frage reduziert: US-Hyperscaler oder europäischer Anbieter? Diese Verkürzung greift zu kurz. Souveränität ist kein binärer Schalter und kein Infrastruktur-Label. Sie ist eine durchgängige Architekturentscheidung — von der Infrastruktur über die Plattform bis zur Schicht, in der Geschäftswissen kodiert ist.

Die Grundthese: Offene Standards und Open Source für die geschäftskritische Logik; proprietäre Dienste nur dort, wo sie vollständig austauschbar und standardisiert sind. Was einfach klingt, erfordert in der Praxis eine differenzierte Betrachtung auf mehreren Ebenen.

1. Souveränität ist ein Spektrum

Es gibt kein binäres „souverän" oder „nicht souverän". Souveränität ist eine bewusste Entscheidung darüber, auf welcher Ebene man Kontrolle behalten will — und was ein realistischer Exit-Plan ist, falls ein Anbieter verschwindet oder sich verändert.

Die EU hat das mittlerweile formalisiert. Der Cloud and AI Development Act (CADA) definiert vier Souveränitätsstufen:

  1. Daten werden in EU-Infrastruktur verarbeitet und gespeichert
  2. Unabhängigkeit von Drittstaaten, Transparenz der Software-Lieferkette
  3. EU-Eigentum und -Kontrolle, Anforderungen an Personalstaatsbürgerschaft
  4. Vollständige Transparenz und Kontrolle über die Software-Lieferkette, kein Drittstaateneinfluss

In Kombination mit der SecNumCloud (Frankreich/ANSSI) und dem C5-Katalog (BSI) entsteht ein kohärentes europäisches Rahmenwerk, das Souveränität nicht als Wunsch formuliert, sondern als prüfbare Anforderung. Die gemeinsame Erklärung von ANSSI und BSI zu Cloud-Souveränitätskriterien (November 2025) unterstreicht die deutsch-französische Konvergenz.

Entscheidend ist: Jede Organisation muss für sich definieren, welche Stufe für welche Daten und Workloads angemessen ist. Nicht alles braucht Stufe 4. Aber die bewusste Entscheidung muss getroffen werden.

2. Eine ehrliche Bestandsaufnahme europäischer Alternativen

Der regulatorische Rahmen steht. Aber wie sieht es auf der Angebotsseite aus?

Die Realität: Europäische Hyperscaler sind den großen US-Anbietern in mehreren Dimensionen hinterher:

  • Developer Experience ist nicht auf dem Niveau von AWS, Azure oder GCP. Wer von einem US-Hyperscaler zu einem europäischen Anbieter wechselt, spürt den Unterschied in Tooling, Dokumentation und Automatisierungsgrad.
  • Geo-Redundanz ist bei einigen Anbietern nicht vollständig gegeben. Für anspruchsvolle HA- und DR-Anforderungen ein reales Risiko.
  • Managed Services sind weniger breit und weniger ausgereift. Feature-Gaps gegenüber den globalen Angeboten existieren.
  • Der Nachfragedruck aus der europäischen Industrie ist enorm — übersteigt aber aktuell die Lieferfähigkeit vieler europäischer Anbieter.

Das ist kein Argument gegen europäische Anbieter. Es ist ein Argument für Ehrlichkeit: Wer Souveränität will, muss verstehen, welche Trade-offs das heute noch bedeutet — und bewusst entscheiden, welche davon tragbar sind.

Gleichzeitig gibt es echte Stärken:

  • Anbieter wie STACKIT setzen auf OpenStack — ein vollständig offener, transparenter und auditierbarer Stack. Transparenz auf Infrastrukturebene ist ein realer Souveränitätsvorteil.
  • Gaia-X hat den Sprung von der Architekturvision zur operativen Infrastruktur geschafft: Digital Clearing Houses sind live, das Framework wird in konkreten Datenräumen wie Catena-X produktiv genutzt.
  • Das IPCEI-CIS-Programm und Projekte wie EURO-3C investieren massiv in föderierte europäische Cloud-Infrastruktur.
  • Die Basisfunktionalität für Large-Scale-Workloads ist vorhanden. Für viele Anwendungsfälle reicht das europäische Angebot bereits.

3. Souveränität geht weit über den Hyperscaler hinaus

Hier liegt der entscheidende Denkfehler: Die Frage „welcher Cloud-Anbieter?" ist nur die oberste Schicht. Die eigentliche Abhängigkeit entsteht tiefer — und betrifft auch rein europäische Lösungen:

  • Proprietäre APIs und Abfragesprachen, die eine Migration zu einem anderen Tool strukturell verhindern
  • Datenformate, die nicht standardisiert und nicht ohne Informationsverlust exportierbar sind
  • Transformationslogik und Business-KPIs, die in herstellerspezifischen Layern leben und nicht als offene Standards extrahierbar sind
  • Plattform-spezifisches Wissen, das Teams aufbauen und das bei einem Wechsel verloren geht

Auch innerhalb Europas schaffen proprietäre Lösungen Abhängigkeiten. End-to-End-Plattformen können beschleunigen und sind für Commodity-Aufgaben relevant, die kein tiefes fachliches Domänenwissen erfordern. Aber: Im Zeitalter von KI muss die Schicht, die Geschäftswissen enthält, technologieagnostisch bleiben.

Das ist eine anspruchsvolle Forderung. In der Praxis bedeutet sie:

  • Geschäftslogik in offenen, portablen Formaten halten — nicht in proprietären Views oder Reflections einschließen
  • Daten in offenen Formaten speichern, die von mehreren Tools gelesen werden können
  • Lineage und Governance über offene Standards abbilden
  • Semantic Layers so gestalten, dass ihre Definitionen exportierbar und migrierbar sind

4. Offene Standards als Souveränitätsgrundlage

Was die Souveränitätsdebatte seit 2024 verändert hat, ist die Reifung offener Standards, die erstmals eine realistische Alternative zur Plattformabhängigkeit bieten. Am Beispiel von Datenplattformen:

  • Apache Iceberg als offenes Table-Format, das von verschiedensten Engines gelesen und geschrieben werden kann
  • Apache Parquet als Columnar-Speicherformat mit vendor-neutralem Encoding
  • OpenLineage als offener Standard für Data Lineage über Tool-Grenzen hinweg
  • Delta Lake (Apache-lizenziert, unter Linux Foundation Governance) als Alternative mit breiter Community

Diese Konvergenz offener Standards existiert zunehmend in vielen Domänen — von Identität (DID, Verifiable Credentials) über API-Design (OpenAPI, GraphQL) bis zu Infrastruktur (OpenStack, Kubernetes, OCI). Das Muster ist immer dasselbe: Offene Standards entkoppeln die Logik von der Infrastruktur und machen Wechsel möglich, ohne alles neu zu bauen.

Wer bewusst auf diese Standards setzt, reduziert Abhängigkeit nicht durch Vermeidung von Technologie, sondern durch kluge Wahl der Abstraktionsebene.

5. „Govern Everything" statt „Migrate Everything"

Ein Paradigmenwechsel, der sich quer durch die Industrie abzeichnet: Die Prämisse, alle Daten und Workloads zuerst in eine zentrale Plattform migrieren zu müssen, weicht dem Prinzip Govern Everything, Move Nothing.

Statt Daten physisch zu bewegen, wird ein Governance-Layer darüber gelegt, der Zugriff, Qualität und Lineage steuert — unabhängig davon, wo die Daten liegen. Data Virtualisation, föderierte Queries und Zero-Copy-Zugriff machen das technisch möglich.

Die Souveränitätsrelevanz: Wenn Daten nicht bewegt werden müssen, entfällt ein zentrales Lock-in-Risiko. Die Hoheit bleibt beim Dateneigentümer. Allerdings bleibt eine rechtliche Frage offen: Wenn der Compute-Layer auf einer nicht-souveränen Infrastruktur läuft und auf lokale Daten zugreift — genügt das den regulatorischen Anforderungen? Zero-Copy ist nicht gleich Zero-Exposure. Das erfordert eine sorgfältige juristische Bewertung.

6. Regulatorischer Rückenwind — und was er konkret bedeutet

Die EU hat seit 2025 einen regulatorischen Rahmen geschaffen, der Souveränität von der Kür zur Pflicht verschiebt:

  • EU Data Act (vollständig anwendbar seit September 2025): Verpflichtet Cloud-Anbieter zu schnellem, kostenlosem Wechsel. Verbietet Lock-in durch proprietäre Schnittstellen. Schreibt Interoperabilität zwischen Datenverarbeitungsdiensten vor.
  • Digital Markets Act: Reguliert Gatekeeper-Plattformen. Verbietet Self-Preferencing, verlangt Datenportabilität.
  • CADA (Cloud and AI Development Act): Definiert vier Souveränitätsstufen. Ziel: Verdreifachung der EU-Rechenzentrums-Kapazität in 5–7 Jahren.
  • European Technological Sovereignty Package (2026): Rahmt Cloud-Infrastruktur explizit als Frage der strategischen Autonomie.

Das bedeutet: Wer heute Technologieentscheidungen trifft, muss regulatorische Anforderungen nicht als zukünftiges Risiko, sondern als gegenwärtige Rahmenbedingung behandeln. Souveränität ist keine optionale Eigenschaft mehr — sie wird zunehmend zur Compliance-Anforderung.

7. Die Geschäftswissens-Schicht im Zeitalter von KI

Hier liegt aus meiner Sicht der strategisch wichtigste Punkt — und derjenige, der in vielen Souveränitätsdebatten fehlt:

Im Zeitalter von KI wird die Schicht, die Geschäftswissen enthält, zum wertvollsten Asset einer Organisation. Semantic Layers, KPI-Definitionen, Trainingsdaten-Pipelines, Prompt-Bibliotheken, Domänenmodelle — das ist das kodierte Wissen, das Wettbewerbsvorteile schafft.

Wenn dieses Wissen in einer proprietären Plattform eingeschlossen ist — egal ob US-amerikanisch oder europäisch — entsteht eine Abhängigkeit, die tiefer geht als Infrastruktur-Lock-in. Der Anbieter kontrolliert nicht nur, wo die Daten liegen, sondern wie das Unternehmen sein eigenes Geschäft versteht und operationalisiert.

Das Prinzip: Die Business-Knowledge-Schicht muss technologieagnostisch bleiben. Das ist theoretisch anspruchsvoll, aber praktisch umsetzbar:

  • Offene Integrationsstandards nutzen, die von mehreren Tools unterstützt werden
  • Geschäftslogik so dokumentieren und implementieren, dass sie unabhängig vom ausführenden System verständlich und portierbar bleibt
  • Bei der Toolwahl explizit prüfen: Kann ich meine Definitionen, Regeln und Modelle exportieren und in einem anderen System weiternutzen?

Es gibt genügend offene Standards und unterstützte Integrationspfade. Die Herausforderung ist nicht technisch unlösbar — sie erfordert Disziplin bei der Architekturentscheidung.

8. Praktische Prinzipien

Aus dem Zusammenspiel von Regulierung, Marktbewertung und Architekturüberlegungen destillieren sich folgende Prinzipien:

  1. Holistisch denken — nicht nur „welcher Cloud-Anbieter?", sondern auch welche APIs, Sprachen und Formate Abhängigkeit schaffen. Souveränität ist eine Entscheidung auf jeder Schicht.

  2. Offene Standards für den kritischen Pfad — alles, was Geschäftslogik, Transformationen und Datenmodelle enthält, muss auf offener Technologie laufen. Wenn der Anbieter verschwindet, muss die Logik migrierbar sein — nicht nur die Daten.

  3. Proprietär nur dort, wo austauschbar — Object Storage mit S3-API-Kompatibilität, Standard-SQL-Datenbanken, VMs. Dienste, die sich wie Commodities verhalten und bei denen ein Wechsel kein Redesign erfordert.

  4. Die Geschäftswissens-Schicht schützen — Semantic Layers, KPI-Definitionen, Domänenmodelle in offenen, portablen Formaten halten. Das ist das strategische Asset.

  5. Exit-Fähigkeit testen, nicht nur dokumentieren — ein theoretischer Exit-Plan genügt nicht. Regelmäßig validieren, ob ein Wechsel technisch und organisatorisch machbar ist.

  6. Ehrlich mit Trade-offs umgehen — europäische Alternativen haben Lücken. Das anzuerkennen ist kein Argument gegen Souveränität, sondern Voraussetzung für realistische Planung.

Digitale Souveränität ist kein abgeschlossenes Projekt mit einer finalen Antwort. Es ist eine kontinuierliche Architekturentscheidung: bewusst offen bleiben, wo es zählt. Bewusst akzeptieren, wo Austauschbarkeit genügt. Und ehrlich sein, wo die europäischen Alternativen heute noch nicht auf Augenhöhe sind — ohne das als Argument zu nutzen, gar nicht erst anzufangen.

Weiterführende Quellen: