Eigene Server, deutsche Rechenzentren, offene Software: Für sich genommen macht keiner dieser Bausteine eine IT souverän. Entscheidend ist, ob Unternehmen ihre Daten kontrollieren, Abhängigkeiten kennen und bei Bedarf auf Alternativen wechseln können. Der Faktencheck ordnet sechs verbreitete Irrtümer ein – und zeigt, welche Fragen CIOs bei Cloud, KI und IT-Governance stellen sollten.

Management Summary

Handlungsfreiheit statt Standortdebatte. Der Artikel beschreibt digitale Souveränität als Kontrolle über Daten, Technologien und Betrieb. Für CIOs steht damit die Frage im Mittelpunkt, welche Alternativen bei veränderten Anforderungen tatsächlich verfügbar sind.
Cloud-Sicherheit braucht eigene Prüfung. Der BSI-Kriterienkatalog C5 schafft eine Grundlage zur Bewertung von Cloud-Diensten. Der Prüfbericht ersetzt jedoch nicht das Risikomanagement des Kunden: Geltungsbereich, Ergebnisse und eigene Verantwortlichkeiten gehören auf die Prüfliste. [2]
Wechselrechte brauchen technische Umsetzung. Der seit 12. September 2025 anwendbare EU Data Act adressiert auch den Wechsel zwischen Cloud-Anbietern. Für die IT-Planung empfiehlt sich, vertragliche Wechselmöglichkeiten mit erprobten Datenexporten und Migrationsverfahren zu verbinden. [3]
Bei KI die Offenheit präzise prüfen. Verfügbare Modellgewichte allein erfüllen nicht die Open Source AI Definition der Open Source Initiative. Relevant sind auch Nutzungsrechte, Code und Informationen über Trainingsdaten. [4]
Souveränität als Führungsaufgabe behandeln. In einer von Red Hat veröffentlichten Befragung von 2026 gaben 57 Prozent der 100 deutschen Teilnehmer eine definierte KI-Exit-Strategie an. Die Anbieterbefragung liefert einen Anlass, die eigene Wechselbereitschaft zu prüfen; sie beschreibt nicht pauschal alle deutschen Unternehmen. [6]

Illustration Absmeier foto ki designer

Kontrolle im Zentrum, Alternativen in der Architektur: Die Illustration verbindet Rechenzentrum, Cloud und KI mit modularen Komponenten und Governance. KI-generierte Illustration.

Sechs vermeintliche Wahrheiten rund um digitale Souveränität im Faktencheck

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. Gregor von Jagow, Senior Director und Country Manager Deutschland bei Red Hat, nimmt sechs verbreitete Annahmen unter die Lupe und zeigt, 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.

1. »Digitale Souveränität bedeutet: Die gesamte IT muss im eigenen Rechenzentrum laufen.«

Faktencheck: 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.

2. »Unsere Daten liegen in Deutschland – also sind sie souverän.«

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.

3. »Open Source ist ein Sicherheitsrisiko.«

Faktencheck: 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.

4. »Cloud und digitale Souveränität schließen sich aus.«

Faktencheck: 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.

5. »Souveräne KI setzt die Entwicklung eines eigenen Sprachmodells voraus.«

Faktencheck: Der Neubau eines Foundation Model ist nicht erforderlich.

Ein eigenes Large Language Model 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.

6. »Digitale Souveränität kann man einfach einkaufen.«

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. Ein 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.

Fazit: 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, Senior Director und Country Manager Deutschland bei Red Hat (Quelle: Red Hat)

Praxistipps: Digitale Souveränität umsetzen

Die folgenden Tipps sind redaktionelle Handlungsempfehlungen auf Basis des Artikels und der ergänzenden Quellen. Sie ersetzen keine individuelle Architektur-, Sicherheits- oder Rechtsprüfung.

Infografik: Die sieben Praxistipps zur digitalen Souveränität im vollständigen Wortlaut. KI-generierte Infografik; Quellenbezugszeichen entsprechen dem Quellenverzeichnis.

