Digitale Souveränität: was souveräne Cloud und Datensouveränität konkret bedeuten

Digitale Souveränität ist zum Pflichtbegriff in jedem Vorstandsdeck geworden, und damit zur Worthülse. In der Praxis reduzieren ihn die meisten Unternehmen auf eine einzige Frage: Steht der Server in der EU? Das ist die einfachste Schicht und längst nicht die wichtigste. Dieser Artikel zerlegt den Begriff in seine operativen Bestandteile und zeigt, was ein DACH-Unternehmen tatsächlich kontrollieren muss, und was nicht.

Souveränität ist nicht eine Eigenschaft, sondern drei

Wer von digitaler Souveränität spricht, meint in Wahrheit drei verschiedene Dinge, die in der Diskussion ständig durcheinandergeworfen werden. Es lohnt sich, sie sauber zu trennen, weil jede Schicht andere Maßnahmen erfordert.

• Datensouveränität: Die Kontrolle darüber, wo Daten liegen, wer rechtlich Zugriff erzwingen kann und unter welcher Jurisdiktion sie stehen. Das ist die Schicht, die fast jeder meint.
• Betriebssouveränität: Die Kontrolle über den laufenden Betrieb. Wer administriert die Plattform, wer kann Patches einspielen, wer kann den Dienst abschalten oder Konfigurationen ändern. Eine in der EU gehostete Plattform, die ausschließlich von einem außereuropäischen Team fernadministriert wird, ist datensouverän, aber nicht betriebssouverän.
• Technologiesouveränität: Die Fähigkeit, den Anbieter zu wechseln, ohne das System neu zu bauen. Das ist die Frage nach Vendor Lock-in, offenen Standards und einer realen Exit-Strategie.

Ein einzelnes Häkchen bei "EU-Rechenzentrum" adressiert nur die erste Schicht, und auch die nur halb. Die teuren Probleme entstehen meist auf den anderen beiden.

US CLOUD Act und DSGVO: warum der Standort nicht genügt

Der häufigste Denkfehler lautet: Wenn die Daten physisch in Frankfurt oder Zürich liegen, sind sie europäischem Recht unterstellt. Das ist nicht richtig.

Der US CLOUD Act von 2018 verpflichtet US-Unternehmen, Daten an US-Behörden herauszugeben, unabhängig davon, wo diese Daten physisch gespeichert sind. Entscheidend ist nicht der Standort des Servers, sondern die Jurisdiktion über die juristische Person, die ihn betreibt. Eine deutsche Tochter eines US-Konzerns oder eine EU-Region eines US-Hyperscalers unterliegt damit potenziell dem Zugriff, auch wenn kein einziges Byte den europäischen Boden verlässt.

Auf der anderen Seite steht die DSGVO mit ihren Anforderungen an Rechtsgrundlage, Zweckbindung und insbesondere an Datentransfers in Drittländer. Das EU-US Data Privacy Framework von 2023 sollte hier Rechtssicherheit schaffen, steht aber wie seine beiden Vorgänger (Safe Harbor und Privacy Shield, beide vom EuGH gekippt) unter rechtlichem Dauerbeschuss. Sich auf seinen Bestand über die gesamte Laufzeit eines Architekturentscheids zu verlassen, ist eine Wette, keine Grundlage.

Für die Praxis heißt das: Die relevante Frage ist nicht "Wo liegen die Daten?", sondern "Wer kann mit rechtlichem Zwang darauf zugreifen, und welcher Jurisdiktion untersteht dieser Akteur?". Erst diese Frage trennt echte Datensouveränität von einer Region auf einer Landkarte.

Was eine EU-Region leistet und was nicht

Eine EU-Region eines Hyperscalers ist nicht wertlos. Sie reduziert Latenz, erfüllt Datenresidenz-Klauseln in vielen Verträgen und vereinfacht die DSGVO-Argumentation in den unkritischen Fällen. Für anonyme Telemetrie, interne Analytics ohne Personenbezug oder unkritische Workloads ist sie völlig ausreichend, und alles andere wäre überengineert.

Was sie nicht leistet: Sie hebt die Jurisdiktion des Betreibers nicht auf. Sie gibt keine Kontrolle über das Administrationsteam. Und sie sagt nichts über die Wechselfähigkeit aus. Ein Unternehmen, das seine gesamte Datenplattform auf proprietäre Dienste eines einzelnen Anbieters aufbaut, ist auch in einer EU-Region tief im Vendor Lock-in, selbst wenn die DSGVO-Frage geklärt scheint.

Die ehrliche Einordnung lautet also: Die EU-Region löst das Residenz-Problem und einen Teil des Compliance-Problems. Sie löst weder das Jurisdiktions-Problem noch das Lock-in-Problem. Wer diese drei Ebenen vermischt, kauft sich ein falsches Sicherheitsgefühl.

Souveräne Cloud: das Versprechen und das Kleingedruckte

Als Antwort auf genau diese Lücke ist eine Kategorie souveräner Cloud-Angebote entstanden. Sie zerfällt grob in drei Modelle, mit jeweils eigenen Stärken und Schwächen.

