Wie die EU-Kommission mit neuen Richtlinien Cloud-Herkunft und Souveränität in kritischen IT-Architekturen sichert

Warum Herkunft und Souveränität jetzt Architekturrisiken sind

Wenn Cloud-Abhängigkeiten politisch werden, kippt ein technisches Detail schnell in ein Architekturproblem. Die Europäische Kommission prüft laut Dossier Vergeltungsmaßnahmen, darunter auch digitale Dienste, als Reaktion auf drohende US-Zölle [1]. Für Enterprise-Architekten ist das kein Randthema. Wer zentrale Workloads auf Plattformen mit unklarer Herkunft oder einseitiger Betreiberkontrolle aufbaut, kalkuliert mit Preisrisiken, regulatorischen Eingriffen und eingeschränkter Verfügbarkeit.

Die Marktstruktur verschärft das Problem. US-Anbieter kontrollieren 65 bis 72 Prozent der europäischen Cloud-Kapazitäten [1]. Zusätzlich stellen sie 85 Prozent der GPU-Kapazitäten für KI-Anwendungen bereit [1]. Das ist für Architekturen mit Analytics-, ML- oder Automatisierungslast relevant, weil sich damit nicht nur Compute, sondern auch die Skalierungsfähigkeit an wenige Anbieter bindet.

Die EU-Vorgaben zur Cloud-Herkunft zielen deshalb auf mehr als Compliance-Sprache. Sie sollen kontrollierbar machen, wo Infrastruktur, Betreiber und kritische Leistungen tatsächlich verankert sind. Für Architekturteams heißt das: Lieferkette, Rechtsraum, technische Betriebsverantwortung und Exit-Pfade müssen gemeinsam betrachtet werden. Einzelne Zertifikate reichen nicht, wenn Subdienstleister, Plattformkomponenten oder Managed Services außerhalb des gewünschten Kontrollrahmens liegen.

Besonders kritisch wird es bei drei Punkten: erstens bei der Lieferkette, weil die Abhängigkeit oft unterhalb der Oberfläche in Plattformdiensten, Control Planes oder Hardware-Bausteinen steckt. Zweitens bei der Kontrolle, weil Governance ohne echte Eingriffsrechte im Störfall nur auf dem Papier existiert. Drittens bei den Exit-Pfaden, weil ein Wechsel ohne portable Daten, offene Schnittstellen und dokumentierte Betriebsparameter teuer oder praktisch unmöglich wird.

Genau an dieser Stelle setzt das EU Cloud Sovereignty Framework an. Es macht Herkunft und Souveränität zu prüfbaren Kriterien für Architekturentscheidungen [2]. Für IT-Entscheider ist das der Wechsel von einer Vertrauensannahme zu einer belastbaren Bewertungslogik.

Was das EU Cloud Sovereignty Framework wirklich verlangt

Wenn Sie Souveränität nur als politische Leitlinie lesen, bleibt sie für die Architektur zu weich. Das EU Cloud Sovereignty Framework der Kommission übersetzt das Thema laut Dossier in messbare Ziele für Cloud-Strategie, Governance und Umsetzung [2]. Genau daraus entsteht der praktische Nutzen: Architekturteams können Anforderungen nicht mehr nur diskutieren, sondern als Zielbild gegen Betriebsmodell, Datenflüsse und Kontrollrechte prüfen.

Für regulierte Umgebungen reicht ein „EU-gehostet“ nicht aus. Das Framework nennt Souveränitätsanforderungen wie EU Only, Schlüsselhoheit und dedizierte Betreiberkontrollen [2]. Technisch heißt das: Herkunft, Schlüsselverwaltung und Eingriffsrechte müssen getrennt bewertet werden. Ein Anbieter kann Daten in Europa speichern und trotzdem über Betriebszugriffe, Supportpfade oder Schlüsselverwaltung außerhalb Ihres gewünschten Kontrollrahmens liegen. Genau diese Trennung entscheidet darüber, ob eine Architektur auditierbar bleibt oder nur compliant wirkt.

Herkunfts- und Rechtsraumvorgaben der EU technisch abbilden