Ausführliche Tipps mit Praxisbeispielen

Die folgenden Umsetzungsvorschläge vertiefen die sieben vorhandenen Tipps. Sämtliche Praxisbeispiele sind fiktive Szenarien, keine dokumentierten Unternehmensfälle. Genannte Vorgehensweisen und Abnahmekriterien sind redaktionelle Empfehlungen und an den jeweiligen Schutzbedarf anzupassen. Tests sollten in einer freigegebenen, vom Produktivbetrieb getrennten Umgebung mit synthetischen oder dafür freigegebenen Daten stattfinden.

1. Kritische Geschäftsprozesse kartieren – nicht nur Systeme inventarisieren

Umsetzung: Beginnen Sie mit einem klar abgegrenzten Geschäftsprozess, etwa Auftragseingang oder Ersatzteilversorgung. Erfassen Sie gemeinsam mit Fachbereich und IT die beteiligten Anwendungen, Datenbestände, Schnittstellen, Identitätsdienste und externen Betreiber. Dokumentieren Sie zusätzlich, wer Verträge, Konfigurationen und Betriebswissen besitzt. Fragen Sie nicht nur, ob sich eine Anwendung verschieben lässt, sondern welche Voraussetzungen für einen funktionsfähigen Gesamtprozess erforderlich sind. Lassen Sie den Fachbereich die tolerierbare Unterbrechung und den tolerierbaren Datenverlust festlegen; diese Zielwerte dürfen nicht aus allgemeinen Richtwerten übernommen werden.

Fiktives Praxisbeispiel: Ein Maschinenbauunternehmen untersucht seinen Ersatzteilvertrieb. Im Abhängigkeitsregister werden neben dem ERP auch ein Kundenportal, ein externer Identitätsdienst und eine proprietäre Versand-Schnittstelle erfasst. Das Projektteam plant deshalb nicht nur einen ERP-Datenexport, sondern auch die Übernahme von Kundenkennungen und den Test einer alternativen Versand-Anbindung. Der Fachbereich beschreibt, welche Bestellungen im Störungsfall über einen freigegebenen Ersatzprozess bearbeitet werden sollen.

Arbeitsergebnis und Prüfkriterium: Erstellen Sie eine Prozesskarte mit Abhängigkeiten, Verantwortlichen, Wiederanlaufzielen und offenen Fragen. Lassen Sie Fachbereich und IT bestätigen, dass alle für den gewählten Prozess erforderlichen Dienste berücksichtigt wurden. Noch ungeklärte Abhängigkeiten bleiben ausdrücklich als offen markiert.

2. Exit-Fähigkeit durch einen vollständigen Probelauf nachweisen

Umsetzung: Definieren Sie vor dem Test, welche Funktionen im Zielbetrieb verfügbar sein müssen. Zum Testpaket gehören nicht nur Nutzdaten, sondern auch Metadaten, Berechtigungszuordnungen, Konfigurationen und erforderliche Integrationen. Halten Sie fest, welche Bestandteile exportierbar sind und welche manuell nachgebildet werden müssen. Führen Sie anschließend einen dokumentierten Import in eine alternative Testumgebung durch. Prüfen Sie dort repräsentative Geschäftsvorgänge und vergleichen Sie Datenbestand und Ergebnisse mit der Ausgangsumgebung. Trennen Sie vertragliche Wechselmöglichkeiten von der technischen Testbewertung; knüpfen Sie die Vertragsprüfung an die im Artikel genannten Cloud-Wechselregeln an. [3]

Fiktives Praxisbeispiel: Ein Großhändler plant einen Anbieterwechsel für sein Serviceportal. In einer Testmigration werden synthetische Tickets samt Anhängen, Zeitstempeln und Statushistorie übertragen. Das Team nimmt Benutzerzuordnungen und die Schnittstelle zur Auftragsverwaltung in die Abnahme auf. Für nicht übertragbare Automatisierungsregeln dokumentiert es einen Ersatz im Zielsystem. Eine Produktivumstellung wird erst zur Entscheidung vorgelegt, wenn die vereinbarten Testfälle und das Rückfallverfahren geprüft sind.

