Cloud and AI Development Act: Die vier Souveränitätsstufen der EU im Klartext

„Souverän" war bislang ein Marketingwort. Jeder Anbieter durfte es benutzen, keiner musste es belegen. Genau das ändert der Cloud and AI Development Act – kurz CADA –, den die EU-Kommission am 3. Juni 2026 als Dokument COM(2026) 502 vorgelegt hat, gestützt auf Art. 114 und Art. 173 Abs. 3 AEUV. Der Text ist ein Verordnungsvorschlag, kein geltendes Recht: Parlament und Rat verhandeln noch, die gemeinsame Roadmap nennt Q4 2027 als indikatives Zieldatum für die Einigung.

Trotzdem ist der Entwurf schon jetzt relevant. Wer im Herbst 2026 eine Ausschreibung schreibt oder einen Lieferanten auditiert, hat mit den Union Assurance Levels erstmals ein Raster, das nicht von der Marketingabteilung des Anbieters stammt. Dieser Artikel geht durch alle vier Stufen, ordnet die Kritik ein und übersetzt das Ganze in Anforderungen, die Sie in eine Leistungsbeschreibung schreiben können.

Was CADA ist und woher es kommt

CADA ist einer von vier Bausteinen des „European Technological Sovereignty Package" vom 3. Juni 2026. Die anderen drei: der Chips Act 2.0, die EU Open Source Strategy und die Strategic Roadmap for Digitalisation and AI in Energy. Das Paket ist die Reaktion auf eine Abhängigkeit, die die Kommission selbst beziffert: Bei über 80 Prozent der digitalen Produkte, Dienste, Infrastrukturen und Schutzrechte hängt die EU an Nicht-EU-Anbietern. Im Cloud-Markt entfallen über 70 Prozent auf drei US-Hyperscaler; alle europäischen Anbieter zusammen kommen auf rund 13 Prozent.

Der Kern der Verordnung steckt in Artikel 16: Er errichtet den „Union cloud computing sovereignty framework" mit vier Union Assurance Levels. Die konkreten Kriterien stehen nicht im Artikeltext, sondern in Annex II – ein wichtiges Detail, denn Annexe lassen sich per delegiertem Rechtsakt ändern. Die Kommission ist verpflichtet, Annex II mindestens alle 18 Monate zu überprüfen (Art. 16 Abs. 3).

Wer prüft, und wie

• Art. 17 – Anerkennungsverfahren bei der jeweils zuständigen nationalen Behörde.
• Art. 19 – Selbstbewertung: nur für Level 1 zulässig. Der Anbieter erklärt sich selbst als konform.
• Art. 20/21 – Drittprüfung durch akkreditierte Auditorganisationen. Pflicht ab Level 2.
• Art. 22 – zentrales EU-Register aller anerkannten Dienste. Damit wird die Stufe eines Anbieters öffentlich nachschlagbar.

Das Register in Art. 22 ist der praktisch wertvollste Teil der Verordnung. Es beendet die Situation, in der ein Einkäufer die Souveränitätsbehauptung eines Anbieters nur gegen das Whitepaper desselben Anbieters prüfen kann.

Neben dem Stufensystem enthält CADA Kapazitätsziele: Bis 2030 soll die EU ihre Rechenzentrumskapazität mindestens verdreifachen, bis 2035 soll die Rechenkapazität den Bedarf decken. Bis 2030 sollen sämtliche Genehmigungen für Bau und Betrieb eines Rechenzentrums EU-weit in unter 18 Monaten erhältlich sein, und bis 2035 sollen hochkritische Anwendungsfälle der öffentlichen Hand auf souveränen Cloud- und KI-Diensten laufen.

Die vier Union Assurance Levels

Die verbreitete Kurzfassung – „Level 1 = Server in der EU, Level 4 = alles europäisch" – ist bequem und falsch. Annex II ist detaillierter, und die Details entscheiden darüber, wer welche Stufe erreicht.

Level 1 (Annex II, 1.1): EU-Perimeter ohne Kontrollfrage

Kumulativ gefordert sind: Niederlassung des Anbieters in der Union; Infrastruktur und Assets – inklusive der von Subunternehmern genutzten – in der Union; Kundendaten einschließlich Metadaten und Telemetriedaten verbleiben ausschließlich in der Union; volle Transparenz über die Subunternehmerkette; Cybersicherheit nach dem Stand der Technik; und keine Drittstaatsgesetze, die eine Meldung von Software-Schwachstellen an Drittstaatsbehörden vor deren Ausnutzung verlangen.