Rechtsraumkontrollen gehören in die Architektur, nicht in den Einkaufsprozess. Das Dossier verweist bei der Bestandsaufnahme explizit auf Rechtsraum und Betreiberkontrollen sowie auf Exit-Potenzial, Lock-in-Risiken und Portabilität [2]. Wer diese Punkte früh modelliert, sieht schneller, ob ein Dienst unter EU-Recht läuft, ob Subdienstleister beteiligt sind und ob operative Eingriffe außerhalb des gewünschten Rahmens stattfinden.

EU-Only-Modelle sind deshalb mehr als ein Standortlabel. Sie müssen auch die Lieferkette berücksichtigen. Das Framework adressiert laut Taylor Wessing ausdrücklich die IT-Lieferkette für kritische Infrastrukturen [3]. Für Architekturentscheidungen heißt das: Prüfen Sie nicht nur den Hyperscaler, sondern auch Control Plane, Managed Services, Supportstrukturen und eingebundene Drittparteien. Sonst entsteht ein Souveränitätsprofil mit Lücken, die im Audit erst spät sichtbar werden.

Souveränitätszielbilder in regulierten Branchen

Das Dossier nennt regulierte Unternehmen ausdrücklich, darunter Finanz- sowie Gesundheitsbranche, und beschreibt Zielbilder auf Basis der Ist-Analyse und der Souveränitätsziele des Cloud Sovereignty Frameworks der EU-Kommission [2]. Für diese Branchen geht es nicht nur um Verfügbarkeit. Entscheidend sind Compliance, offene Standards, Multi-Cloud-Orchestrierung und klar definierte Mindestanforderungen an Funktionen [2]. Auch die neuen regulatorischen Anforderungen für KI und Cloud im Gesundheitswesen zeigen, wie stark Architektur, Datenschutz und Compliance inzwischen zusammenspielen.

In der Praxis unterscheiden sich die Zielbilder je nach Schutzbedarf. Ein Finanzinstitut priorisiert oft Schlüsselhoheit, Auditierbarkeit und Eingriffsrechte bei kritischen Workloads. Eine Klinik oder ein Gesundheitsdienstleister legt zusätzlich Gewicht auf Datenflüsse, Betreiberkontrolle und Portabilität, wenn Systeme zwischen Betriebsmodellen wechseln müssen. Beide Fälle verlangen dasselbe Muster: Das Zielbild muss technische, funktionale und regulatorische Anforderungen in einer Architektur zusammenführen [2].

Für die Bewertung hilft eine einfache Leitfrage: Kann der Betrieb nachweisen, wo Daten liegen, wer Schlüssel kontrolliert und wer im Ernstfall handeln darf? Wenn eine dieser Antworten fehlt, ist das Zielbild noch nicht tragfähig. Genau dort entstehen später Verzögerungen bei Audit, Migration oder Exit.

Bestandsaufnahme: Wie Sie Souveränitätslücken systematisch sichtbar machen

Wenn Sie Souveränität nur über Provider-Namen diskutieren, bleibt der eigentliche Risikoraum unsichtbar. Das Dossier empfiehlt deshalb zuerst eine Bestandsaufnahme der aktuellen Cloud-Nutzung, um eine Transparenzmatrix der Ist-Nutzung und erste Souveränitätslücken zu erhalten [2]. Für Architekturteams ist das der Punkt, an dem aus einer politischen Zielsetzung ein belastbarer Technik- und Governance-Plan wird.

Die Bestandsaufnahme muss mehr erfassen als Verträge und Lizenzmodelle. Laut Dossier gehören Cloud-Inventar, kritische Funktionen und Daten, Datenflüsse, Abhängigkeiten, Rechtsraum und Betreiberkontrollen sowie Exit-Potenzial und Lock-in-Risiken in dieselbe Analyse [2]. Wer diese Ebenen getrennt betrachtet, übersieht oft genau die Kopplung, die später Audit, Migration oder Störfallbetrieb blockiert.

Transparenzmatrix: Die sechs Pflichtdimensionen

Die Transparenzmatrix sollte sechs Pflichtdimensionen abbilden: Inventar, Datenflüsse, Abhängigkeiten, Rechtsraum, Exit-Pfad und Bedrohungen [2]. Im Inventar stehen nicht nur die Workloads, sondern auch die Dienste, Plattformen und Managed Services, die daran hängen. Bei den Datenflüssen zählen Herkunft, Verarbeitungsort und Zielsysteme. Abhängigkeiten zeigen, welche technischen Komponenten und Betreiberrollen den Betrieb tatsächlich bestimmen.

