Vermeintliche Wahrheiten rund um digitale Souveränität im FaktencheckZusammenspiel von Daten, Technologie, Betrieb und Governance entscheidet

Digitale Souveränität ist für Unternehmen eine strategische Frage: Wer kontrolliert Daten, Technologien und Betriebsmodelle? Und wie schnell kann eine Organisation handeln, wenn sich die Rahmenbedingungen ändern? Gleichzeitig kursieren rund um das Thema zahlreiche Vereinfachungen. Daher ist es sinnvoll, verbreitete Annahmen unter die Lupe zu nehmen und zu zeigen, worauf es bei digitaler Souveränität technisch tatsächlich ankommt.
Laut einer Untersuchung von Red Hat hat digitale Souveränität für 80 Prozent der befragten IT-Verantwortlichen in Deutschland höchste Priorität. Doch nicht alles, was rund um das Thema im Umlauf ist, stimmt.

Annahme 1 „Digitale Souveränität bedeutet: Die gesamte IT muss im eigenen Rechenzentrum laufen.“ Dazu liefert der folgende Faktencheck die Antwort „Falsch“.

Digitale Souveränität ist keine Frage des Besitzes von Hardware, sondern der Handlungsfähigkeit. Ein Unternehmen muss selbst entscheiden können, wo ein Workload betrieben wird, welche Daten wohin fließen, wer darauf zugreifen darf und wie sich eine Anwendung bei veränderten Anforderungen auf eine andere Infrastruktur verlagern lässt. Damit kann auch eine Cloud Teil einer souveränen IT-Architektur sein.

Entscheidend sind unter anderem Portabilität, Interoperabilität, standardisierte Schnittstellen und die Möglichkeit, Betriebsmodelle zu wechseln. Eine hybride Architektur kann beispielsweise sensible Workloads auf eigener oder speziell abgesicherter Infrastruktur betreiben, während weniger kritische Anwendungen skalierbare Cloud-Ressourcen nutzen. Die Systeme sollten möglichst wenig von proprietären Diensten einer einzelnen Plattform abhängig sein.

Container, Kubernetes-basierte Plattformen und offene APIs können dabei helfen, Workloads zwischen unterschiedlichen Umgebungen beweglich zu halten. Souveränität bedeutet also nicht „alles selbst zu betreiben“, sondern eine Alternative zu haben. Wer jederzeit wechseln kann, hat eine andere Verhandlungsposition als ein Unternehmen, dessen Anwendungen, Datenformate und Betriebsprozesse untrennbar an einen Anbieter gekoppelt sind.

Annahme 2 „Unsere Daten liegen in Deutschland – also sind sie souverän.“ Dazu liefert der Faktencheck: Datenresidenz allein reicht nicht.

Wo Daten gespeichert werden, ist zwar relevant, aber nur ein Teil der Gleichung. Ebenso entscheidend sind die Fragen, wer auf die Daten zugreifen kann, wer die Schlüssel kontrolliert, welche Software sie verarbeitet und wer den Betrieb administriert.

Ein Rechenzentrum kann physisch in Deutschland stehen, während die eingesetzte Software, zentrale Managementsysteme oder Supportstrukturen von einem ausländischen Anbieter kontrolliert werden. Damit ist die tatsächliche Zugriffskontrolle noch nicht geklärt.

Souveräne Datenverarbeitung erfordert deshalb ein mehrschichtiges Sicherheitsmodell. Dazu gehören etwa Identity and Access Management, konsequente Privilegienkontrolle, Auditierbarkeit und Verschlüsselung. Relevant sind dabei alle drei Zustände von Daten: Data at Rest, Data in Transit und Data in Use.

Für den Schutz während der Verarbeitung können beispielsweise Technologien wie Confidential Computing eingesetzt werden. Auch das Schlüsselmanagement ist entscheidend: Wer die kryptografischen Schlüssel kontrolliert, verfügt über eine wesentlich stärkere technische Kontrolle als ein Unternehmen, das diese vollständig an einen externen Dienstleister delegiert.

Annahme 3 „Open Source ist ein Sicherheitsrisiko.“ Dazu liefert der Faktencheck als Antwort: Open Source ist weder automatisch sicher noch unsicher.

Der entscheidende Unterschied liegt in der Kontroll- und Überprüfbarkeit. Bei quelloffener Software kann der Code grundsätzlich unabhängig analysiert, auf Schwachstellen untersucht und an die eigenen Anforderungen angepasst werden. Das reduziert insbesondere die Abhängigkeit davon, was ein einzelner Hersteller über Funktionsweise und Weiterentwicklung seiner Software offenlegt.

Für digitale Souveränität ist zudem die Substituierbarkeit wichtig. Wenn eine Anwendung auf offenen Standards und dokumentierten Schnittstellen basiert, lässt sich eine einzelne Komponente eher austauschen, ohne die gesamte Architektur neu aufbauen zu müssen. Das ist gerade bei kritischen Plattformen relevant.

Proprietäre Abhängigkeiten können beispielsweise entstehen, wenn Datenformate, APIs oder Managementfunktionen nicht portierbar sind. Open Source kann hier eine Grundlage schaffen, auf der unterschiedliche Anbieter Dienstleistungen erbringen können. Allerdings ist Quelloffenheit kein Freifahrtschein. Unternehmen müssen auch bei Open-Source-Software Lieferketten, Abhängigkeiten, Patch-Prozesse und Governance kontrollieren.
Annahme 4 „Cloud und digitale Souveränität schließen sich aus.“ Der Faktencheck zeigt: Das Problem ist nicht die Cloud, sondern fehlende Kontrolle.

