Seit Monaten scrolle ich durch LinkedIn und sehe überall denselben Begriff: Datensouveränität. Jeder zweite Post, jede Pressemitteilung, jedes Whitepaper. Der Begriff ist zum Marketinginstrument verkommen – und das ist ein Problem.
Denn die meisten, die ihn benutzen, meinen eigentlich etwas ganz anderes.
Sie meinen Datenhoheit.
Datenhoheit beschreibt die rechtliche und physische Verfügungsgewalt über Daten. Es geht um Kontrolle und die Entscheidung, wer Zugriff bekommt. Das ist eine technische und juristische Frage.
Datensouveränität geht weiter. Der Begriff verspricht die technische und organisatorische Fähigkeit, jederzeit und uneingeschränkt selbstbestimmt über die eigenen Daten zu verfügen. Das klingt nach absoluter Kontrolle. Nach Unabhängigkeit. Nach Freiheit.
Und genau deshalb wird er so inflationär benutzt.
Souveränität klingt mächtiger, politischer. Es suggeriert absolute Kontrolle und Unabhängigkeit – das ist emotional viel stärker als der nüchterne Begriff Datenhoheit. Wenn einem Kunden "Datensouveränität" angeboten wird, klingt das nach Schutz vor den amerikanischen Tech-Giganten. Ein perfektes Marketing-Narrativ.
Datenhoheit hingegen klingt technisch, trocken, nach Paragrafen und Verträgen.
Aber genau das ist es ja auch – eine rechtliche und technische Frage der Verfügungsgewalt. Kein Wunder, dass der Begriff Souveränität sich durchsetzt. Er verkauft sich einfach besser.
Ich habe mehrere Fälle gesehen, wo dieses Missverständnis richtig teuer wurde.
Ein mittelständisches Unternehmen hat vor zwei Jahren seinen gesamten Cloud-Stack zu einem deutschen Anbieter migriert. Der Anbieter warb mit "100% Datensouveränität". Keine US-Shareholder, Server in Deutschland, alles schön verpackt.
Nach einem Jahr wollten sie zusätzliche Features implementieren. Der Anbieter konnte sie nicht liefern.
Dann kam der Schock: Die Migration zurück oder zu einem anderen Anbieter war extrem komplex und teuer. Sie waren in proprietäre Systeme eingesperrt. Vendor Lock-in vom Feinsten.
Von Souveränität keine Spur – sie waren abhängiger als vorher bei AWS.
Das Ironische: Sie hatten Datenhoheit. Aber sie konnten nicht frei darüber verfügen. Genau das Gegenteil von dem, was Souveränität verspricht.
Am Ende haben sie viel Geld in die Migration gesteckt und standen schlechter da als zuvor. Vendor Lock-in kann sich schnell addieren: Migration des Systems, Schulungen, Berater, rechtliche Überprüfung, temporärer Produktivitätsverlust. Je länger eine Cloud-Infrastruktur genutzt wird, desto schwieriger ist der Wechsel.
Hier wird es technisch – aber das ist der Kern des Problems.
Viele lokale "Souveränitäts"-Anbieter sind technologisch oft noch klassische Hoster. Es ist fast schon unfair, sie direkt mit AWS oder Azure zu vergleichen.
Warum war AWS in dem Fall oben weniger problematisch? Wegen der Automatisierbarkeit.
Ein Hyperscaler bietet extrem ausgereifte APIs. Wer Infrastruktur agnostisch bauen will, nutzt Infrastructure-as-Code – wie Pulumi oder Terraform – und steuert Deployments per GitOps. Mit Kubernetes als Abstraktionslayer lassen sich Container-Workloads standardisiert betreiben. Ingress oder HTTPRoute provisionieren den Load Balancer bei AWS komplett automatisiert.
Bei kleineren, vermeintlich souveränen Providern fehlen diese sauberen Schnittstellen oft.
Das führt dazu, dass Unternehmen anfangen, unsaubere Workarounds und eigene Skripte zu bauen, um die fehlende Flexibilität auszugleichen. Und genau dieser Custom-Code ist der schlimmste Vendor Lock-in, den man sich vorstellen kann.
Bei AWS hätte das Unternehmen die Chance gehabt, sich durch Standard-Tools und Kubernetes sauber vom Provider zu entkoppeln.
Die Postleitzahl des Rechenzentrums ersetzt keine Architektur.
Es gibt zwei Hauptgründe für diesen Fehlschluss: Geopolitische Risiko-Aversion und falsches Architektur-Verständnis.
Die Lage – gerade mit der erneuten Präsidentschaft von Trump in den USA – macht Unternehmen völlig zu Recht nervös. Solche Risiken müssen bewertet werden. Das führt in den Chefetagen aber oft dazu, dass die Souveränitäts-Debatte primär von der Rechtsabteilung geführt wird.
Man sieht einen europäischen Standort, hakt das Thema Compliance ab und denkt, man sei nun "souverän".
Und genau hier passiert der zweite Fehler, der technische.
US-Hyperscaler wie AWS bieten unglaubliche API-Tiefe und Flexibilität. Wer sich davon lösen will, braucht europäische Anbieter, die technologisch auf Augenhöhe agieren und auf Open-Source-Standards setzen.
STACKIT ist da beispielsweise ein interessanter Player, weil sie Cloud-Native und Kubernetes in den Mittelpunkt stellen. Das ist der richtige Ansatz – allerdings hört man aktuell auch, dass sie von ihrem eigenen Erfolg etwas überfordert sind. Lieferfähigkeit ist eben auch wichtig.
Wenn Kunden aber zu klassischen Hostern gehen, die diese standardisierten APIs nicht bieten, fangen sie an, sich mit eigenen Skripten und unsauberen Workarounds die fehlende Flexibilität selbst nachzubauen.
Am Ende kaufen sich diese Unternehmen aus Angst vor politischer Abhängigkeit eine technologische Abhängigkeit durch Custom-Code ein.
Kurzfristig profitieren vor allem die europäischen Anbieter. Sie nutzen die politische Verunsicherung als starkes Marketinginstrument.
Aber ich glaube, dass ihnen genau das auf Dauer auf die Füße fallen wird.
Denn wenn das politische Versprechen zwar gut klingt, die Anbieter operativ aber hinterherhinken und manche Kunden wegen fehlender Kapazitäten oder API-Features gar nicht richtig bedienen können, schadet das massiv dem eigenen Image.
Die Zahlen sprechen eine klare Sprache: Europäische Cloud-Anbieter konnten ihren Umsatz zwar verdreifachen, ihr Marktanteil fiel jedoch von 29% auf 15%. Amazon, Microsoft und Google dominieren das europäische Cloud-Geschäft mit einem Anteil von 70 Prozent.
Die aktuelle Diskussion über digitale Souveränität scheint die Aufteilung des Marktes nicht zu verändern.
Es würde den europäischen Anbietern enorm guttun, diese Debatte selbst aktiv auf die Architektur-Ebene zu lenken. Sie sollten aufhören, sich nur über ihren Standort zu definieren, und sich stattdessen als erstklassiges, ergänzendes Toolset präsentieren.
Ein guter Handwerker fragt schließlich auch nicht nach der Nationalität seines Werkzeugs, sondern nimmt genau das mit, das den Job am besten und sichersten erledigt.
Die Politik spielt eine zentrale Rolle, aber oft aus den falschen Motiven heraus.
Gaia-X ist dafür das perfekte Beispiel – eine Initiative, die mit großen Versprechen gestartet ist und dann in bürokratischen Strukturen und Interessenskonflikten versandet ist. Frank Karlitschek, CEO von Nextcloud, erklärte im Februar 2025, dass Gaia-X "tot" sei. Vom ursprünglichen Ziel, eine europäische Cloud-Alternative zu den amerikanischen Hyperscalern aufzustellen, sei heute nicht mehr die Rede.
Die Politik will digitale Souveränität als Antwort auf geopolitische Abhängigkeiten, aber sie versteht oft nicht die technischen Realitäten.
Das Problem: Politiker denken in Legislaturperioden und in sichtbaren Projekten. Ein Rechenzentrum in Deutschland zu fördern, das lässt sich gut verkaufen. "Wir haben jetzt eine europäische Cloud" – das ist eine Schlagzeile.
Aber Kubernetes-Kompetenz aufbauen, Open-Source-Standards fördern, Entwickler ausbilden – das ist unsexy, dauert Jahre und lässt sich schwer in eine Pressemitteilung packen.
Hinzu kommt, dass die Politik oft von Lobbyisten beraten wird, die natürlich ihre eigenen Interessen verfolgen. Große europäische IT-Dienstleister haben ein massives Interesse daran, dass öffentliche Gelder in Cloud-Infrastruktur fließen. Die Souveränitäts-Rhetorik ist da das perfekte Vehikel.
Man kann Fördergelder rechtfertigen, Protektionismus betreiben und gleichzeitig so tun, als würde man europäische Werte verteidigen.
Was wir stattdessen bräuchten, wäre eine Politik, die technologische Unabhängigkeit durch Bildung, Standards und echte Interoperabilität fördert. Aber das ist komplizierter zu vermitteln als "deutsche Server für deutsche Daten".
Wer gerade einen Wechsel zu einem "souveränen" Anbieter erwägt, sollte die Nationalität vergessen und sich drei strategische Fragen stellen:
Nummer eins: Was ist unser eigentliches Ziel?
Geht es um ein echtes juristisches Hindernis, für das zwingend eine europäische Cloud benötigt wird? Wenn ja – für wie viel Prozent der Daten gilt das wirklich?
Nummer zwei: Was ist unsere Exit-Strategie?
Auch mit der Geschäftsführung oder den Ausfallzeiten eines deutschen Anbieters kann man unzufrieden sein. Bei einem Wechsel sollte sichergestellt werden, dass Workloads wieder abgezogen werden können, ohne Monate in Refactoring zu stecken.
Nummer drei: Was braucht unser Produkt technologisch, um wettbewerbsfähig zu bleiben?
Es gibt bei den Cloud-Features einen massiven Gap. Dieser Rückstand lässt sich nicht kurzfristig wegdiskutieren. Wer sich aus rein ideologischen Gründen von US-Technologie abschneidet, riskiert schlechtere Produkte zu bauen.
Am Ende wandern Marktanteile zum nächsten US-Startup ab – nur weil aus Prinzip nicht mit amerikanischen Hyperscalern gearbeitet werden wollte.
Das ist keine Souveränität. Das ist geschäftlicher Suizid.
Wahre Souveränität bedeutet nicht, dass dein Server in Frankfurt steht.
Wahre Souveränität bedeutet: Ein starker Provider – gerne aus Europa, wenn das Use-Case und Compliance fordern – kombiniert mit einer strikt Cloud-agnostischen Architektur, die über Kubernetes und Infrastructure-as-Code abstrahiert ist.
Die europäische Cloud-Debatte ist nicht grundsätzlich falsch. Wir brauchen sie aus einem ganz pragmatischen Grund: Wettbewerb. Wenn wir nur drei amerikanische Hyperscaler haben, die den Markt dominieren, dann haben wir ein Oligopol-Problem. Europäische Anbieter wie STACKIT oder OVHcloud sorgen für mehr Wettbewerb, für Innovation und auch für Preisdruck.
Aber die Souveränitäts-Diskussion lenkt von der Kernfrage ab.
Die wirkliche Frage lautet: Wie lassen sich Systeme so bauen, dass keine Abhängigkeit entsteht? Wie wird sichergestellt, dass ein Provider-Wechsel jederzeit möglich ist?
Die Souveränitäts-Debatte gibt Unternehmen ein falsches Sicherheitsgefühl. Sie denken: "Wir haben jetzt einen deutschen Anbieter, Problem gelöst." Dabei wurde nur das geopolitische Risiko gegen ein technisches Risiko getauscht.
Die eigentliche Arbeit – eine saubere, portable Architektur zu bauen – wird nicht gemacht.
Das ist gefährlich, weil es Ressourcen und Aufmerksamkeit bindet, die für die echten Herausforderungen gebraucht werden: Kubernetes-Kompetenz aufbauen, Infrastructure-as-Code etablieren, Multi-Cloud-Strategien entwickeln.
Es gibt auch gute Nachrichten. Die EU reguliert jetzt echte Wechselfähigkeit – unabhängig von der Nationalität des Anbieters.
Ab Januar 2027 dürfen Anbieter nur noch Kosten in Rechnung stellen, die tatsächlich beim Datenabzug entstehen. Ab 12. Januar 2027 entfallen alle Gebühren für Daten- und Asset-Migration vollständig. Ab dem 12. September 2025 dürfen Anbieter ihren Kunden höchstens zwei Monate Kündigungsfrist auferlegen. Der eigentliche Wechsel zu einem anderen Anbieter muss in der Regel innerhalb von 30 Tagen abgeschlossen sein.
Das ist der richtige Ansatz. Nicht die Nationalität regulieren, sondern die Wechselfähigkeit.
Der Begriff Datensouveränität ist zum Marketinginstrument verkommen. Er verspricht absolute Kontrolle und liefert neue Abhängigkeiten. Er lenkt von den echten Fragen ab und bindet Ressourcen, die für die wirklichen Herausforderungen gebraucht werden.
Wenn das nächste Mal jemand von Datensouveränität spricht, lohnt sich die Nachfrage: Was genau ist gemeint? Geht es um Datenhoheit – also rechtliche Kontrolle? Oder geht es um technische Unabhängigkeit durch saubere Architektur?
Meistens wirst du feststellen: Die Person meint Datenhoheit, sagt aber Souveränität, weil es sich besser anhört.
Und genau da liegt das Problem.