Arbeitsergebnis und Prüfkriterium: Legen Sie ein Migrationsprotokoll mit Exportumfang, importierten Bestandteilen, Abweichungen, benötigter Arbeitszeit und gemessener Testdauer vor. Bewerten Sie die Abnahme gegen vorab festgelegte Kriterien. Ein erfolgreicher Einzeltest ist kein Nachweis dafür, dass sämtliche Anwendungen oder künftigen Versionen ebenso portierbar sind.

3. Anbieterprüfungen in eine eigene Maßnahmenliste übersetzen

Umsetzung: Ordnen Sie den angeforderten C5-Prüfbericht dem tatsächlich bezogenen Dienst und dessen Leistungsumfang zu. Gehen Sie Systembeschreibung, Prüfzeitraum, Feststellungen und Kundenverantwortlichkeiten gemeinsam mit Informationssicherheit und Betrieb durch. Übertragen Sie die für Ihr Nutzungsszenario relevanten Punkte in eine Maßnahmenliste: Wer muss etwas konfigurieren, welchen Nachweis benötigen Sie und bis wann soll die Aufgabe erledigt sein? Nutzen Sie die vorhandene Quelle [2] als fachlichen Ausgangspunkt. Formulieren Sie offene Fragen an den Anbieter konkret, statt allein eine allgemeine Bestätigung zur Sicherheit anzufordern.

Fiktives Praxisbeispiel: Ein Logistikunternehmen prüft den Bericht für einen Cloud-Dienst zur Dokumentenablage. Das Team nimmt die im Beispielszenario vom Kunden zu betreuenden Zugriffsrollen und Protokollauswertungen in seine Maßnahmenliste auf. Der Cloud-Betrieb dokumentiert die Rollenkonfiguration; die Informationssicherheit legt fest, welche Ereignisse ausgewertet werden sollen. Unklare Angaben zum gebuchten Dienstumfang werden vor einer Freigabe mit dem Anbieter geklärt.

Arbeitsergebnis und Prüfkriterium: Führen Sie eine nachvollziehbare Zuordnung zwischen Bericht, Nutzungsszenario, eigener Kontrollmaßnahme und Nachweis. Markieren Sie erledigte, offene und bewusst akzeptierte Punkte getrennt. Ein Bericht für einen anderen Dienst oder einen nicht abgedeckten Leistungsumfang bleibt eine Nachweislücke.

4. Zugriffsrechte, Schlüssel und Wiederherstellung gemeinsam prüfen

Umsetzung: Erstellen Sie eine Rollenübersicht für Datenzugriff, Berechtigungsverwaltung, Schlüsselverwaltung und Wiederherstellung. Beziehen Sie technische Konten, Supportwege und Notfallverfahren ein. Prüfen Sie anhand der konkreten Architektur, welche Zugriffe durch welche Kontrollen beschränkt werden und welche Zugriffe weiterhin möglich bleiben. Schlüsselhoheit und administrativer Zugriff sollten getrennt dokumentiert werden. Testen Sie in einer isolierten Umgebung, ob eine autorisierte Wiederherstellung mit den vorgesehenen Schlüsseln und Freigaben funktioniert. Ändern oder löschen Sie für einen Test keine produktiven Schlüssel.

Fiktives Praxisbeispiel: Ein Entwicklungsdienstleister legt für ein Projektarchiv getrennte Rollen für Betrieb und Schlüsselverwaltung fest. Im Test wird ein synthetisches Archivbackup in einer isolierten Umgebung wiederhergestellt. Das Team dokumentiert, welche Freigaben dafür erforderlich sind und welche Protokolle entstehen. Die Sicherheitsprüfung bewertet zusätzlich die Support- und Administrationswege; die getrennte Schlüsselrolle wird nicht als pauschaler Beleg für vollständige Zugriffskontrolle behandelt.