Der Rechtsraum klärt, unter welchem juristischen Rahmen Dienst, Betrieb und Subprozessoren laufen. Der Exit-Pfad prüft, ob Daten, Konfigurationen und Betriebsparameter exportierbar sind. Die Bedrohungen schließlich markieren, wo Lock-in, Ausfall oder regulatorische Eingriffe am schnellsten durchschlagen. Genau diese sechs Felder machen Souveränitätslücken sichtbar, bevor sie im Betrieb teuer werden [2].

Für die Praxis reicht eine Matrix mit Ampellogik oft nicht aus. Besser ist eine Bewertung je Workload, damit Sie produktive Kernanwendungen getrennt von Testdiensten beurteilen.

Souveränitätsmetriken für kritische Workloads

Für kritische Workloads braucht die Bewertung harte Kriterien. Das Dossier nennt Lock-in-Risiken, Exit-Potenzial und Portabilität als zentrale Faktoren [2]. Daraus lässt sich eine einfache Metrik ableiten: Wie viel des Workloads bleibt bei einem Anbieterwechsel unverändert nutzbar, wie stark hängen Daten und Konfigurationen an proprietären Diensten, und wie viel Betriebswissen steckt außerhalb Ihrer Kontrolle?

Diese Fragen zeigen, ob eine Architektur nur theoretisch souverän ist oder praktisch wechselbar bleibt. Wenn ein Workload offene Standards nutzt und seine Betriebsparameter sauber dokumentiert, sinkt das Wechselrisiko. Wenn dagegen Datenformate, Steuerungsebenen oder Schlüsselverwaltung eng an einen Anbieter gebunden sind, steigt die Abhängigkeit sofort. Genau dort entstehen die Souveränitätskosten, die später in Migrationsprojekten, Sonderfreigaben oder Vertragsverhandlungen sichtbar werden [2].

Für den Architekturentscheid hilft eine klare Priorisierung: Zuerst die Workloads mit hohem Schutzbedarf und hoher Anbieterbindung, dann die mittleren Risiken, zuletzt die unkritischen Services. Bei strategischen Plattformen lohnt sich außerdem ein Blick auf andere Architekturansätze, etwa die BASF-IT-Architektur für digitale Transformation im Großkonzern, um technische Entkopplung und Betriebsfähigkeit besser einzuordnen.

Architektur: Hybride, souveräne und exit-fähige Modelle leiten sich aus EU-Vorgaben ab

Wenn die Vorgaben zur Cloud-Herkunft nur im Policy-Dokument stehen, bleibt die Architektur angreifbar. Das Dossier beschreibt souveräne Hybrid-Clouds als Modell, das Innovation, Compliance und Exit-Fähigkeit verbinden soll [2]. Für Enterprise-Architekten ist der entscheidende Schritt daher nicht die Grundsatzfrage „Cloud oder nicht Cloud“, sondern die Zuordnung von Workloads zu Kontrollzonen, Rechtsräumen und Betreiberrollen.

Die Architektur folgt dabei einem klaren Muster: Kritische Funktionen laufen dort, wo Sie Schlüsselhoheit, Betreiberkontrollen und Auditierbarkeit sauber nachweisen können; weniger sensible Lasten können auf elastischere Plattformen ausweichen [2]. Genau diese Trennung macht hybride Zielbilder belastbar. Sie verhindert, dass ein einzelnes Betriebsmodell alle Schutzbedarfe gleichzeitig erfüllen muss.

Modellvergleich: EU-only, Hybrid und souveräne Public Cloud

Ein belastbarer Vergleich braucht mehr als Labels. Entscheidend sind Kontrolltiefe, Rechtsraum, Betreiberrolle und Exit-Pfad. Das Dossier nennt als Zielgrößen unter anderem EU Only, Schlüsselhoheit und dedizierte Betreiberkontrollen [2]. Ein Beispiel für eine souveräne Public Cloud unter europäischem Recht liefert STACKIT; dort wird die Plattform explizit als europäische souveräne Cloud unter EU-Recht beschrieben [4].