Das ist deutlich mehr als „Rechenzentrum Frankfurt". Insbesondere der Punkt Telemetrie trifft real: Viele Managed-Cloud-Dienste schicken Betriebs- und Nutzungstelemetrie an globale Backends. Entscheidend ist aber, was nicht gefordert wird: Level 1 schließt Drittstaatskontrolle ausdrücklich nicht aus. Genau deshalb ist Level 1 für die „souveränen" EU-Angebote der US-Hyperscaler grundsätzlich erreichbar – und zwar per Selbstbewertung nach Art. 19.

Level 2 (Annex II, 2.1): Kontrolle bleibt erlaubt, wird aber eingehegt

Level 2 addiert eine lange Liste: Personal in der Union; ein EU-Cybersicherheitszertifikat mindestens der Stufe „substantiell" (nach VO (EU) 2019/881, ersatzweise nationale Schemata); Support und Wartung ausschließlich aus der Union heraus; eine vollständige SBOM nach Art. 3 Nr. 39 Cyber Resilience Act (VO (EU) 2024/2847); Quellcode-Audits und ein Migrationsplan für sicherheitsrelevante Drittstaats-Softwarekomponenten; sowie die rechtliche, technische und organisatorische Trennung von Drittstaats-Tochtergesellschaften.

Zwei Klauseln sind für KI-Beschaffung entscheidend: Daten aus dem Dienst dürfen nicht zum Training oder Fine-Tuning von KI-Systemen genutzt werden, die von Drittstaatsakteuren betrieben werden – und sie dürfen die Union überhaupt nicht verlassen. An diesem Punkt scheiden generische SaaS-KI-Angebote in öffentlichen Ausschreibungen aus, unabhängig davon, wie die AGB formuliert sind. Wer hier Compliance behauptet, muss sie über Betriebsarchitektur belegen, nicht über Zusicherungen; anonymisierende Verfahren wie Differential Privacy lösen das Problem nicht, weil es um Verfügungsgewalt geht, nicht um Re-Identifizierbarkeit.