Arbeitsergebnis und Prüfkriterium: Dokumentieren Sie eine Rollen- und Zugriffsmatrix sowie ein geprüftes Wiederherstellungsprotokoll. Jeder vorgesehene Notfallzugriff benötigt einen benannten Freigabeweg, eine Protokollierung und einen Verantwortlichen. Nicht geprüfte Zugriffspfade bleiben als solche ausgewiesen.

5. Lieferkettenanforderungen vor der Beschaffung festlegen

Umsetzung: Ergänzen Sie die fachlichen Anforderungen um Fragen zu Komponentenherkunft, Versionspflege, Sicherheitsmeldungen und Update-Verfahren. Lassen Sie den Anbieter beschreiben, wie er Schwachstellen bewertet und Kunden über relevante Änderungen informiert. Fordern Sie, soweit für die Beschaffung angemessen, eine Komponentenübersicht mit Versionen und Zuständigkeiten an. Vereinbaren Sie intern, wer Meldungen bewertet, Updates in der Testumgebung prüft und die Freigabe verantwortet. Nutzen Sie das im Quellenverzeichnis geführte NIST SSDF als Bezugsrahmen für das Gespräch, nicht als pauschalen Sicherheitsnachweis eines Produkts. [5]

Fiktives Praxisbeispiel: Ein Handelsunternehmen beschafft eine Plattform für sein Kundenportal. Der Einkauf fordert gemeinsam mit der IT eine Komponentenübersicht und eine Beschreibung des Melde- und Update-Prozesses an. Für eine beispielhafte Sicherheitsmeldung spielt das Team den Ablauf durch: Eingang, technische Bewertung, Test eines Updates und dokumentierte Freigabe. Dabei wird auch festgelegt, wie mit einer Komponente ohne zugesicherte weitere Pflege umzugehen wäre.

Arbeitsergebnis und Prüfkriterium: Halten Sie Anforderungen, gelieferte Auskünfte und offene Nachweise in einem Beschaffungsprotokoll fest. Prüfen Sie an einem vereinbarten Beispielszenario, ob Meldeweg und interne Zuständigkeiten nachvollziehbar sind. Eine Komponentenliste allein ist noch kein Nachweis eines funktionierenden Pflegeprozesses.

6. KI-Modelle anhand von Rechten und Betriebsanforderungen vergleichen

Umsetzung: Erstellen Sie für jedes Kandidatenmodell einen Steckbrief: genaue Version, veröffentlichte Gewichte, Lizenzbedingungen, verfügbarer Code, Informationen über Trainingsdaten und vorgesehener Einsatz. Lassen Sie die Rechte für Nutzung und Anpassung prüfen und vergleichen Sie die veröffentlichten Bestandteile mit der im Artikel genannten OSI-Definition. [4] Dokumentieren Sie getrennt davon den geplanten Betrieb: Rechenressourcen, Datenquellen, Schnittstellen, Protokollierung, Updates und Verantwortliche. Legen Sie für den Pilotversuch synthetische Testfälle und fachliche Abnahmekriterien fest. Die Einstufung der Lizenz beantwortet nicht automatisch die Frage nach der Eignung für den konkreten Geschäftsprozess.

Fiktives Praxisbeispiel: Ein Unternehmen plant einen internen Assistenten zur Suche in technischen Handbüchern. Für zwei Kandidaten werden Modellversion, Rechte und Betriebsanforderungen gegenübergestellt. Der Pilot nutzt synthetische Dokumente und Fragen; das Team prüft die angezeigten Fundstellen sowie vorsätzlich eingebautes fehlendes Wissen. Fachliche Prüfer bewerten die Ergebnisse anhand der vorab festgelegten Kriterien. Das Szenario beschreibt einen geplanten Test, keinen belegten Leistungsnachweis eines Modells.