Für die Architektur bedeutet das: EU-Only-Modelle maximieren die formale Kontrolle, verlangen aber oft strengere Auswahl bei Betrieb, Support und Subdienstleistern. Hybride Modelle senken den Druck auf einzelne Plattformen, weil sensible Workloads getrennt bleiben können. Souveräne Public Clouds bieten mehr Skalierung als rein exklusive Umgebungen, wenn Rechtsraum und Betreiberrahmen konsistent bleiben. Wer die Modelle sauber trennt, kann pro Workload entscheiden, welche Kontrolltiefe wirklich nötig ist und wo ein Kompromiss vertretbar bleibt [2] [4].

Exit-Fähigkeit: Technische Kriterien statt politischer Prinzipien

Exit-Fähigkeit entsteht nicht durch eine Absichtserklärung, sondern durch Portabilität. Das Dossier nennt Exit-Potenzial, Lock-in-Risiken und Portabilität als zentrale Prüffelder der Souveränitätsbewertung [2]. Für die Architektur heißt das: Daten, Konfigurationen, Betriebsparameter und Integrationen müssen so modelliert sein, dass ein Wechsel des Anbieters nicht an proprietären Abhängigkeiten scheitert.

Praktisch reduzieren offene Standards die Kopplung an die Plattform. Auch die Trennung von Datenhaltung, Steuerung und Identitätsmanagement senkt den Wechselaufwand. Wenn Sie zusätzlich Betriebswissen dokumentieren und nicht nur beim Provider belassen, verkleinern Sie die Exit-Kosten weiter. Genau hier entscheidet sich, ob ein Modell nur theoretisch souverän wirkt oder im Ernstfall tatsächlich verlagerbar bleibt [2].

Für die Bewertung hilft ein einfacher Architekturtest: Können Sie einen Workload mit vertretbarem Aufwand exportieren, auf einer anderen Plattform wieder importieren und dort ohne vollständigen Neuaufbau betreiben? Wenn diese Antwort offen bleibt, besteht ein Lock-in-Risiko, das im Audit später sichtbar wird. Die Architekturbausteine müssen anschließend operationalisiert und gegen regulatorische Anforderungen abgesichert werden.

Implementierung: Governance, Betreiberkontrollen und regulatorische Absicherung

Wenn Betreiberkontrollen nur im Architekturdiagramm stehen, fehlt im Audit der Nachweis. Das Dossier nennt Rechtsraum, Betreiberkontrollen und Bedrohungen als zentrale Prüffelder für souveräne Cloud-Architekturen [2]. Für die Umsetzung heißt das: Sie brauchen ein Governance-Modell, das Zuständigkeiten, Freigaben und Eskalationen so abbildet, dass jede kritische Entscheidung später nachvollziehbar bleibt. Sonst bleibt Souveränität ein Etikett ohne Beweiskraft.

Die Erfahrung aus der Souveränitätsbewertung zeigt außerdem, dass Stakeholder früh eingebunden werden müssen. Heise beschreibt den Aufbau digitaler Souveränität als Prozess, der mit dem Austausch mit Vorständen, Technologiepartnern und IT-Teams beginnt [5]. Genau dort entsteht die Grundlage für tragfähige Betriebs- und Compliance-Regeln.

Governance-Strukturen für regulierte Architekturen

Für regulierte Unternehmen braucht Governance mehr als ein Policy-Dokument. Das Dossier nennt ausdrücklich Cloud-Strategie, Governance und Umsetzung als gemeinsam zu gestaltende Ebenen, ausgerichtet auf messbare Kriterien für regulierte Unternehmen [2]. Daraus folgt ein praktischer Aufbau: Jede kritische Plattform erhält definierte Owner für Daten, Betrieb, Sicherheit und Compliance. Diese Rollen trennen fachliche Verantwortung von technischer Administration.

Auditfähigkeit entsteht erst, wenn Entscheidungen, Kontrollen und Abweichungen versioniert vorliegen. Wer Betreiberkontrollen sauber dokumentiert, kann später nachweisen, wer Zugriff hatte, in welchem Rechtsraum ein Dienst lief und welche Maßnahmen bei einem Vorfall greifen. Für Architekten ist das kein Formalismus. Es ist die Voraussetzung dafür, dass Souveränitätsziele im Tagesbetrieb nicht verwässern.

