Cloud-Dienste sind für viele Unternehmen längst Teil der betrieblichen Grundversorgung. Damit verändert sich auch die Bewertung von Abhängigkeiten. Ein Rechenzentrum in Frankfurt oder Amsterdam macht eine Plattform noch nicht souverän. Entscheidend ist, wie viel Kontrolle ein Unternehmen über Daten, Identitäten, Schlüssel, Software und letztlich über seine eigene Betriebsfähigkeit behält.
Die Diskussion um digitale Souveränität wird schnell grundsätzlich. Europäische Anbieter gegen amerikanische Hyperscaler, Open Source gegen proprietäre Software oder eigene Rechenzentren gegen Public Cloud. Für Unternehmen führen solche Gegenüberstellungen allerdings nur begrenzt weiter.
AWS, Microsoft Azure oder Google Cloud bieten eine technologische Breite und Skalierung, die sich intern kaum wirtschaftlich nachbauen lässt. Moderne Datenplattformen, weltweite Netze, Security Services oder KI-Infrastruktur können Projekte erheblich beschleunigen. Es wäre deshalb wenig sinnvoll, Cloud-Nutzung grundsätzlich als Verlust von Souveränität zu betrachten.
Problematisch wird sie dort, wo aus einer technisch sinnvollen Abhängigkeit eine Abhängigkeit ohne belastbare Alternative wird.
Genau das passiert in vielen Unternehmen schleichend.
Ein Rechenzentrum in Europa reicht nicht
Beim Einkauf von Cloud-Diensten wird Souveränität häufig zunächst mit dem Standort der Daten gleichgesetzt. Liegen die Daten innerhalb Deutschlands oder zumindest innerhalb der Europäischen Union, scheint ein wichtiger Teil des Problems gelöst.
Das ist richtig, aber unvollständig.
Der physische Speicherort sagt zunächst nur, wo Daten verarbeitet oder gespeichert werden. Er sagt wenig darüber aus, wer die Plattform kontrolliert, welches Unternehmen administrative Zugriffe ausführen kann, welchem Recht der Betreiber unterliegt, wo Supportpersonal sitzt, wer die kryptografischen Schlüssel kontrolliert oder über welche Systeme Software-Updates ausgeliefert werden.
Besonders sichtbar wird diese Unterscheidung bei US-amerikanischen Cloud-Anbietern. Der US CLOUD Act führt nicht dazu, dass amerikanische Behörden beliebig auf Daten europäischer Kunden zugreifen könnten. Er schafft aber unter bestimmten Voraussetzungen rechtliche Möglichkeiten, US-Anbieter zur Herausgabe von Daten zu verpflichten, auch wenn diese außerhalb der USA gespeichert sind. Europäische Datenschutzbehörden beschäftigen sich deshalb seit Jahren mit möglichen Konflikten zwischen solchen Zugriffsansprüchen und europäischem Datenschutzrecht.[1]
Umgekehrt hat auch Europa reagiert. Der EU Data Act verpflichtet Anbieter von Datenverarbeitungsdiensten unter anderem dazu, technische, organisatorische und rechtliche Maßnahmen gegen bestimmte unzulässige Zugriffe von Drittstaaten auf in der EU gespeicherte nicht personenbezogene Daten zu treffen.[2]
Damit wird deutlich: Datenlokation ist eine Komponente von Souveränität, aber nicht deren Definition.
Die eigentliche Abhängigkeit entsteht eine Ebene höher
Die stärksten Bindungen an einen Cloud-Anbieter entstehen heute häufig gar nicht beim Speicherplatz oder bei virtuellen Maschinen.
Sie entstehen durch Plattformdienste.
Eine Anwendung, die auf virtuellen Servern läuft und ihre Daten in einer weitgehend standardisierten Datenbank hält, lässt sich mit Aufwand auf eine andere Infrastruktur übertragen. Anders sieht es aus, wenn dieselbe Anwendung eng mit proprietären Identity Services, serverlosen Funktionen, Event-Plattformen, Datenbanken, Security-Werkzeugen, KI-APIs und herstellerspezifischen Managementdiensten verbunden ist.
Jeder einzelne dieser Dienste kann technisch sinnvoll sein. Zusammen entsteht jedoch eine Architektur, deren Wechselkosten kontinuierlich steigen.
Der Lock-in steckt dann nicht im Vertrag, sondern im Systemdesign.
Das gilt inzwischen besonders für KI. Unternehmen speichern nicht mehr nur Daten in einer Cloud. Dort entstehen Vektordatenbanken, Embeddings, Modellzugriffe, RAG-Architekturen, Agenten, Governance-Funktionen und ganze Entwicklungsumgebungen. Wer diese Komponenten ausschließlich mit proprietären Diensten eines Anbieters aufbaut, bindet nicht nur Infrastruktur, sondern zunehmend auch Wissen und Geschäftslogik an eine Plattform.
Das muss kein Fehler sein. Ein Lock-in kann wirtschaftlich vernünftig sein, wenn der Nutzen größer ist als das damit verbundene Risiko. Problematisch wird er erst dann, wenn niemand weiß, wie groß diese Abhängigkeit tatsächlich geworden ist.
Multicloud löst das Problem nicht automatisch
Eine häufig genannte Antwort lautet Multicloud. Werden mehrere Anbieter eingesetzt, könne ein Unternehmen bei Problemen einfach ausweichen.
In der Praxis funktioniert das selten so einfach.
Eine Anwendung gleichzeitig für Azure, AWS und Google Cloud vollständig portabel zu halten, kann erhebliche zusätzliche Entwicklungs-, Betriebs- und Testkosten verursachen. Hinzu kommen unterschiedliche Sicherheitsmodelle, IAM-Strukturen, Netzwerkarchitekturen und Betriebswerkzeuge. Wer versucht, jede technische Besonderheit der Anbieter zu vermeiden, verzichtet unter Umständen gerade auf diejenigen Funktionen, wegen derer die Cloud ursprünglich gewählt wurde.
Multicloud ist deshalb nicht automatisch eine Resilienzstrategie.
Sinnvoller ist es, gezielt zu entscheiden, wo Portabilität tatsächlich erforderlich ist.
Für ein zeitkritisches Produktionssystem kann es sinnvoll sein, Datenformate, Deployment und Datenbank so zu gestalten, dass eine Migration möglich bleibt. Bei einem weniger kritischen Collaboration-Dienst kann das Unternehmen dagegen bewusst eine stärkere Herstellerbindung akzeptieren – sofern Datenexport, Notbetrieb und Wiederanlauf geklärt sind.
Souveränität bedeutet damit nicht, jede Komponente jederzeit austauschen zu können. Sie bedeutet, Abhängigkeiten zu kennen und dort Alternativen vorzubereiten, wo ihr Ausfall oder Wegfall das Unternehmen ernsthaft treffen würde.
Europa versucht, Wechselmöglichkeiten regulatorisch zu stärken
Interessant ist, dass sich inzwischen auch die europäische Regulierung stärker mit genau dieser praktischen Seite der Cloud-Abhängigkeit beschäftigt.
Der EU Data Act gilt seit dem 12. September 2025. Sein Kapitel VI enthält konkrete Vorgaben zum Wechsel zwischen Datenverarbeitungsdiensten. Anbieter müssen Hindernisse abbauen, die Kunden am Wechsel zu einem anderen Anbieter oder zurück auf eine eigene Infrastruktur hindern. Verträge müssen entsprechende Wechselmöglichkeiten berücksichtigen und die Übertragung exportierbarer Daten und digitaler Assets regeln.[2]
Ab dem 12. Januar 2027 dürfen Anbieter für den eigentlichen Wechsel keine Wechselentgelte mehr verlangen. Der regulatorische Ansatz ist bemerkenswert: Vendor Lock-in wird damit nicht nur als technisches Architekturproblem betrachtet, sondern ausdrücklich als Wettbewerbs- und Souveränitätsthema.
Dass die Problematik inzwischen auch wettbewerbsrechtlich relevant ist, zeigte die EU-Kommission im Juni 2026. Sie teilte Amazon und Microsoft ihre vorläufige Auffassung mit, dass AWS und Azure wegen ihrer Marktstellung als Gatekeeper unter dem Digital Markets Act eingestuft werden sollten. Als Gründe nennt die Kommission ausdrücklich Lock-in-Effekte, hohe Wechselkosten und die großen Ökosysteme der Anbieter. Die Prüfung ist noch kein endgültiger Beschluss, zeigt aber, wie weit das Thema inzwischen über klassische IT-Architektur hinausgeht.[3]
Noch deutlicher wird die politische Richtung beim im Juni 2026 vorgelegten Vorschlag für den Cloud and AI Development Act (CADA). Die Kommission schlägt darin einen EU-weiten Rahmen zur Bewertung von Cloud- und KI-Souveränität vor. Dieser soll verschiedene Souveränitätsstufen unterscheiden – von der Verarbeitung innerhalb der EU bis zu weitreichenden Anforderungen an Eigentum, Kontrolle und Software-Lieferketten. Wichtig ist dabei der rechtliche Status: CADA ist derzeit ein Gesetzgebungsvorschlag und noch kein geltendes Recht.[4]
Damit bekommt ein bislang vergleichsweise unscharfer Begriff erstmals deutlich konkretere Kriterien.
Souveränität muss in der Architektur sichtbar werden
Für Unternehmen ergibt sich daraus eine sehr praktische Aufgabe. Sie sollten nicht versuchen, einen Anbieter pauschal als „souverän“ oder „nicht souverän“ einzustufen. Relevant ist vielmehr die konkrete Kombination aus Anwendung, Daten, Schutzbedarf und Abhängigkeit.
Am Anfang steht deshalb eine Bestandsaufnahme: Welche geschäftskritischen Prozesse hängen von welchen Cloud-Diensten ab? Dabei reicht es nicht, lediglich „Microsoft“, „AWS“ oder „Google“ in eine Lieferantenliste einzutragen.
Die Abhängigkeit liegt häufig tiefer.
Welche Identitätsplattform authentifiziert die Administratoren? Wo liegen die kryptografischen Schlüssel? Welche SaaS-Anwendung enthält die einzige aktuelle Kopie bestimmter Geschäftsdaten? Von welchem Dienst hängen Backups ab? Welche APIs werden für zentrale Geschäftsprozesse benötigt? Lassen sich Protokolldaten exportieren? Kann auf Daten noch zugegriffen werden, wenn der zentrale Identity Provider nicht verfügbar ist?
Eine solche Betrachtung verändert das Bild erheblich.
Ein Unternehmen kann beispielsweise seine Anwendungen auf mehrere Rechenzentren verteilen und trotzdem einen Single Point of Failure besitzen, wenn sämtliche administrativen Zugriffe über einen einzigen Cloud-Identity-Dienst laufen.
Der Exit gehört bereits in die Beschaffung
Besonders häufig wird über den Ausstieg aus einem Cloud-Dienst erst nachgedacht, wenn er tatsächlich notwendig wird.
Dann ist es zu spät.
Eine belastbare Cloud-Strategie behandelt die Exit-Frage bereits bei Architektur und Beschaffung. Dabei geht es nicht um einen theoretischen Satz im Vertrag, wonach der Anbieter bei Vertragsende Daten bereitstellt. Ein Unternehmen muss wissen, welche Daten tatsächlich exportiert werden können, in welchem Format sie vorliegen, wie lange ein vollständiger Export dauert und welche Funktionen nach einer Migration verloren gehen.
Bei einigen SaaS-Lösungen lassen sich Dokumente problemlos exportieren, während Metadaten, Berechtigungen, Auditinformationen oder Workflow-Logik nur eingeschränkt übertragen werden können. Bei PaaS-Plattformen lässt sich vielleicht die Datenbank migrieren, nicht aber die gesamte umgebende Geschäftslogik.
Ein technisch möglicher Export ist daher noch keine funktionierende Exit-Strategie.
Das BSI greift diesen Gedanken beispielsweise in seinem Mindeststandard zur Nutzung externer Cloud-Dienste auf. Bei Beendigung eines Cloud-Nutzungsverhältnisses sollen Datenrückgabe und Datenlöschung kontrolliert und dokumentiert werden. Der zugrunde liegende Gedanke lässt sich auch außerhalb der Bundesverwaltung sinnvoll übertragen: Der Lebenszyklus einer Cloud-Nutzung endet nicht mit der Vertragsunterschrift, sondern erst mit einer geordneten Ablösung.[5]
Wer die Schlüssel kontrolliert, kontrolliert noch lange nicht alles
Verschlüsselung spielt bei souveränen Cloud-Konzepten zu Recht eine wichtige Rolle. Customer Managed Keys, Bring Your Own Key oder externe Key-Management-Systeme können die Kontrolle des Kunden erheblich erhöhen.
Aber auch hier lohnt ein genauer Blick.
Wenn die Anwendung Daten zur Verarbeitung entschlüsseln muss und der Cloud-Anbieter gleichzeitig wesentliche Teile der Laufzeitumgebung kontrolliert, löst die Kontrolle über den Schlüssel nicht automatisch sämtliche Zugriffsrisiken. Entscheidend ist, an welcher Stelle entschlüsselt wird, wer Zugriff auf die Verarbeitungsebene besitzt und wie Administration und Schlüsselverwaltung voneinander getrennt sind.
Bei besonders sensiblen Anwendungen können deshalb zusätzliche Konzepte wie Confidential Computing oder eine vom Cloud-Anbieter organisatorisch und technisch getrennte Schlüsselverwaltung sinnvoll sein.
Auch hier gilt: Ein einzelnes Sicherheitsmerkmal erzeugt noch keine Souveränität.
Open Source hilft – wenn man es betreiben kann
Ähnliches gilt für Open Source.
Offene Software kann Abhängigkeiten reduzieren, weil Quellcode verfügbar ist, Schnittstellen nachvollziehbarer sind und grundsätzlich die Möglichkeit besteht, Software selbst oder durch einen anderen Dienstleister weiterbetreiben zu lassen.
Doch ein Repository auf GitHub ist noch keine Exit-Strategie.
Wer eine Plattform nach dem Ausfall eines Dienstleisters theoretisch selbst betreiben könnte, dafür aber weder Personal noch Dokumentation noch Infrastruktur besitzt, hat nur eine formale Alternative. Deshalb rückt inzwischen auch die Europäische Union neben der Verfügbarkeit von Open Source stärker dessen nachhaltige Pflege, Governance und Finanzierung in den Mittelpunkt. Die 2026 vorgestellte EU Open Source Strategy verknüpft offene Technologien ausdrücklich mit technologischer Souveränität und der Reduzierung von Abhängigkeiten.[6]
Für Unternehmen ist das ein wichtiger Unterschied: Relevant ist nicht nur, ob eine Technologie offen ist, sondern ob tatsächlich mehrere realistische Betriebs- und Supportoptionen existieren.
Cloud-Souveränität ist auch Business Continuity
Gerade bei geschäftskritischen Cloud-Diensten sollte das Thema deshalb aus der reinen IT-Architektur herausgeholt werden.
Der Ausfall eines Cloud-Anbieters ist nur eines der möglichen Szenarien. Ebenso relevant sind ein Ausfall des Identity Providers, eine größere Fehlkonfiguration, ein kompromittiertes Administratorkonto, der Verlust des Managementzugangs, ein regionales Infrastrukturproblem, eine Unterbrechung wichtiger APIs oder eine Situation, in der ein Dienst aufgrund rechtlicher oder geopolitischer Veränderungen nicht mehr wie bisher genutzt werden kann.
Business Continuity und IT Service Continuity Management sollten solche Abhängigkeiten berücksichtigen.
Dabei muss nicht für jedes denkbare Ereignis eine zweite vollständige Cloud-Umgebung bereitstehen. Häufig reicht eine abgestufte Strategie. Für besonders kritische Funktionen kann echte technische Redundanz notwendig sein. Andere Prozesse benötigen einen zeitlich begrenzten Notbetrieb. Wieder andere können einige Tage stillstehen, wenn anschließend Daten und Systeme zuverlässig wiederhergestellt werden können.
Erst diese Einordnung macht aus einer allgemeinen Forderung nach digitaler Souveränität ein handhabbares Risikomanagement.
Die sinnvollere Frage lautet: Welche Optionen bleiben uns?
Vollständige technologische Unabhängigkeit ist für die meisten Unternehmen weder realistisch noch wirtschaftlich sinnvoll. Selbst ein eigenes Rechenzentrum besteht aus Prozessoren, Betriebssystemen, Netzwerkkomponenten, Softwarebibliotheken und Sicherheitsprodukten internationaler Hersteller.
Souveränität kann deshalb nicht bedeuten, jede Abhängigkeit zu vermeiden.
Sie zeigt sich darin, ob eine Organisation ihre Abhängigkeiten kennt, bewusst eingeht und kritische Entscheidungen weiterhin selbst treffen kann.
Dazu gehört die Wahl des Datenstandorts ebenso wie die Kontrolle von Identitäten und Schlüsseln. Dazu gehören offene Schnittstellen, nachvollziehbare Lieferketten und vertragliche Regelungen. Vor allem gehört dazu aber die Fähigkeit, Daten zurückzuerhalten, Anwendungen zu migrieren und kritische Prozesse weiterzubetreiben, wenn sich technische, wirtschaftliche oder politische Rahmenbedingungen ändern.
Eine Cloud-Architektur ist deshalb nicht schon dann souverän, wenn der Anbieter dieses Wort auf seine Produktseite schreibt.
Sie ist dann belastbar, wenn das Unternehmen auch unter ungünstigen Bedingungen noch reale Handlungsoptionen besitzt.
Quellen und weiterführende Informationen
[1] European Data Protection Board / European Data Protection Supervisor: Stellungnahme zu möglichen Auswirkungen des US CLOUD Act auf den europäischen Datenschutzrahmen.
[2] Verordnung (EU) 2023/2854 – EU Data Act, insbesondere Kapitel VI zum Wechsel zwischen Datenverarbeitungsdiensten, Artikel 29 zu Wechselentgelten sowie Artikel 32 zum Zugriff von Drittstaaten. Der Data Act gilt grundsätzlich seit dem 12. September 2025; Wechselentgelte werden zum 12. Januar 2027 abgeschafft.
[3] Europäische Kommission, 25. Juni 2026: Vorläufige Position zur möglichen Gatekeeper-Einstufung von Amazon AWS und Microsoft Azure unter dem Digital Markets Act.
[4] Europäische Kommission, 3. Juni 2026: Vorschlag für den Cloud and AI Development Act sowie europäisches Technologiesouveränitätspaket. Der vorgeschlagene Rahmen sieht vier Abstufungen für Cloud- und KI-Souveränität vor.
[5] Bundesamt für Sicherheit in der Informationstechnik: Mindeststandard zur Nutzung externer Cloud-Dienste, einschließlich Anforderungen an Beendigung, Datenrückgabe und Datenlöschung; ergänzend Cloud Computing Compliance Criteria Catalogue (C5).
[6] Europäische Kommission: EU Open Source Strategy, veröffentlicht im Rahmen des Technologiesouveränitätspakets am 3. Juni 2026.
[7] Ausgangspunkt und thematischer Impuls: Prof. Dr. Iris Lorscheid, „Kritische Infrastruktur Cloud: Warum jetzt Souveränität zählt“, Security-Insider, 5. Oktober 2026.