Arbeitsergebnis und Prüfkriterium: Legen Sie einen Modellsteckbrief, eine Rechteprüfung, eine dokumentierte Datenflussübersicht und ein fachliches Testprotokoll vor. Entscheiden Sie getrennt über rechtliche Nutzbarkeit, Betriebsfreigabe und fachliche Eignung. Fehlende Informationen werden nicht durch die Bezeichnung »offen« ersetzt.

7. Souveränität mit Nachweisen und Entscheidungen steuern

Umsetzung: Definieren Sie wenige Kennzahlen mit klarer Bezugsgröße. Unterscheiden Sie beispielsweise zwischen dokumentierten Abhängigkeiten, vertraglich vorgesehenen Wechselmöglichkeiten und tatsächlich getesteten Migrationen. Notieren Sie für jeden Nachweis Testumfang, Datum, Version und offene Abweichungen. Verbinden Sie die Berichterstattung mit einer Entscheidung: Welche Nachweislücke soll als Nächstes bearbeitet werden, wer verantwortet sie und welche Ressourcen sind vorgesehen? Vermeiden Sie einen zusammengefassten Souveränitätsscore, wenn dessen Gewichtung nicht transparent und für den Einsatzzweck begründet ist.

Fiktives Praxisbeispiel: Die IT-Leitung eines mittelständischen Unternehmens berichtet über die für seinen Ersatzteilprozess festgelegten kritischen Anwendungen. Das Dashboard weist je Anwendung aus, ob eine aktuelle Abhängigkeitskarte, ein geprüfter Export und ein dokumentierter Wiederanlauftest vorliegen. Für das Portal ist ein Export vorhanden, der alternative Betrieb aber noch ungeprüft. Dieser Unterschied bleibt sichtbar; das Management entscheidet über einen gezielten Migrationstest statt über eine pauschale Freigabe sämtlicher Systeme.

Arbeitsergebnis und Prüfkriterium: Führen Sie ein Dashboard mit eindeutigen Definitionen und verlinkten beziehungsweise zugeordneten internen Nachweisen. Ergänzen Sie ein Entscheidungsprotokoll mit Verantwortlichen und Prüfterminen. Ein grüner Status darf nur den dokumentierten Prüfumfang bezeichnen, nicht eine ungeprüfte Gesamtarchitektur.

FAQ: Zehn Fragen zur digitalen Souveränität

1. Was bedeutet digitale Souveränität für Unternehmen konkret?

Im Verständnis des Artikels bedeutet sie, über Daten, Technologien und Betriebsmodelle selbstbestimmt entscheiden zu können. Dafür müssen Unternehmen ihre Abhängigkeiten kennen und relevante Alternativen bewerten. Als praktische Prüffragen bieten sich an: Wer kann auf unsere Daten zugreifen? Welche Komponenten können wir austauschen? Und lässt sich ein kritischer Dienst unter vertretbaren Bedingungen an anderer Stelle weiterbetreiben? Vollständige Autarkie ist dabei nicht das Ziel.

2. Warum reicht ein Rechenzentrum in Deutschland nicht aus?

Der Artikel unterscheidet zwischen dem physischen Speicherort und der Kontrolle über Verarbeitung und Betrieb. Zur Standortfrage kommen deshalb Administrationsrechte, Supportwege, Schlüsselmanagement und die eingesetzte Software hinzu. Für die Bewertung eines Cloud-Dienstes empfiehlt sich außerdem die Prüfung der dokumentierten Sicherheitsmaßnahmen und Kundenverantwortlichkeiten. Der C5-Prüfbericht liefert hierfür eine Grundlage, ersetzt aber keine eigene Risikoanalyse. [2]

3. Ist eine Cloud-Strategie mit digitaler Souveränität vereinbar?