Regulatorische Veränderungsprozesse einbinden

Regulatorik ist kein Einmalprojekt. Heise beschreibt die Beobachtung regulatorischer Veränderungen als eigenen Schritt auf dem Weg zur digitalen Souveränität [5]. Für die Architektur bedeutet das: Sie brauchen einen Prozess, der neue EU-Vorgaben, Anpassungen an Betreiberrollen und Änderungen im zulässigen Rechtsraum laufend gegen die Zielarchitektur prüft.

In der Praxis funktioniert das am besten über ein festes Review-Rhythmusmodell. Neue Vorgaben landen zuerst bei Compliance und Architektur, dann bei den Plattformverantwortlichen. Erst danach werden technische Controls, Vertragsklauseln oder Betriebsprozesse angepasst. So verhindern Sie, dass ein späterer Richtlinienwechsel überraschend auf Produktionssysteme durchschlägt.

Wenn Ihre IT mehrere Cloud-Provider nutzt, sollte das Monitoring auch Lieferketten- und Abhängigkeitsänderungen einschließen. Genau an dieser Stelle verknüpfen Sie Compliance mit dem Betrieb.

Checkliste für die EU-konforme Bewertung von Cloud-Herkunft und Souveränität

Die folgende Checkliste verdichtet die bisherigen Prüfpunkte für Architektur- und Compliance-Entscheidungen. Sie ersetzt kein vollständiges Assessment, hilft aber dabei, Workloads einheitlich zu bewerten und Souveränitätslücken schneller zu priorisieren.

Fazit: Souveränitätsziele umsetzen und den nächsten Architektur-Schritt planen

Wenn Cloud-Herkunft und Souveränität nur als Leitbild formuliert bleiben, entsteht kein belastbares Zielbild. Das Dossier macht klar, dass Europas Cloud-Abhängigkeit real ist: US-Anbieter kontrollieren 65 bis 72 Prozent der europäischen Cloud-Kapazitäten und stellen 85 Prozent der GPU-Kapazitäten für KI-Anwendungen bereit [1]. Für Enterprise-Architekten folgt daraus ein klarer Auftrag: Sie müssen Souveränität in Kontrollzonen, Betreiberrollen, Rechtsräume und Exit-Pfade übersetzen.

Der praktische Prüfpunkt ist nicht, ob eine Plattform „souverän“ klingt. Entscheidend ist, ob Sie Schlüsselhoheit, Portabilität und Betreiberkontrollen nachweisen können [2]. Genau dort trennt sich Architektur von Marketing. Eine hybride Zielarchitektur ist dann belastbar, wenn kritische Funktionen in der kontrollierbaren Zone laufen und weniger sensible Lasten auf flexiblere Plattformen ausweichen können [2].

Für die nächsten Schritte hat sich eine einfache Reihenfolge bewährt: Erst Inventar und Abhängigkeiten erfassen, dann Rechtsraum und Betreiberrollen bewerten, anschließend Exit-Fähigkeit und Lock-in-Risiken prüfen [2]. Die Bestandsaufnahme muss dabei nicht abstrakt bleiben. Sie braucht ein sichtbares Ergebnis wie eine Transparenzmatrix, in der Cloud-Inventar, kritische Datenflüsse, Abhängigkeiten und Bedrohungen zusammenlaufen [2]. Genau diese Matrix macht Souveränitätslücken im Audit und im Architekturboard greifbar.

Wenn Sie die Umsetzung strukturieren wollen, starten Sie mit einer belastbaren Migrations- und Compliance-Perspektive. Die internen Guides zu IT-Architektur in der digitalen Transformation und zu C3A und Cloud-Souveränität helfen Ihnen, die Architekturentscheidung mit den operativen und regulatorischen Anforderungen zu verzahnen.

Die passende Checkliste für die Bewertung von Cloud-Herkunft und Souveränität sollte jetzt der nächste Arbeitsschritt sein. Nutzen Sie sie, um Workloads systematisch zu klassifizieren, Souveränitätslücken zu priorisieren und eine exit-fähige Zielarchitektur festzulegen. Wenn Sie diesen Schritt sauber aufsetzen, schaffen Sie die Grundlage für auditierbare Entscheidungen statt für nachträgliche Rechtfertigungen.