Cloud-Souveränität braucht vier Assurance-Level
Der Cloud and AI Development Act verbindet Kapazitätsausbau, Energie und Beschaffung. Unternehmen sollten daraus keine Herkunftsdebatte, sondern eine risikobasierte Architektur ableiten.

In 30 Sekunden
Die EU will ihre Rechenzentrumskapazität binnen fünf bis sieben Jahren mindestens verdreifachen und führt vier Souveränitätsstufen ein. Für Unternehmen folgt daraus kein pauschaler Anbieterwechsel, sondern eine belastbare Zuordnung von Workloads zu Kritikalität, Kontrollbedarf und realistischen Exit-Pfaden.
Kapazität, Energiezugang und Souveränität werden zu einer gemeinsamen Infrastrukturentscheidung und dürfen nicht mehr getrennt beschafft werden.
Die vier vorgesehenen Assurance-Level ermöglichen eine risikobasierte Cloud-Architektur statt eines pauschalen Europa-oder-Nicht-Europa-Schemas.
Der wichtigste Souveränitätsnachweis ist ein getesteter Wechselpfad mit Daten, Identitäten, Betrieb und Kompetenzen.
Position der Redaktion
Transformation Briefing versteht Souveränität als abgestufte Wahlfähigkeit. Kritische Workloads verdienen stärkere Kontrolle; für den breiten Markt bleiben globale Partnerschaften sinnvoll, wenn Portabilität, Transparenz und Exit real sind.
Mit dem Vorschlag für den Cloud and AI Development Act, kurz CADA, verändert die Europäische Kommission die Souveränitätsdebatte. Sie verbindet erstmals in einem sichtbaren politischen Paket drei Fragen, die Unternehmen oft getrennt behandeln: Wo entsteht zusätzliche Rechenkapazität? Wie wird sie mit Energie, Land und Kühlung versorgt? Und welche Kontrolltiefe braucht ein kritischer digitaler Dienst? [1]
Das Ziel ist ehrgeizig: Die Rechenzentrumskapazität der EU soll innerhalb von fünf bis sieben Jahren mindestens verdreifacht werden. Bis 2035 soll der Bedarf europäischer Unternehmen und Verwaltungen vollständig gedeckt werden können. [2] Das ist keine bloße Infrastrukturstatistik. Rechenleistung wird zum knappen Produktionsfaktor – und damit zur Frage von Standort, Versorgungssicherheit und strategischer Verhandlungsmacht.
Der falsche Gegensatz: global oder souverän
Die öffentliche Debatte kennt häufig nur zwei Positionen. Die eine hält globale Hyperscaler für alternativlos. Die andere fordert europäische Autarkie. Beide Perspektiven ignorieren die Vielfalt realer Workloads.
Eine öffentlich verfügbare Website, ein Entwicklungswerkzeug, ein Produktionsleitsystem und eine hochsensible staatliche Anwendung besitzen nicht dieselbe Kritikalität. Sie brauchen deshalb weder dieselbe Anbieterstruktur noch dieselbe Kontrolle. CADA schlägt vier Assurance-Level vor und schafft damit die Grundlage für eine abgestufte Entscheidung. [3]
Die Stufen sind strategisch wertvoll, weil sie Diskussionen konkret machen. Ein Unternehmen kann nicht mehr pauschal „souveräne Cloud“ bestellen. Es muss begründen, welche Assurance für welchen Dienst notwendig ist.
Kapazität ist ohne Energie keine Kapazität
Der geplante Ausbau trifft auf begrenzte Netze, Genehmigungszeiten, Flächen und Wasserressourcen. CADA will geeignete Standorte identifizieren, Genehmigungen vereinfachen und innovative Kühl- sowie Energiemanagementverfahren fördern. [4]
Für CIOs und Infrastrukturverantwortliche folgt daraus eine neue Kostenwahrheit. Der Preis eines Workloads besteht nicht nur aus Compute, Storage und Netzwerk. Er umfasst zunehmend:
- langfristige Energieverfügbarkeit,
- räumliche Nähe zu Netzen und Wärmenutzung,
- regulatorische und gesellschaftliche Akzeptanz,
- CO₂- und Wasserintensität,
- sowie die Opportunitätskosten knapper Kapazität.
FinOps ohne Energieperspektive wird unvollständig. Eine günstige Rechenstunde kann strategisch teuer sein, wenn sie an einen nicht skalierbaren Standort oder eine unklare Lieferkette gebunden ist.
Der Exit-Test trennt Behauptung von Fähigkeit
Viele Cloud-Strategien nennen Portabilität, prüfen sie aber nie. Ein theoretisch containerisierter Workload ist noch nicht wechselbar. Identitäten, Schlüssel, Datenbewegung, Observability, Betriebswissen, Supportprozesse und Verträge müssen gemeinsam funktionieren.
Ein realistischer Exit-Test beantwortet:
- Welche Datenmenge muss in welcher Zeit bewegt werden?
- Welche proprietären Dienste müssen ersetzt oder abstrahiert werden?
- Wer besitzt die Kompetenz, den Zielbetrieb zu übernehmen?
- Welche Kunden- und Regulierungszusagen gelten während des Übergangs?
- Welche Restabhängigkeit bleibt nach dem Wechsel bestehen?
Der Test muss nicht immer in einer vollständigen Migration enden. Schon ein begrenzter Wiederanlauf eines kritischen Dienstes auf einer zweiten Plattform zeigt, wo Souveränität nur auf Papier existiert.
Öffentliche Beschaffung wird zum Marktdesign
CADA verbindet den Souveränitätsrahmen mit einem gemeinsamen Beschaffungsansatz für öffentliche Verwaltungen. Das ist industriepolitisch relevant: Gebündelte Nachfrage kann Standards, Auditierbarkeit und europäische Wertschöpfung stärken. [5]
Doch Beschaffung kann auch Fehlanreize setzen. Zu detaillierte Herkunftsvorgaben können Wettbewerb verengen, ohne technische Kontrolle zu verbessern. Zu allgemeine Kriterien können dagegen bestehende Konzentration zementieren. Gute Beschaffung sollte deshalb Fähigkeiten bewerten:
- Nachweisbare Kontrolle über Daten und Schlüssel,
- Transparenz der Software- und Hardwarelieferkette,
- offene Schnittstellen und dokumentierte Exportpfade,
- überprüfbare Betriebs- und Sicherheitsprozesse,
- Beitrag zu europäischer Innovation und Resilienz,
- sowie Gesamtbetriebskosten über die Vertragslaufzeit.
Herkunft kann ein Signal sein. Sie darf aber nicht der einzige Ersatz für technische und operative Prüfung werden.
Die Entscheidung pro Workload
- Nein Standardisierter, gut ersetzbarer Dienst
Level 1 als Basis prüfen; Wettbewerb und Kosten priorisieren, Exportfähigkeit vertraglich sichern.
- Ja Kritischer Dienst, aber realistische Mehranbieter-Architektur
Level 2 oder 3 anstreben, Abhängigkeiten transparent machen und Wiederanlauf testen.
- Extrem Hoheitliche, sicherheitskritische oder existenzielle Funktion
Level 4 begründen, vollständige Lieferkettenkontrolle und unabhängigen Betrieb nachweisen.
Die Entscheidung darf nicht allein vom CIO getroffen werden. Geschäftswirkung, rechtliche Exposition, Sicherheitslage, Kapitalbedarf und Produktstrategie gehören zusammen. Für jeden kritischen Workload sollte es deshalb einen gemeinsamen Beschluss von Geschäftsowner, Technologie, Sicherheit, Recht und Einkauf geben.
Was dafür spricht – und was dagegen
Für ein abgestuftes Portfolio spricht wirtschaftliche Präzision. Hohe Assurance ist teuer; sie wird dort finanziert, wo Schaden und strategische Bedeutung es rechtfertigen. Gleichzeitig bleibt der breite Markt offen und innovativ.
Dagegen spricht die zusätzliche Steuerungskomplexität. Vier Stufen können zu einem neuen Klassifikationsprojekt werden. Außerdem besteht die Gefahr, dass Teams ihre Systeme zu niedrig einstufen, um Kontrollen zu vermeiden, oder zu hoch, um Budgets zu sichern.
Deshalb braucht das Modell überprüfbare Kriterien und eine Portfolioperspektive. Nicht jedes Team darf seine eigene Definition von „kritisch“ wählen. Umgekehrt darf eine zentrale Stelle nicht jede Abweichung verhindern.
Board Briefing: fünf Fragen
Der Vorstand sollte quartalsweise fünf Fragen beantworten lassen:
- Welche zehn Cloud-Abhängigkeiten besitzen den größten potenziellen Geschäftsschaden?
- Welche davon haben keinen getesteten Exit- oder Wiederanlaufpfad?
- Wo steigen Energie- und Kapazitätskosten schneller als der geschaffene Nutzen?
- Welche Verträge begrenzen Audit, Portabilität oder Unterlieferantentransparenz?
- Welche europäische Option ist heute real – und welche nur strategische Hoffnung?
Souveränität ist eine Architektur mit getesteten Wahlmöglichkeiten, keine Herkunftsfolie im Beschaffungsausschuss.
CADA kann Europas Infrastrukturmarkt verändern. Für Unternehmen beginnt die Arbeit jedoch nicht mit dem Inkrafttreten. Sie beginnt mit einer ehrlichen Karte ihrer Abhängigkeiten und dem Mut, kritische Wahlfähigkeit gezielt zu finanzieren.
Die Workload-Karte muss beim Geschäft beginnen
Viele Cloud-Klassifikationen starten mit Datenarten. Das ist wichtig, aber unvollständig. Derselbe Datentyp kann in einem unterstützenden Bericht oder in einer zeitkritischen Produktionssteuerung auftreten. Geschäftswirkung entsteht aus Dienst, Prozess und Zeitpunkt.
Eine belastbare Workload-Karte verbindet deshalb sechs Dimensionen:
- Umsatz-, Versorgungs- oder Sicherheitswirkung eines Ausfalls,
- Sensibilität und rechtliche Bindung der Daten,
- maximale akzeptable Unterbrechungs- und Datenverlustzeit,
- Abhängigkeit von proprietären Plattformdiensten,
- geopolitische und vertragliche Exposition,
- strategische Bedeutung der entstehenden Daten und Lernschleifen.
Erst daraus folgt die Zielstufe. Level 4 ist nicht automatisch „besser“. Es ist eine teure Assurance für eng begrenzte Fälle. Ein unkritischer Standarddienst kann auf Level 1 wirtschaftlich und sicher angemessen sein.
Souveränitätskosten transparent machen
Höhere Kontrolle erzeugt direkte und indirekte Kosten. Direkte Kosten sind Audit, redundante Infrastruktur, Spezialpersonal und gegebenenfalls kleinere Skaleneffekte. Indirekte Kosten entstehen durch längere Beschaffung, geringere Dienstvielfalt und die Pflege eigener Kompetenzen.
Diese Kosten sollten nicht versteckt werden. Der Vorstand muss sehen, welchen Optionswert er kauft. Eine zweite Plattform kann im Normalbetrieb teurer sein, im Krisenfall aber einen existenziellen Verlust vermeiden. Umgekehrt kann eine vollständig unabhängige Lösung so viel Kapital binden, dass Innovation an anderer Stelle unterbleibt.
Die Entscheidung ähnelt einer Versicherung: Schadenshöhe, Eintrittswahrscheinlichkeit, Prämie und verbleibendes Risiko gehören in dieselbe Vorlage. Souveränität ohne Kostenkurve bleibt politische Symbolik.
Energie wird zum Portfoliolimit
Der geplante Kapazitätsausbau konkurriert mit Elektrifizierung von Industrie, Wärme und Mobilität. Rechenzentren können Last flexibel steuern, Abwärme nutzen und erneuerbare Erzeugung integrieren. Sie können aber auch lokale Netze belasten und Ausbaukonflikte verschärfen.
Unternehmen sollten deshalb drei Energiefragen in die Cloud-Beschaffung aufnehmen:
- Ist Kapazität am Standort langfristig vertraglich und physisch verfügbar?
- Wie transparent sind Energie-, Wasser- und Emissionsdaten je Dienst?
- Kann Rechenlast zeitlich oder geografisch verschoben werden, ohne Datenschutz und Latenz zu verletzen?
Eine jährliche Nachhaltigkeitszahl genügt nicht. Für große KI-Workloads wird die zeitliche und regionale Energieintensität zu einer Betriebsgröße.
Das Problem proprietärer Komfortdienste
Hyperscaler schaffen Produktivität durch integrierte Datenbanken, Identitäten, Analyse- und KI-Dienste. Genau dieser Komfort erhöht Wechselkosten. Eine Architektur, die jede proprietäre Funktion vermeidet, verschenkt Innovation. Eine Architektur, die keine Grenzen setzt, verliert Wahlfähigkeit.
Professionell ist eine bewusste Bindungsentscheidung. Für jeden proprietären Dienst wird dokumentiert:
- welcher Nutzen die Bindung rechtfertigt,
- welche Daten oder Prozesse betroffen sind,
- welche Ersatzoption existiert,
- wie lange ein Wechsel dauern würde,
- und welcher Neubewertungspunkt gilt.
Diese Dokumentation verhindert keine Abhängigkeit. Sie macht sie zu einer kontrollierten Kapitalentscheidung.
Drei Szenarien bis 2030
Im ersten Szenario wächst europäische Kapazität schnell, bleibt aber preislich und funktional hinter globalen Plattformen. Unternehmen nutzen sie vor allem für kritische öffentliche und regulierte Workloads. Das Portfolio wird zweigeteilt.
Im zweiten Szenario entstehen wettbewerbsfähige europäische Cloud- und KI-Dienste mit offenen Schnittstellen. Öffentliche Nachfrage schafft Skalierung, private Unternehmen übernehmen die Angebote. Wahlfähigkeit steigt, ohne den Markt abzuschotten.
Im dritten Szenario verzögern Energie, Genehmigung und Finanzierung den Ausbau. Nachfrage wächst schneller als Angebot; Preise und Warteschlangen steigen. Unternehmen mit früh gesicherter Kapazität und flexibler Architektur besitzen einen Vorteil.
Eine robuste Strategie funktioniert in allen drei Szenarien. Sie setzt nicht auf einen einzelnen politischen Erfolg, sondern kombiniert Vertragsoptionen, technische Portabilität und gezielt eigene Kompetenz.
Das Beschaffungsdesign für vier Level
Ein Beschaffungsprozess sollte zunächst die benötigte Assurance bestätigen und erst danach Anbieter vergleichen. Sonst gewinnt entweder der günstigste Standarddienst oder die maximalistische Sicherheitsforderung.
Für Level 1 stehen Standort, Basissicherheit und Exportfähigkeit im Vordergrund. Level 2 verlangt zusätzlich Transparenz über Drittlandabhängigkeiten und Softwarelieferkette. Level 3 erweitert die Prüfung um Eigentum, Kontrolle und Personal. Level 4 benötigt vollständige Nachvollziehbarkeit und Schutz vor Drittlandinterferenz.
Die Nachweise müssen auditierbar und zeitlich gültig sein. Ein Zertifikat bei Vertragsbeginn reicht nicht, wenn Eigentum, Unterauftragnehmer oder Softwarekomponenten später wechseln.
Das Gegenargument: Multicloud ist keine Souveränität
Zwei Anbieter bedeuten nicht automatisch Wahlfähigkeit. Wenn beide dieselbe Chip-, Netzwerk- oder Identitätsabhängigkeit teilen, bleibt ein gemeinsamer Ausfallpfad. Wenn Anwendungen unterschiedlich implementiert sind, kann Multicloud sogar Komplexität erhöhen, ohne einen realistischen Wechsel zu ermöglichen.
Deshalb sollte Redundanz entlang konkreter Ausfallursachen gestaltet werden. Für manche Dienste genügt ein zweiter Standort. Andere brauchen einen zweiten Betreiber, unabhängige Identitäten oder einen funktional reduzierten Notbetrieb. Architektur folgt Szenario, nicht Modewort.
Die Rolle des Aufsichtsrats
Der Aufsichtsrat muss keine Cloud-Produktdetails entscheiden. Er sollte aber prüfen, ob das Management Konzentrationsrisiken, Exit-Zeiten und Assurance-Kosten als Teil der Unternehmensstrategie behandelt. Besonders kritisch sind Systeme, deren Ausfall oder Fremdzugriff die Fortführung des Geschäfts gefährden könnte.
Ein jährlicher Bericht sollte die größten Abhängigkeiten, Veränderungen seit dem Vorjahr, letzte Wiederanlauftests und offene Ausnahmen zeigen. Dadurch wird Cloud-Souveränität von einer Technologiefrage zu überprüfbarer Risikosteuerung.
Schlussfolgerung
Der CADA-Vorschlag bietet eine nützliche Sprache für abgestufte Souveränität. Unternehmen sollten sie nicht einfach übernehmen, sondern in ihre Geschäfts- und Architekturentscheidungen übersetzen. Der Wert liegt nicht im Label einer Stufe, sondern in den nachweisbaren Fähigkeiten dahinter.
Wer Kritikalität sauber segmentiert, Kosten offenlegt und Exit-Pfade testet, kann globale Innovation und europäische Kontrolle verbinden. Wer dagegen jeden Workload gleich behandelt, zahlt entweder zu viel für Souveränität oder zu viel für unbeabsichtigte Abhängigkeit.
Die nächsten sechs Monate
Ein pragmatischer Einstieg beginnt nicht mit einer vollständigen Neuklassifikation der gesamten IT. Zwanzig kritische Workloads reichen, um Kriterien, Datenqualität und Entscheidungsprozess zu testen. Für jeden Fall werden heutige und angestrebte Assurance, größte Abhängigkeit, Exit-Zeit und verantwortlicher Geschäftsowner dokumentiert.
Anschließend sollten zwei unterschiedliche Übungen stattfinden. Die erste simuliert einen vertraglichen oder geopolitischen Wechsel. Die zweite simuliert einen technischen Ausfall mit begrenzter Datenverfügbarkeit. Beide Szenarien zeigen andere Schwächen. Ein System kann rechtlich portabel, aber technisch schwer beweglich sein – oder technisch redundant, aber von derselben Identität und Lieferkette abhängen.
Nach sechs Monaten entscheidet der Vorstand, welche zusätzlichen Kontrollen wirtschaftlich gerechtfertigt sind. Er sollte auch bewusst dokumentieren, wo eine Abhängigkeit akzeptiert wird. Transparente Akzeptanz ist strategisch reifer als ein pauschales Souveränitätsversprechen, das technisch nicht eingehalten werden kann.
CADA liefert dafür eine gemeinsame europäische Sprache. Die Qualität der Unternehmensentscheidung entsteht jedoch aus realen Tests, klaren Kosten und einem Portfolio, das zwischen gewöhnlichem Komfort und existenzieller Handlungsfähigkeit unterscheiden kann.
Was der Vorstand vierteljährlich sehen sollte
Ein belastbares Souveränitäts-Dashboard braucht nur wenige, aber entscheidungsfähige Größen. Es zeigt den Anteil kritischer Dienste je Assurance-Level, die fünf größten Konzentrationsrisiken, die real getestete Wiederanlaufzeit und die Kosten eines belastbaren Exit-Pfads. Hinzu kommen offene Abweichungen mit verantwortlicher Person und Ablaufdatum. Eine abstrakte Ampel ohne diese Bezüge verschleiert mehr, als sie erklärt.
Besonders wichtig ist die Trennung zwischen vertraglicher und technischer Beweglichkeit. Ein Vertrag kann einen Export zusichern, während Datenmenge, proprietäre Funktionen oder fehlende Betriebskompetenz einen Wechsel faktisch verhindern. Umgekehrt kann eine Anwendung technisch portabel sein, obwohl Kündigungsfristen, Lizenzrechte oder Zugänge sie binden. Beide Dimensionen müssen deshalb getrennt bewertet und anschließend in einem realistischen Szenario zusammengeführt werden.
Der Vorstand sollte außerdem eine bewusste Investitionsschwelle festlegen. Nicht jede Abhängigkeit rechtfertigt doppelte Infrastruktur. Wo ein Ausfall jedoch Sicherheit, Liquidität, Produktion oder regulatorische Handlungsfähigkeit bedroht, ist Resilienz keine optionale Komfortfunktion. Die Kostenentscheidung wird damit transparent: Das Unternehmen bezahlt entweder vorab für überprüfbare Wahlfähigkeit oder später für eine Krise, deren Preis und Zeitpunkt es nicht kontrolliert.
Management-Assessment
Kann das Unternehmen für jeden geschäftskritischen Cloud-Workload begründen, welche Souveränitätsstufe notwendig ist und wie ein Wechsel tatsächlich funktionieren würde?
Workloads entlang Geschäftswirkung, Datenkontrolle, Jurisdiktion, Softwarelieferkette und Exit-Zeit klassifizieren.
- Die 20 kritischsten Cloud-Workloads und ihre Abhängigkeiten kartieren.
- Für jeden Workload eine Ziel-Assurance-Stufe festlegen.
- Zwei Exit-Tests mit realen Daten, Identitäten und Betriebsabläufen durchführen.
Belege & Vertiefung
Quellenverzeichnis
Bevorzugt wurden Rechtsakte, Veröffentlichungen europäischer Institutionen und amtliche Statistiken. Abrufdaten dokumentieren den Recherchestand. Unser Quellenstandard
- Europäische KommissionProposal for the Cloud and AI Development Act Abgerufen am 25. Juli 2026
- Europäische KommissionCloud and AI Development Act Abgerufen am 25. Juli 2026
- Europäische KommissionStrengthening Europe’s Tech Sovereignty Abgerufen am 25. Juli 2026
Transparenz
Versions- und Korrekturhistorie
- Assurance-Modell, Gegenargumente, Szenarien und Management-Assessment erweitert.
- Erstveröffentlichung zum CADA-Vorschlag.