Der Artikel bejaht dies, sofern Kontrolle und relevante Wechselmöglichkeiten berücksichtigt werden. Eine sinnvolle Entscheidungsgrundlage ist eine Bewertung pro Workload: Schutzbedarf, Leistungsanforderungen, Kosten, Schnittstellen und Wechselaufwand gehören zusammen. Ergänzend bietet C5 eine strukturierte Grundlage zur Sicherheitsbewertung. Redaktionelle Empfehlung: Wählen Sie das Betriebsmodell anhand dieser Anforderungen und nicht allein anhand des Etiketts »souveräne Cloud«. [2]

4. Was ändert der EU Data Act beim Cloud-Anbieterwechsel?

Der Data Act ist seit dem 12. September 2025 anwendbar und enthält Regelungen, die den Wechsel zwischen Cloud-Anbietern und die Übertragung von Daten erleichtern sollen. Die Europäische Kommission beschreibt Cloud-Switching ausdrücklich als einen Bestandteil der Verordnung. Für Unternehmen empfiehlt sich deshalb, Exportmöglichkeiten, Wechselunterstützung und die einschlägigen Vertragsbedingungen zu prüfen. Welche Pflichten im konkreten Vertragsfall greifen, sollte individuell rechtlich bewertet werden. [3]

5. Woran lässt sich eine belastbare Exit-Strategie erkennen?

Als redaktionelle Prüfkriterien empfehlen sich ein benannter Zielbetrieb, dokumentierte Exportformate, verfügbare Konfigurationen, klare Verantwortlichkeiten und ein praktischer Migrationstest. Ein Vertragsrecht zum Wechsel ist dabei von der tatsächlich getesteten technischen Fähigkeit zu unterscheiden. Die Red-Hat-Befragung von April 2026 liefert einen Vergleichspunkt: 57 Prozent der 100 deutschen IT-Entscheider gaben eine definierte Exit-Strategie für ihren primären KI-Anbieter an. Die Zahl erfasst Selbstauskünfte in einer Anbieterbefragung, keinen unabhängigen Nachweis erfolgreicher Migrationen. [6]

6. Macht Open Source eine Software automatisch sicher?

Der Artikel verneint einen solchen Automatismus. Quelloffenheit und ein geregelter Sicherheitsprozess sind unterschiedliche Eigenschaften. Das NIST Secure Software Development Framework beschreibt Praktiken für sichere Softwareentwicklung und den Umgang mit Schwachstellen; es bietet auch eine gemeinsame Sprache für Beschaffungsgespräche. Redaktionelle Empfehlung: Prüfen Sie bei offenen wie proprietären Komponenten Pflegezustand, Update-Verfahren, Zuständigkeiten und die Behandlung von Sicherheitsmeldungen. [5]

7. Sind Open-Weight-Modelle dasselbe wie Open-Source-KI?

Nein, nicht nach der Open Source AI Definition 1.0 der Open Source Initiative. Diese verlangt Freiheiten zur Nutzung, Untersuchung, Veränderung und Weitergabe sowie die dafür erforderliche Form zur Modifikation. Dazu zählen neben Parametern auch Code und hinreichend detaillierte Informationen über die Trainingsdaten. Redaktionelle Empfehlung: Bewerten Sie die veröffentlichten Bestandteile und die konkreten Lizenzbedingungen einzeln, statt die Bezeichnung »offen« ungeprüft zu übernehmen. [4]

8. Müssen Unternehmen für souveräne KI ein eigenes Modell entwickeln?

Der Artikel setzt souveräne KI nicht mit dem vollständigen Neutraining eines eigenen Foundation Model gleich. Er stellt stattdessen die Kontrolle über Modell, Daten und Betrieb in den Mittelpunkt. Als redaktionelle Entscheidungsgrundlage empfiehlt sich eine Prüfung von Lizenzrechten, Infrastruktur, Datenzugriffen, Betriebsverantwortung und Wechseloptionen. Die OSI-Definition hilft dabei, die Offenheit der bereitgestellten Bestandteile präzise einzuordnen; sie ist kein Nachweis für die Souveränität der gesamten Unternehmensarchitektur. [4]