Cloud Computing kann bestehende Abhängigkeiten verstärken, muss es aber nicht. Ausschlaggebend ist, wie Anwendungen und Daten an die jeweilige Umgebung gekoppelt sind. Eine Lösung, die beispielsweise zentrale proprietäre Datenbanken, Storage-Dienste, Identitätsmechanismen und spezifische Cloud-APIs nutzt, lässt sich nur mit erheblichem Aufwand migrieren. Die technische Abhängigkeit wird damit zur strategischen Abhängigkeit.

Anders sieht es bei einer Architektur aus, die containerisiert, API-basiert und auf offenen Standards aufgebaut ist. Sie kann Workloads grundsätzlich in unterschiedlichen Umgebungen betreiben – vom eigenen Rechenzentrum über einen lokalen Provider bis hin zur Public Cloud. Es geht nicht darum, jede Anwendung jederzeit verschieben zu können. Eine solche Fähigkeit zur „Cloud-Flucht“ wäre wirtschaftlich und technisch oft nicht sinnvoll. Entscheidend ist vielmehr, kritische Abhängigkeiten bewusst zu kennen und Wechselmöglichkeiten für relevante Workloads vorzusehen.

Für KI-Anwendungen gewinnt diese Frage zusätzlich an Bedeutung. Training, Inferenz und Datenverarbeitung stellen unterschiedliche Anforderungen an Rechenleistung, Kosten, Latenz und Datenschutz. Eine souveräne Architektur kann deshalb beispielsweise skalierbare Ressourcen für bestimmte Trainingsaufgaben nutzen und sensible Inferenz-Workloads in einer kontrollierten Umgebung betreiben.

Annahme 5 „Souveräne KI setzt die Entwicklung eines eigenen Sprachmodells voraus.“ Dazu die klare Antwort aus dem Faktencheck: Der Neubau eines Foundation Model ist nicht erforderlich.

Ein eigenes Large Language Model (LLM) von Grund auf zu trainieren, ist für die meisten Unternehmen weder technisch noch wirtschaftlich sinnvoll. Für souveräne KI ist es entscheidender, wer Modell, Daten, Inferenz und Betrieb kontrolliert. Unternehmen können beispielsweise Open-Weight-Modelle mit offenen Gewichten einsetzen und diese in einer eigenen oder kontrollierten Infrastruktur betreiben.

Dadurch lässt sich die Inferenz so gestalten, dass sensible Prompts und Unternehmensdaten nicht an eine externe Modell-API übertragen werden müssen. Auch die Spezialisierung eines bestehenden Modells kann wesentlich effizienter sein als ein komplettes Neutraining. Je nach Anwendungsfall kommen dafür unter anderem Retrieval-Augmented Generation, Fine-Tuning, synthetische Daten oder kontrollierte Wissenseinspeisung infrage.
Auf der Infrastrukturseite geht es wiederum um mehr als nur das Modell. Komponenten für Model Serving und Inference – etwa vLLM oder llm-d – können dazu beitragen, Modelle effizient und skalierbar in der eigenen Umgebung bereitzustellen.

Annahme 6: „Digitale Souveränität kann man einfach einkaufen.“ Doch dazu meint der Faktencheck: Technologie allein macht noch keine souveräne Organisation.

Selbst die souveränste Plattform ist nutzlos, wenn niemand weiß, welche Abhängigkeiten in der eigenen IT bestehen. Digitale Souveränität ist deshalb auch eine Frage der Architekturkompetenz und Governance.

Unternehmen müssen zunächst Transparenz schaffen: Welche Anwendungen und Dienste werden eingesetzt? Wo werden Daten gespeichert und verarbeitet? Welche externen Abhängigkeiten bestehen? Welche Komponenten sind geschäftskritisch? Wie schnell lässt sich ein Anbieter wechseln – und welche Daten, Schnittstellen oder Skills wären dafür erforderlich?

Daraus folgt eine zentrale Anforderung an die IT-Architektur: Die Exit-Fähigkeit muss bereits bei der Planung berücksichtigt werden. Dazu gehören dokumentierte Schnittstellen, portable Datenformate, reproduzierbare Deployments, getestete Backup- und Recovery-Verfahren sowie Know-how im eigenen Unternehmen. Das bedeutet nicht, dass proprietäre Technologien grundsätzlich ausgeschlossen werden müssen.
E

in Unternehmen kann sich bewusst für eine solche Lösung entscheiden, wenn deren Vorteile die entstehenden Abhängigkeiten rechtfertigen. Souverän ist diese Entscheidung aber erst dann, wenn die Konsequenzen bekannt sind und Alternativen zumindest bewertet wurden.

Souverän ist nicht, wer alles selbst macht

Digitale Souveränität lässt sich nicht auf einen Rechenzentrumsstandort, eine Cloud-Strategie oder den Einsatz von Open Source reduzieren. Sie entsteht aus dem Zusammenspiel von Daten, Technologie, Betrieb und Governance.

Entscheidend ist dabei die Fähigkeit eines Unternehmens, Kontrolle und Handlungsfreiheit auch dann zu bewahren, wenn sich ein Anbieter, regulatorische Anforderungen, die Bedrohungslage oder die eigenen Geschäftsanforderungen verändern. Dazu gehören Transparenz über technologische Abhängigkeiten, belastbare Alternativen und die technische Fähigkeit, diese bei Bedarf auch umzusetzen.

Gregor von Jagow ist Senior Director und Country Manager Deutschland bei Red Hat.

Red Hat