Wie sieht Unabhängigkeit im Konkreten aus? Souveränität ist nicht zu kaufen, sondern zu designen

Anbieter zum Thema

Dataiku GmbH

DAXTEN GmbH

VON ZUR MÜHLEN'SCHE GmbH

STACKIT - Schwarz Digits Cloud GmbH & Co. KG

Souveränität wird mittlerweile von vielen Hyperscalern als weitere Produktkategorie vermarktet. Dabei bringt der Begriff aktuell einen strukturellen Widerspruch zum Vorschein: Souveränität ist eine grundsätzliche Voraussetzung für unabhängiges Handeln, und kein Anbieter kann diese grundlegende Unabhängigkeit von den eigenen Produkten oder Dienstleistungen verkaufen.

Der genannte Unterschied prägt damit nicht nur die Beschaffungsebene, sondern ist vor allem auch auf der Ebene der Infrastruktur essentiell, wo architektonische Entscheidungen letztlich darüber entscheiden, wie und ob Unabhängigkeit überhaupt erreichbar ist.

Bevor man sich fragt, ob die eigene Architektur souverän ist, sollte man sich überlegen, worauf es einem eigentlich ankommt. Kurzum: Es gibt keine einheitliche Definition von Souveränität, die auf alle stimmig anwendbar ist. Vielmehr gibt es einzelne Anhaltspunkte, anhand derer man sich an den Kern des Themas im konkreten Fall annähern kann.

Zunächst also erst einmal eine Annäherung über einige an Sicherheit grenzende Wahrscheinlichkeiten.

• Erstens ist Souveränität ziemlich sicher schlicht durch einen Anti-US-Cloud Ansatz zu erreichen. Cloud-Technologie beschleunigt Innovationen und wird erst zum Problem, wenn ein Wechsel zwischen verschiedenen Anbietern zu einer strategischen Krise wird, statt als lediglich technisches Projekt bewerkstelligbar zu sein.

• Zweitens ist es unwahrscheinlich, dass es sich bei Souveränität grundsätzlich um eine rein geographische Thematik handelt, da sich rechtliche Rahmenbedingungen heutzutage überall ständig und stark ändern können.

• Und Drittens lässt sich Souveränität ohnehin nicht auf den Faktor des Datenstandorts reduzieren. Denn wo genau Daten gespeichert werden, liegt weit hinter der Frage, wer genau am Ende die Kontrolle über sie hat.

Dieser letzte Punkt öffnet eine zentrale Perspektive, der sich vor allem Infrastrukturarchitekten stellen sollten: Besitzt und behält die eigene Organisation die Fähigkeit, unter Druck die Daten-Kontrolle zu behalten - auch, wenn gerade nicht alles nach Plan läuft, sondern wenn sich Gesetze ändern, politische Bedingungen wandeln oder eine Lieferantenbeziehung feindselig wird? Eine grundsätzliche Vorbereitung hierzu wird nicht jeden Sonderfall lösen, rückt aber tendenziell wichtigste architektonische Fragen bereits im Vorfeld in den Hauptfokus.

Drei zentrale Blickwinkel für Infrastrukturarchitekten

Die drei Dimensionen übersetzen sich also in diagnostische Perspektiven auf Souveränität: rechtlich, operativ und architektonisch.

Rechtliche Souveränität beleuchtet, welche Gesetze gelten und wer Offenlegungen erzwingen kann. Sie bildet also vor allem den Ausgangspunkt ab, nicht das Ziel.

Operative Souveränität stellt in den Fokus, wer das System betreibt, wer eingreifen kann, und zum Beispiel Fragen dazu, ob Teams mit Sitz in der EU eine Plattform ohne Beteiligung externer Anbieter betreiben und weiterentwickeln können.

Architektonische Souveränität beleuchtet, wie einfach sich Workloads migrieren lassen und wie groß die Abhängigkeit von einzelnen Anbietern und Technologien ist. Während die erste Dimension also in vielen Diskussionen um Souveränität im Zentrum steht, sind die zu bewerkstelligenden Aufgaben um einiges weitreichender.

Was EU-Bewertungen über Prioritäten verrät

Das Cloud Sovereignty Framework der Europäischen Kommission (v1.2.1, Okt. 2025) bewertet die Souveränität von Cloud-Anbietern anhand von acht Faktoren. Am höchsten gewichtet wird dabei die Lieferkettensouveränität (SOV-5) mit 20 Prozent. Diese umfasst sowohl die Herkunft der Hardware, als auch die Zuständigkeit für die Firmware und den Softwarevertrieb.

Die Einhaltung rechtlicher und jurisdiktioneller Vorschriften macht dagegen nur 10 Prozent aus. Die Einordnung der Kommission bewertet also, dass die am schwersten zu erreichenden Dimensionen strategisch am wichtigsten verortet sind. Und bei allen handelt es sich ausnahmslos um Infrastrukturfragen.

Ein Sovereign-First-Konzept: Entkoppelte Architektur

Im EU Framework wird in SOV-6 technologische Souveränität mit 15 Prozent kodifiziert: offene APIs, öffentlich geregelte Standards und Portabilitätsgarantien auf der Orchestrierung-Ebene. Während in der „Lift-and-Shift“-Ära die Cloud-Migration noch als das Endziel betrachtet wurde, ist eine ausgereifte Sichtweise darauf, dass eine zentrale Orchestrierung nötig ist. Diese umfasst On-Premise-, souveräne Cloud- und Hyperscaler-Umgebungen.

Das ist also kein vorübergehender Kompromiss, sondern die bewusste Wahl einer Architektur. Diese Schicht muss unabhängig von Infrastrukturen sein. So können dieselbe Governance-Logik, dieselbe Workflow-Orchestrierung und dieselben KI-Fähigkeiten allumfassend funktionieren, unabhängig davon, wo die Rechenleistung ausgeführt wird.

Die Kosten aufgeschobener Entscheidungen

SOV-1 fokussiert sich auf Absicherungen gegen einen Kontrollwechsel. Was passiert also, wenn der Anbieter übernommen oder sanktioniert wird oder generell aus dem Markt ausscheidet?

Architektonische Unabhängigkeit ist hier die einzige glaubwürdige Antwort. Wenn eine Lock-in-Situation erkannt wird, ist es bereits so spät, dass sie schon strukturell verankert ist: in APIs, Orchestrierungs-Tools, Datenformaten und betrieblichen Abhängigkeiten.

Migrationen in solchen Situationen bedeuten jahrelange Prozesse und Dutzende Millionen Euro. Die Relevanz von Souveränität ist also sowohl finanzieller als auch regulatorischer Natur: Eine Organisation, die über einen Migrationsplan verfügt, der es ermöglicht, Workloads innerhalb von Monaten statt Jahren und ohne erhebliche finanzielle Investitionen (wie die Beauftragung externer Beratungsteams) zu verlagern, agiert aus einer Position echter Stärke.

(ID:50875294)