9. Was sagt ein C5-Testat aus – und was nicht?

C5 beschreibt Mindestanforderungen an die Informationssicherheit von Cloud-Diensten. Die Prüfung durch Wirtschaftsprüfer mündet in einen Bericht mit dokumentierten Prüfhandlungen und einer Systembeschreibung. Abhängig vom Prüfungstyp wird auch die Erfüllung der Anforderungen über einen vergangenen Zeitraum untersucht. Das BSI betont, dass Kunden den Bericht für ihre eigene Risikoanalyse auswerten sollen. Für eine Souveränitätsbewertung empfiehlt sich zusätzlich die Prüfung von Wechselmöglichkeiten und konkreten Daten- und Betriebskontrollen. [2]

10. Wie kann das Management digitale Souveränität messbar machen?

Als interne Steuerungsgrößen empfehlen sich dokumentierte Abhängigkeiten, getestete Export- und Wiederanlaufverfahren, gemessener Wechselaufwand und regelmäßig ausgewertete Anbieterprüfberichte. Ergänzen Sie jede Kennzahl um Zuständigkeit, Prüftermin und den Bezug zum Geschäftsprozess. Das sind redaktionelle Vorschläge für ein unternehmensspezifisches Kennzahlensystem, kein universeller Souveränitätsscore. Für die laufende Cloud-Sicherheitsbewertung empfiehlt das BSI, C5-Prüfberichte initial und danach jährlich anzufordern und auszuwerten. [2]

Quellen

[1] https://www.redhat.com/de/about/press-releases/Studie-Red-Hat-Deutsche-Unternehmen-streben-nach-digitaler-Souveraenitaet

[2] Bundesamt für Sicherheit in der Informationstechnik: Kriterienkatalog C5. https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html

[3] Europäische Kommission: Data Act. https://digital-strategy.ec.europa.eu/en/policies/data-act

[4] Open Source Initiative: The Open Source AI Definition – 1.0. https://opensource.org/ai/open-source-ai-definition

[5] NIST: Secure Software Development Framework (SSDF), Version 1.1, SP 800-218, Februar 2022. https://csrc.nist.gov/pubs/sp/800/218/final

[6] Red Hat: Studie zur Abhängigkeit deutscher Unternehmen von globalen KI-Anbietern, 21. April 2026; Anbieterquelle, jeweils 100 befragte IT-Entscheider in Deutschland, Frankreich, dem Vereinigten Königreich, Italien und den Niederlanden. https://www.redhat.com/de/about/press-releases/studie-von-red-hat-zeigt-abhaengigkeit-deutscher-unternehmen-von-globalen-ki-anbietern

Recherche-Stand der ergänzenden Quellen: 3. November 2026. Die bestehende Quelle [1] bleibt dem Originalartikel zugeordnet. Handlungsempfehlungen sind als redaktionelle Empfehlungen formuliert; Befragungsergebnisse werden der jeweiligen Anbieterquelle zugeschrieben.

Management Summary, Tipps, FAQ und Bilder wurden mit Hilfe von KI erstellt

1736 Artikel zu „Souveränität“

IT-Security | News | Trends 2026 | Trends Security

it-sa 2026: Souveränität, KI und Governance prägen die Cybersecurity-Agenda

28. Oktober 2026

Digitale Souveränität, KI-gestützte Cyberabwehr und nachvollziehbare Compliance: Die hier zusammengefassten Meldungen zur it-sa 2026 verbinden technische Produktneuheiten mit Fragen der operativen Kontrolle. Anbieter stellen souveräne Cloud- und Netzwerkmodelle, agentenbasierte Security Operations sowie Plattformen für sensiblen Datenaustausch und Nachweisführung vor. Für CIOs und Geschäftsleitungen rücken damit neben der Schutzwirkung auch Betreiberverantwortung, Berechtigungen und die Handlungsfähigkeit im…