• Europäische Anbieter: Provider mit europäischer Eigentümerstruktur und europäischer Jurisdiktion. Sie schließen das CLOUD-Act-Problem an der Wurzel, hinken aber bei der Tiefe der Managed Services, besonders im ML- und Daten-Ökosystem, den großen Hyperscalern noch hinterher.
• Souveräne Joint Ventures: Konstruktionen, bei denen ein US-Technologieanbieter die Plattform liefert, ein europäischer Partner aber Betrieb und Zugriffskontrolle hält (etwa nach dem Muster von Bleu in Frankreich oder Delos in Deutschland). Sie bieten mehr Service-Tiefe, das genaue Maß an Souveränität hängt aber stark von der Vertragskonstruktion ab. Hier lohnt sich der Blick ins Kleingedruckte: Wer kann administrieren, wer kann eskalieren, wer hält die Schlüssel.
• Private Cloud oder On-Premise: Maximale Kontrolle über alle drei Schichten, dafür der höchste Betriebsaufwand und die Notwendigkeit, Kompetenz im eigenen Haus aufzubauen.

Wichtig ist eine nüchterne Wahrheit: Souveräne Cloud löst primär die Jurisdiktions- und Betriebsfrage. Sie löst das Lock-in-Problem nicht automatisch. Man kann sich auch in eine souveräne Plattform genauso einbetonieren wie in einen Hyperscaler. Technologiesouveränität ist eine separate Anstrengung.

Open Source und Exit-Strategie gegen Vendor Lock-in

Die dritte Schicht, Technologiesouveränität, entscheidet sich nicht über den Anbieter, sondern über die Architektur. Der Hebel ist die Frage: Wie aufwendig wäre es, diesen Workload zu einem anderen Anbieter zu verschieben?

Konkret bedeutet das einige bewusste Entscheidungen:

• Offene Standards und Formate. Daten in offenen Tabellenformaten und über portable Schnittstellen statt in proprietären Diensten zu halten, kostet anfangs etwas Bequemlichkeit und zahlt sich beim Wechsel um ein Vielfaches aus.
• Open-Source-Komponenten an den kritischen Stellen. Eine Software, deren Lizenz und Code man kontrolliert, kann niemand einseitig abschalten oder umpreisen. Das ist kein ideologisches Bekenntnis, sondern Risikomanagement.
• Eine getestete Exit-Strategie. Eine Exit-Klausel im Vertrag ist wertlos, wenn niemand je geprüft hat, ob die Migration in der Praxis funktioniert. Datenexport, Re-Deployment und Cutover gehören mindestens einmal durchgespielt, bevor man sie im Ernstfall braucht.

Vendor Lock-in ist selten eine bewusste Entscheidung. Es ist die Summe vieler bequemer Einzelentscheidungen, die jede für sich vernünftig aussah. Souveränität auf dieser Ebene heißt, diese Summe im Blick zu behalten.

Eine pragmatische Roadmap für DACH-Unternehmen

Der teuerste Fehler ist, Souveränität als Alles-oder-nichts zu behandeln und die gesamte IT pauschal migrieren zu wollen. Das ist weder finanzierbar noch nötig. Der pragmatische Weg ist eine Klassifizierung.

1. Datenflüsse klassifizieren. Welche Workloads verarbeiten personenbezogene Daten, besondere Kategorien nach Art. 9 DSGVO, Geschäftsgeheimnisse oder regulierte Prozesse? Und welche verarbeiten anonyme oder unkritische Daten? Diese Trennung ist die Grundlage jeder vernünftigen Entscheidung.
2. Vertragliche Pflichten prüfen. Viele B2B-Verträge enthalten inzwischen Klauseln zur ausschließlichen Verarbeitung in der EU. Es lohnt sich, sie zu lesen, bevor ein US-Dienst eine davon still verletzt.
3. Souverän nur, wo es zählt. Die wirklich sensiblen Workloads gehören auf souveräne Infrastruktur, mit Kontrolle über alle drei Schichten. Der große, unkritische Rest darf bequem und kostenoptimiert auf einer Hyperscaler-Region bleiben.
4. Exit-Fähigkeit von Anfang an einbauen. Neue Systeme so zu bauen, dass ein Wechsel möglich bleibt, kostet zur Bauzeit wenig und ist später kaum nachrüstbar.
5. Inkrementell migrieren. Mit dem Workload beginnen, der das höchste Risiko bei vertretbarem Aufwand trägt. Wer auf den großen Stichtag wartet, migriert am Ende unter Zeitdruck schlecht.

Diese Reihenfolge sorgt dafür, dass Aufwand und Risiko zueinanderpassen. Digitale Souveränität wird so von einer abstrakten Forderung zu einer Liste konkreter, priorisierter Entscheidungen.

Souveränitätsstrategie besprechen

DNA Solutions hilft Unternehmen im DACH-Raum, digitale Souveränität von der Folie in die Architektur zu übersetzen: Datenflüsse klassifizieren, die wenigen wirklich sensiblen Workloads identifizieren und Plattformen so bauen, dass Datensouveränität, Betriebskontrolle und eine getestete Exit-Strategie zusammenkommen. Wenn Sie zwischen EU-Region, souveräner Cloud und einem pragmatischen Mischmodell abwägen: Sprechen Sie uns an.