Steht der Anbieter unter Drittstaatskontrolle, muss er auf Level 2 nachweisen, dass Datenzugriff, Dienstunterbrechung oder Qualitätsverschlechterung („Kill-Switch") und die erzwungene Umsetzung von Sanktionen und Embargos ausgeschlossen sind. Drittstaatskontrolle ist auf dieser Stufe also weiterhin zulässig – nur mit Schutzmaßnahmen.

Level 3 (Annex II, 3.1): Kontrolle ist das Ausschlusskriterium

Hier kippt die Logik. Anbieter und Subunternehmer dürfen nicht unter der Kontrolle eines Drittstaats stehen – mit der einzigen Ausnahme aus Art. 18. Das Personal muss aus Unionsbürgern bestehen; bei Verschlusssachen ist eine nationale Sicherheitsüberprüfung im Sinne von Art. 2 Nr. 21 VO (EU) 2021/697 erforderlich. Das Cybersicherheitszertifikat muss weiterhin mindestens „substantiell" sein.

Level 4 (Annex II, 4.1): keine Ausnahme, Zertifikat „hoch"

Für Level 4 gilt: keinerlei Drittstaatskontrolle, und zwar ohne Ausnahmemöglichkeit. Personal = Unionsbürger. EU-Cybersicherheitszertifikat der Stufe „hoch". Support ausschließlich in der Union durch Unionsansässige. SBOM plus Nachweis, dass kein Drittstaat effektive Kontrolle über Design, Entwicklung, Wartung und Weiterentwicklung der Softwarekomponenten ausübt.

Kriterium	Level 1	Level 2	Level 3	Level 4
Daten & Telemetrie nur in der EU	ja	ja	ja	ja
Nachweisform	Selbstbewertung (Art. 19)	Drittaudit	Drittaudit	Drittaudit
Cybersicherheitszertifikat	–	substantiell	substantiell	hoch
SBOM & Quellcode-Audit	–	ja	ja	ja + Kontrollnachweis
Drittstaatskontrolle zulässig	ja, uneingeschränkt	ja, mit Schutzmaßnahmen	nein (Ausnahme Art. 18)	nein, ohne Ausnahme
Anteil an Behörden-Use-Cases*	ca. 70 %	ca. 20 %	ca. 9 %	ca. 1 %

* Verteilung nach der Analyse von netzpolitik.org vom 4. Juni 2026. Die Kommission selbst kommuniziert nur, dass Level 3 und 4 zusammen rund 10 Prozent der Public-Sector-Use-Cases betreffen – das deckt sich mit 9 + 1.

Warum Level 1 kein Hindernis ist

Die schärfste Kritik am Entwurf zielt auf die Einstiegsstufe. Sie lautet nicht „Server in Frankfurt reicht" – Level 1 verlangt, wie oben gezeigt, mehr als das. Der eigentliche Punkt sind zwei strukturelle Eigenschaften:

1. Level 1 ist die einzige Stufe, die Drittstaatskontrolle nicht adressiert. Ein Anbieter kann vollständig einem US-Konzern gehören, dem CLOUD Act unterliegen und trotzdem konform sein, solange die Daten physisch in der Union bleiben.
2. Level 1 wird per Selbstbewertung nachgewiesen. Keine akkreditierte Auditorganisation, keine Prüfung der Subunternehmerkette durch Dritte – eine Erklärung des Anbieters genügt für die Anerkennung nach Art. 17.

Daraus zieht netzpolitik.org in der Analyse vom 4. Juni 2026 die viel zitierte Bilanz: „gut 99 Prozent, mindestens aber 70 Prozent" staatlicher Daten könnten weiterhin bei US-Anbietern liegen. Wichtig für die korrekte Zuschreibung – diese Zahl stammt nicht von der Kommission, sondern ist aus der erwarteten Level-Verteilung abgeleitet: rund 70 Prozent der Anwendungsfälle auf Level 1, 20 Prozent auf Level 2, 9 Prozent auf Level 3, 1 Prozent auf Level 4. Da Level 1 und 2 Drittstaatskontrolle zulassen, ergibt sich der Korridor von 70 bis 99 Prozent.

Level 4 wäre nach dieser Lesart faktisch dem Verteidigungsbereich vorbehalten. Justiz, Polizei und Grenzsicherung landeten auf Level 2. Auch hier lohnt Genauigkeit: Der Verordnungstext schreibt diese Zuordnung nicht fest. Art. 29 Abs. 1 lit. a nennt nationale Sicherheit, innere Sicherheit, Außengrenzmanagement, Verteidigung, Justiz und Strafverfolgung nur als Bereiche, die einer Risikobewertung zu unterziehen sind. Die konkrete Stufenzuordnung erfolgt über einen Durchführungsrechtsakt zur Methodik (Art. 29 Abs. 3), der ausdrücklich nur für den Verteidigungsbereich die höchste Stufe vorsieht. Ob Polizeidaten am Ende auf Level 2 oder 3 landen, ist damit eine politische Entscheidung, die noch nicht gefallen ist.

Artikel 18: die Ausnahmeklausel

Artikel 18 – „Associated third countries" – wird in vielen Zusammenfassungen falsch wiedergegeben. Er nimmt Drittstaaten nicht von den Level-3-Anforderungen aus. Er erlaubt der Kommission, per Durchführungsrechtsakt Drittstaaten anzuerkennen, sodass dort kontrollierte Anbieter überhaupt erst für ein Level-3-Audit zugelassen sind. Alle übrigen Level-3-Kriterien – Unionsbürger als Personal, Zertifikat „substantiell", saubere Subunternehmerkette – gelten unverändert weiter.

Die Anerkennung setzt sechs kumulative Kriterien voraus:

• (a) ein bestehender Angemessenheitsbeschluss nach Art. 45 DSGVO;
• (b) keine Regelungen für rechtswidrigen Zugriff auf nicht-personenbezogene Daten im Widerspruch zu Art. 32 Abs. 2 und 3 Data Act (VO (EU) 2023/2854);
• (c) keine Möglichkeit, eine Dienstunterbrechung oder die Durchsetzung von Sanktionen und Embargos zu erzwingen;
• (d) keine Beschränkung modernster Technologien;
• (e) ein offener Markt für EU-Cloud-Dienste;
• (f) gleichwertiger Zugang zu öffentlichen Ausschreibungen.

Fällt eine Voraussetzung weg, kann die Anerkennung zurückgenommen oder ausgesetzt werden (Abs. 2); die Liste anerkannter Staaten ist auf der Kommissions-Website zu veröffentlichen (Abs. 3). Die USA sind damit nicht automatisch begünstigt – im Gegenteil: Kriterium (c) kollidiert erkennbar mit der US-Sanktionspraxis, Kriterium (b) mit Zugriffen nach dem CLOUD Act. Ein US-Angemessenheitsbeschluss allein reicht nicht.

Die substanzielle Kritik an Art. 18 ist deshalb nicht „Freifahrtschein für die USA", sondern subtiler: Die Bewertung der sechs Kriterien liegt allein bei der Kommission, erfolgt per Durchführungsrechtsakt und ist damit politisch beeinflussbar. Ein handelspolitischer Deal kann eine technische Souveränitätsanforderung aushebeln, ohne dass der Verordnungstext geändert werden müsste. Für Level 4 existiert dieser Pfad ausdrücklich nicht – das ist der wesentliche Unterschied zwischen den beiden oberen Stufen.

Redaktioneller Hinweis für Textleser: Annex II Ziff. 3.1 lit. g verweist auf „Article 19" statt auf Article 18 – ein Redaktionsfehler im Entwurf, der im Trilog vermutlich korrigiert wird.

Was der Vorschlag nicht enthält

Die verbreitete These „CADA enthält keine verbindlichen Beschaffungsvorgaben, alles bleibt den Mitgliedstaaten überlassen" ist nur halb richtig – und in dieser Form in einer Ausschreibungsdiskussion leicht widerlegbar. Verbindlich sind nämlich sehr wohl:

• Art. 30: Jede öffentliche Auftraggeberin muss mindestens Level 1 beschaffen. Wo die Risikobewertung eine „public order relevance" feststellt, darf ausschließlich Level 2, 3 oder 4 beschafft werden.
• Art. 29 Abs. 5: Die Kommission kann eine aus ihrer Sicht zu niedrige nationale Stufenzuordnung per Durchführungsrechtsakt überschreiben.
• Art. 29 Abs. 1: Mitgliedstaaten und EU-Einrichtungen müssen binnen eines Jahres nach Inkrafttreten die erste Risikobewertung durchführen, danach alle zwei Jahre; Ergebnisse sind der Kommission binnen drei Monaten zu melden.
• Art. 29 Abs. 6: Ergibt die Bewertung Migrationsbedarf, gilt eine Übergangsfrist von maximal zwölf Monaten.
• Art. 48: Die Verordnung gilt ein Jahr nach Inkrafttreten.

Zutreffend bleibt: Es gibt kein namentliches Anbieterverbot. Kein Artikel schließt AWS, Microsoft oder Google aus. Und die entscheidende Weiche – welcher Anwendungsfall welche Stufe braucht – stellen die Mitgliedstaaten und EU-Einrichtungen selbst. Wer Level 1 für seine Fachverfahren als ausreichend einstuft, hat die Verordnung formal erfüllt.

Eine zweite Lücke betrifft die Vergabemechanik. Art. 32 „Union added value" verpflichtet Auftraggeber zwar, europäischen Mehrwert als nicht-preisliches Zuschlagskriterium aufzunehmen – gleichzeitig muss dieses Kriterium ausdrücklich „ancillary and not decisive" sein. Erwägungsgrund 67 nennt als Orientierung eine Maximalgewichtung von 15 von 120 Punkten, also 12,5 Prozent. Souveränität wirkt also über die Assurance-Level-Schwelle als Ausschlusskriterium, nicht über die Punktwertung. Wer hofft, europäische Anbieter würden über die Bewertungsmatrix nach vorne rutschen, wird enttäuscht.

Was das für Ihre Ausschreibung heißt

Auch als Nicht-Behörde profitieren Sie vom Raster: Es liefert prüfbare Formulierungen, wo bisher „DSGVO-konform" und „souverän" standen. Drei Schritte haben sich in Lieferantenaudits bewährt.

1. Stufe als Mindestanforderung, nicht als Wunsch

Schreiben Sie das Zielniveau in die Leistungsbeschreibung, nicht in die Bewertungsmatrix. Formulierung nach dem Muster: „Der Dienst erfüllt die Kriterien nach Annex II Ziff. 3.1 des Verordnungsvorschlags COM(2026) 502 (Union Assurance Level 3). Der Nachweis erfolgt durch [Auditbericht / Selbstauskunft mit Belegen] zum Zeitpunkt der Angebotsabgabe." Damit ist die Anforderung auch vor Inkrafttreten operabel: Sie referenzieren einen öffentlich zugänglichen Kriterienkatalog, keine Zertifizierung, die es noch nicht gibt.

2. Nachweise verlangen, die man nicht zusichern kann

Zusicherungen sind billig. Prüfbar sind:

• Betreiberstruktur: Gesellschafterliste, Beherrschungs- und Gewinnabführungsverträge, Nachweis der Trennung von Drittstaats-Töchtern.
• Personal: Wo sitzt der 2nd- und 3rd-Level-Support tatsächlich? Wer hat administrativen Zugriff auf Hypervisor und Storage-Layer?
• Schlüsselhoheit: Wer erzeugt, verwahrt und rotiert die Schlüssel? „Customer-managed keys" in einem KMS des Anbieters ist etwas anderes als ein HSM in Ihrem Rack.
• SBOM: vollständig nach Art. 3 Nr. 39 CRA – inklusive der Modell- und Inferenzkomponenten, nicht nur der Applikationsbibliotheken.
• Telemetrie: Liste aller ausgehenden Verbindungen im Regelbetrieb, mit Zielsystem und Rechtsgrundlage.
• Trainingsverbot: vertragliche und technische Umsetzung des Level-2-Verbots, Daten für Training oder Fine-Tuning von Drittstaats-KI zu nutzen.

3. Die Abkürzung: Level-4-Eigenschaften per Konstruktion

Der bemerkenswerteste Aspekt von Annex II Ziff. 4.1 ist, wie wenig exotisch die Kriterien sind, sobald man den Dienst nicht mietet, sondern betreibt. Keine Drittstaatskontrolle, Personal aus der Union, Support aus der Union, effektive Kontrolle über Design, Wartung und Weiterentwicklung der Softwarekomponenten – das ist die Beschreibung einer On-Premise-Installation mit offenen Modellgewichten. Was auf Level 4 als aufwendige Nachweispflicht erscheint, ist bei einer eigenen Installation schlicht der Normalzustand: Die Frage „Wer könnte diesen Dienst abschalten?" hat dort eine triviale Antwort.

Zwei Einschränkungen gehören dazu. Erstens: Eine formale Anerkennung nach CADA setzt das abgeschlossene Gesetzgebungsverfahren, akkreditierte Auditorganisationen und das Register nach Art. 22 voraus. Bis dahin argumentieren Sie mit Kriterienerfüllung, nicht mit einem Zertifikat. Zweitens: Die Kontrolle über den Stack ist eine Betriebsaufgabe, keine einmalige Beschaffung. Modell-Updates, Sicherheits-Patches, Evaluationsläufe, Rollback-Fähigkeit – ohne belastbare LLMOps-Praxis wird aus Souveränität schnell ein veralteter Stack. Der Nachweis „effektive Kontrolle über Weiterentwicklung" ist gleichzeitig eine Selbstverpflichtung.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. Europäische Kommission – Digital Strategy proposal cloud and ai development act cada
2. Europäische Kommission
3. Europäische Kommission
4. Europäische Kommission – Digital Strategy cloud and ai development act
5. commission.europa.eu strengthening europes tech sovereignty 2026 06 03 en
6. netzpolitik.org cloud and ai development act eu kommission greift bei us cloud anbietern kaum du
7. cyber-regulierung.de cloud ai development act
8. globalpolicywatch.com the eu cloud and ai development act in depth
9. eu-cloud-ai-act.com
10. cloudmagazin.com cada cloud souveraenitaet assurance levels
11. iapp.org europe s cloud and ai development act grand ambition fragile foundations

Häufig gestellte Fragen zum Cloud and AI Development Act

Gilt CADA schon?

Nein. Der Cloud and AI Development Act wurde am 3. Juni 2026 als Verordnungsvorschlag vorgelegt und durchläuft das Gesetzgebungsverfahren. Als Bewertungsraster taucht er aber bereits jetzt in Ausschreibungen und Lieferantenaudits auf.

Welche Stufe erreicht mein aktueller Cloud-Anbieter?

Rechenzentrumsstandort in der EU erfüllt Level 1. Für Level 3 brauchen Sie EU-basierte Kontrolle und europäisches Personal, für Level 4 die vollständige Kontrolle über den Technologiestack – das erreichen Anbieter mit US-Mutterkonzern praktisch nicht.

Was ist an Artikel 18 umstritten?

Er erlaubt der Kommission, Drittstaaten einschließlich der USA per Angemessenheitsbeschluss von Level-3-Anforderungen auszunehmen. Kritiker sehen darin die Möglichkeit, die Souveränitätsanforderungen politisch zu umgehen.

Erfüllt eine eigene Installation Level 4?

Der Sache nach ja: Wer Hardware, Betrieb, Personal und Schlüsselmaterial im eigenen Haus hat, kontrolliert den vollständigen Stack. Eine formale Zertifizierung nach CADA setzt allerdings das abgeschlossene Verfahren voraus.