Zusammenfassung

  • Der CADA-Vorschlag trennt zwei rechtlich verschiedene Entscheidungen. Nach Artikel 29 sollen Mitgliedstaaten und Unionsstellen risikobasiert feststellen, welche öffentlichen Tätigkeiten zur Wahrung der öffentlichen Ordnung beitragen und welches Union Assurance Level erforderlich ist; Artikel 30 macht die entsprechende Anerkennung des Cloud-Dienstes dann grundsätzlich zur Beschaffungsvoraussetzung. Das ist ein Zulässigkeits- beziehungsweise Eignungstor für den Dienst, kein Zuschlagsbonus. Eine nach Artikel 30 vorgesehene Ausnahme muss außergewöhnlich und ordnungsgemäß begründet sein.
  • Artikel 32 funktioniert anders und enger: Nur bei öffentlichen Vergabeverfahren für innovative Cloud-Computing-Dienste und KI-Systeme sollen nicht preisbezogene Zuschlagskriterien den Beitrag eines Bieters zum europäischen Cloud- und KI-Ökosystem bewerten. Diese Kriterien müssen auftragsbezogen, vorab offengelegt, ermessensgebunden sowie ausdrücklich „ancillary and not decisive“ sein. Erwägungsgrund 67 nennt lediglich als Orientierung eine mögliche Höchstgewichtung von 15 von 120 Punkten; der Artikel selbst schreibt keine Punktzahl vor. Der EWSA hat am 23. September 2026 eine deutlich stärkere Gewichtung empfohlen, doch diese Empfehlung ist kein geltendes Recht und ändert den Kommissionsvorschlag nicht.

Das Tor entscheidet über die Zulässigkeit, nicht über den Zuschlag

Das praktische Beschaffungsproblem lässt sich an einem einfachen Fall zeigen. Eine Behörde will eine Cloud-Leistung für eine sensible Tätigkeit beschaffen. Dass ein Dienst das nach Artikel 29 ermittelte erforderliche Assurance Level besitzt und deshalb das Tor des Artikels 30 passiert, beantwortet lediglich die Frage, ob dieser Dienst grundsätzlich für die betreffende Nutzung beschafft werden darf. Es beantwortet noch nicht die zweite Frage, welches von mehreren zulässigen Angeboten nach Preis, Technik, Leistungsfähigkeit und den zulässigen Qualitätskriterien den Zuschlag erhält. Genau diese Trennung verhindert, dass Artikel 32 fälschlich als allgemeine „Buy European“-Zugangsschranke gelesen wird.

Der Vorschlag der Kommission vom 3. Juni 2026 ist als Verordnung auf die Rechtsgrundlagen der Artikel 114 und 173 Absatz 3 AEUV gestützt. Die Kommission verfolgt damit mehrere miteinander verbundene Ziele: mehr und räumlich breiter verfügbare Rechenkapazität in der Union, günstigere Bedingungen für nachhaltige und innovative Recheninfrastruktur, geringere Risiken aus Daten- und Betriebsabhängigkeiten sowie resilientere Cloud-Versorgung insbesondere für den öffentlichen Sektor. Die politische Begleitdarstellung nennt darüber hinaus das Ziel, die europäische Rechenzentrumskapazität innerhalb von fünf bis sieben Jahren mindestens zu verdreifachen. Diese politische Zielmarke ist von den konkret einklagbaren Pflichten des Vorschlagstexts zu unterscheiden.

Der Entwurf ist erheblich breiter als seine Beschaffungsvorschriften. Er verbindet Forschungs- und Innovationsmaßnahmen, nationale Cloud- und KI-Strategien, Instrumente für Rechenzentrumskapazitäten und Beschleunigungsgebiete, ein unionsweites Anerkennungsregime für Cloud-Dienste, öffentliche Beschaffung, Innovationsbeschaffung und eine europäische Public-Sector-Cloud-Föderation. Für die hier entscheidende Governance-Frage liegt der Schwerpunkt jedoch in Titel IV: Anerkennung und Überwachung von Cloud-Diensten, Risikobewertung sowie Beschaffung.

Auch die Begriffe sind überwiegend an bestehendes Unionsrecht angebunden. Artikel 2 übernimmt für den „cloud computing service“ die Definition aus Artikel 6 Nummer 30 NIS2 und für das „AI system“ die Definition des AI Act; „public sector body“ verweist auf die Open-Data-Richtlinie. „Union entities“ sind die durch die EU-Verträge oder auf deren Grundlage errichteten Institutionen, Einrichtungen, Ämter und Agenturen.

Erwägungsgrund 10 stellt zudem klar, dass ein über die Cloud bereitgestelltes KI-System insofern in den Cloud-Kontext fällt, als es um die Bereitstellung beziehungsweise Zugänglichmachung geht; das KI-System oder Modell selbst wird dadurch nicht einfach zum Cloud-Dienst.

Die vorgeschlagenen vier Union Assurance Levels bilden eine gestufte Vertrauensarchitektur. Schon Level 1 enthält nach Anhang II unter anderem unionsbezogene Anforderungen an Niederlassung, Infrastruktur sowie grundsätzlich den Verbleib von Kundendaten einschließlich Metadaten und Telemetriedaten in der Union, vorbehaltlich der ausdrücklich vorgesehenen Ausnahmen. Mit höheren Stufen werden die Anforderungen an Drittstaatenabhängigkeiten, Kontrolle, Personal, Software- und Lieferketten sowie betriebliche Autonomie strenger. Die Kommission beschreibt die Stufen als kumulativ ansteigendes System; die konkrete Compliance muss deshalb anhand sämtlicher Kriterien des Anhangs II und nicht anhand eines vereinfachten Etiketts geprüft werden.

Der Zugang zu diesem System läuft über Artikel 17. Ein Anbieter, der seinen Cloud-Dienst für die unionsweite Anerkennung qualifizieren will, beantragt die Anerkennung grundsätzlich bei der zuständigen Behörde seines Niederlassungsstaats. Für die höheren Assurance Levels sieht der Vorschlag unabhängige Audits und entsprechende Nachweise vor. Eine erteilte Anerkennung soll unionsweit gelten; Artikel 22 verpflichtet die Kommission zu einem öffentlich zugänglichen zentralen Register anerkannter Dienste. Widerrufe von Audit- beziehungsweise Anerkennungsentscheidungen sollen dort fünf Jahre sichtbar bleiben. Damit entsteht ein vom konkreten Vergabeverfahren getrenntes regulatorisches Vorprüfsystem.

Die eigentliche Risikozuweisung erfolgt dann nach Artikel 29. Mitgliedstaaten und Unionsstellen sollen erstmals binnen eines Jahres nach Inkrafttreten und danach grundsätzlich alle zwei Jahre oder bei Bedarf prüfen, welche Cloud nutzenden öffentlichen Tätigkeiten zur Wahrung der öffentlichen Ordnung beitragen. Erfasst werden Tätigkeiten in den Sektoren der Anhänge I und II der NIS2 sowie in ausdrücklich genannten Bereichen wie nationale und innere Sicherheit, Außengrenzen, Verteidigung, Justiz und Strafverfolgung. Zu berücksichtigen sind mindestens Sensitivität, Kritikalität und Umfang nicht personenbezogener Daten, Art und Kontext personenbezogener Daten und Risiken für Grundrechte, Risiken rechtswidriger Drittstaatenzugriffe sowie Auswirkungen einer Dienstunterbrechung.

Die Kommission soll per Durchführungsrechtsakt Methodik, Vorlagen und Elemente dieser Prüfungen präzisieren. Besonders wichtig für die Kompetenzverteilung ist Artikel 29 Absatz 5: Hält die Kommission das von einem Mitgliedstaat vorgesehene Assurance Level in Bezug auf die öffentliche Ordnung für ungeeignet oder unzureichend, sieht der Entwurf einen weiteren Durchführungsrechtsakt zur Festlegung des erforderlichen Levels vor. Der Mitgliedstaat trifft also die Ausgangsentscheidung, besitzt aber nach dem vorgeschlagenen Modell nicht in jedem Fall das letzte Wort über das Beschaffungsniveau.

Artikel 30 übersetzt diese Risikoentscheidung in das Beschaffungsrecht. Für Cloud-Dienste zum „exclusive use“ der erfassten öffentlichen Stellen gilt: Tätigkeiten, die nach Artikel 29 nicht als zur Wahrung der öffentlichen Ordnung beitragend identifiziert wurden, sollen grundsätzlich Dienste mit Anerkennung auf Level 1 nutzen. Für entsprechend identifizierte Tätigkeiten in den genannten Sektoren und Sicherheitsbereichen dürfen grundsätzlich nur anerkannte Dienste der Level 2, 3 oder 4 beschafft werden. Der Begriff „exclusive use“ ist dabei für die praktische Reichweitenbestimmung bedeutsam; seine Anwendung auf komplexe Shared-Service-, Rahmenvertrags- und Multi-Tenant-Konstellationen wird im Entwurf nicht in einer Weise operationalisiert, die alle Grenzfälle vorab beseitigt.

Artikel 30 Absatz 4 hält allerdings eine Ausnahme offen. Eine Vergabestelle kann ausnahmsweise und mit ordnungsgemäßer Begründung vom Anerkennungserfordernis abweichen, wenn der Beschaffungsgegenstand von keinem im zentralen Register verfügbaren anerkannten Dienst erbracht werden kann und keine angemessene oder vergleichbare Alternative besteht, wenn eine vergleichbare Beschaffung im Vorjahr keine geeigneten Angebote beziehungsweise Teilnehmer hervorgebracht hat oder wenn die Anwendung der Vorgabe unverhältnismäßige Kosten verursachen würde.

Die erste Alternative darf nicht darauf beruhen, dass die Vergabestelle ihre Anforderungen künstlich so verengt hat, dass kein anerkannter Dienst mehr passt.

Damit liegt ein erheblicher Teil der späteren gerichtlichen und administrativen Prüfbarkeit in der Akte, nicht in einem abstrakten Sicherheitslabel. Ein belastbarer Vorgang müsste nachvollziehbar machen, welche Tätigkeit Artikel 29 zugeordnet wurde, welche Risikoindikatoren bewertet wurden, welches Assurance Level daraus folgte, welcher Registerstand bei Ausschreibungsbeginn maßgeblich war und – bei Nutzung von Artikel 30 Absatz 4 – welche Marktprüfung und Kostenanalyse die Ausnahme stützen. Diese Anforderungen ergeben sich analytisch aus der Struktur von Artikeln 29 und 30: Je größer der Entscheidungsspielraum, desto wichtiger wird die dokumentierte Verbindung zwischen festgestelltem Risiko, gewähltem Level und konkreter Beschaffung.

Entscheidungsstufe Wer entscheidet? Maßgeblicher Nachweis Folge
Risikoklassifizierung, Art. 29 Mitgliedstaat bzw. Unionsstelle; Kommission mit methodischen und gegebenenfalls korrigierenden Durchführungsbefugnissen Risikoanalyse zu Daten, Drittstaatenzugriff, Kritikalität und Betriebsunterbrechung Bestimmt das erforderliche Assurance Level.
Anerkennung, Art. 17–22 Nationale zuständige Behörde des Niederlassungsstaats; Auditorganisationen liefern je nach Level Nachweise; Kommission hat im vorgesehenen Kooperationsmechanismus eine Rolle Kriterien des Anhangs II, Audit-/Konformitätsnachweise, Registereintrag Dienst erhält – oder verliert – unionsweit relevante Anerkennung.
Zulassung zur Beschaffung, Art. 30 Öffentlicher Auftraggeber wendet die Risikoeinstufung und den Registerstatus an Erforderliches Level + anerkannter Dienst; gegebenenfalls dokumentierte Ausnahme Nicht anerkannter beziehungsweise zu niedrig anerkannter Dienst ist grundsätzlich nicht beschaffbar, sofern keine Ausnahme greift.
Qualitätswertung, Art. 32 Öffentlicher Auftraggeber Vorab veröffentlichte, auftragsbezogene nicht preisbezogene Kriterien Kann die Rangfolge zulässiger Angebote beeinflussen, darf aber nicht entscheidend sein.

Der Ablauf lässt sich deshalb als Kette und nicht als einheitliches Souveränitätssiegel verstehen:

flowchart TD
    A[Art. 29: öffentliche Tätigkeit und Risiko bestimmen] --> B[Erforderliches Union Assurance Level]
    C[Art. 17–22: Dienst anerkennen und im Register führen] --> D{Anerkennung erreicht erforderliches Level?}
    B --> D
    D -->|Ja| E[Art. 30: Dienst passiert das Beschaffungstor]
    D -->|Nein| F{Art. 30 Abs. 4: eng begründete Ausnahme?}
    F -->|Nein| G[Dienst für diese Beschaffung grundsätzlich nicht zulässig]
    F -->|Ja| E
    E --> H{Innovative Cloud-/KI-Beschaffung?}
    H -->|Ja| I[Art. 32: europäischer Mehrwert als zusätzlicher Qualitätsfaktor]
    H -->|Nein| J[Zuschlag nach sonstigem Vergaberecht]
    I --> K[Gesamtwertung: Technik, Preis und weitere zulässige Kriterien]
    J --> K

Artikel 32 beginnt erst hinter diesem Tor. Nach Absatz 1 müssen Auftraggeber bei Vergabeverfahren für innovative Cloud-Computing-Dienste und KI-Systeme nicht preisbezogene Kriterien verwenden, mit denen sich der Beitrag des Bieters zur Entwicklung eines europäischen Cloud- und KI-Ökosystems bewerten lässt. Absatz 2 setzt vier Sicherungen: Auftragsbezug, kein unbeschränktes Ermessen, ausdrückliche Bekanntgabe in Vergabeunterlagen oder Bekanntmachung und eine nur ergänzende, nicht entscheidende Rolle.

Absatz 3 konkretisiert, was bewertet werden kann: Stärkung der digitalen Lieferkette in der Union, einschließlich in der Union entwickelter oder hergestellter Software und Hardware; Integration in der Union entwickelter Technologien und EU-finanzierter Forschungsergebnisse; innovationsbedingte Stärkung von Versorgungssicherheit und Ökosystem; sowie, soweit Marktverfügbarkeit und technische Anforderungen es erlauben, Nutzung kritischer Rechen-, Speicher- und Netzwerkhardware, die in der Union entwickelt beziehungsweise hergestellt wurde.

Ist dies nicht machbar, kann auch Drittstaatenhardware berücksichtigt werden, sofern sie zur Versorgungssicherheit und zum Ökosystem beiträgt. Schon dieser letzte Punkt zeigt, dass Artikel 32 kein generelles Herkunftsverbot für Drittstaatentechnik ist.

Eine wichtige Auslegungsfrage ergibt sich aus dem Verhältnis von Erwägungsgrund 67 und Artikel 32. Der Erwägungsgrund spricht allgemeiner von öffentlichen Beschaffungsverfahren für Cloud-Dienste und KI-Systeme und schlägt als denkbare Obergrenze 15 von 120 Punkten für den europäischen Mehrwert vor. Der operative Artikel 32 Absatz 1 nennt demgegenüber ausdrücklich „innovative“ Cloud-Dienste und KI-Systeme. Für die Reichweite der gesetzlichen Verpflichtung ist der operative Tatbestand entscheidend; ein Erwägungsgrund kann die Norm erläutern, aber nicht ihre tatbestandliche Grenze durch eine breitere Formulierung ersetzen.

Ebenso wenig macht der Vorschlag die 15 Punkte zu einer verbindlichen Gewichtung. Artikel 32 enthält keine festgelegte Quote; eine verpflichtende Punktzahl ist im Normtext nicht spezifiziert. Gerade deshalb ist die Stellungnahme des Europäischen Wirtschafts- und Sozialausschusses vom 23. September 2026 politisch relevant, rechtlich aber sauber einzuordnen: Der EWSA verlangt ein deutlich stärkeres Gewicht des „Union added value“-Kriteriums; seine begleitende amtliche Kommunikation nennt 40 von 120 Punkten. Das ist eine Empfehlung im laufenden Gesetzgebungsverfahren, keine Änderung des CADA-Vorschlags und erst recht kein geltendes Vergaberecht.

Sollte der Gesetzgeber eine solche erhebliche Gewichtung übernehmen, würde sich zugleich die Auslegungsfrage verschärfen, wann ein Kriterium noch „ancillary and not decisive“ ist. Das ist keine Aussage, dass 40 Punkte automatisch rechtswidrig wären. Es ist vielmehr ein strukturelles Spannungsfeld: Je stärker das europäische Mehrwertkriterium den mathematischen Zuschlagsausgang beeinflussen kann, desto größer wird der Begründungsbedarf dafür, dass technische und finanzielle Kernkriterien tatsächlich primär bleiben.

Grundlage dieser Bewertung sind die ausdrückliche Begrenzung in Artikel 32 Absatz 2 Buchstabe d und die Erläuterung des Erwägungsgrunds 67.

Regelungsarchitektur, Reichweite und Rechtsrahmen

CADA würde nicht im regulatorischen Vakuum wirken. Der Vorschlag ist ausdrücklich als Ergänzung eines bereits dichten EU-Digitalrechts angelegt. Das ist für Compliance entscheidend: Eine CADA-Anerkennung wäre weder ein DSGVO-Zertifikat noch ein Freibrief nach NIS2, Data Act, AI Act, DMA oder DSA. Umgekehrt genügt die Compliance mit diesen Rechtsakten nicht automatisch für ein Union Assurance Level. Die Regime beantworten unterschiedliche Fragen.

Rechtsregime Kernfrage Überschneidung mit CADA Entscheidend verbleibender Unterschied
DSGVO Darf und wie darf personenbezogen verarbeitet werden? Art. 29 CADA berücksichtigt ausdrücklich Art, Kontext und Grundrechtsrisiken personenbezogener Daten; Cloud-Verträge berühren Auftragsverarbeitung und Sicherheit. CADA-Anerkennung ersetzt weder Art. 28 DSGVO noch die Sicherheitsprüfung nach Art. 32, eine erforderliche DSFA nach Art. 35 oder die Regeln für Drittlandübermittlungen in Kapitel V.
Data Act Wechsel zwischen Datenverarbeitungsdiensten und Schutz nicht personenbezogener Daten vor unionsrechtswidrigem Drittstaatenzugriff Beide Regime adressieren Lock-in, Portabilität, Kontinuität und Drittstaatenrisiken. Art. 23 ff. Data Act regeln Switching; Art. 32 Data Act verpflichtet Anbieter zu technischen, organisatorischen und rechtlichen Maßnahmen gegen konfliktträchtigen Drittstaatenzugriff. Der Data Act schafft aber nicht das CADA-Beschaffungstor.
NIS2 Cyber-Risikomanagement und Resilienz bestimmter wesentlicher und wichtiger Einrichtungen CADA übernimmt die Cloud-Definition und knüpft Art. 29 an die NIS2-Sektoren an. CADA erweitert die Betrachtung von technischer Cybersicherheit auf Souveränität, Abhängigkeit, Drittstaatenkontrolle und öffentliche Beschaffungsfähigkeit.
AI Act Entwicklung, Bereitstellung und Nutzung von KI-Systemen und -Modellen CADA übernimmt die Definition des KI-Systems; Art. 32 kann innovative KI-Beschaffung erfassen. CADA ersetzt die risikobasierten Produkt- und Betreiberpflichten des AI Act nicht; seine Autonomieregeln richten sich vor allem auf Infrastruktur, Cloud und Beschaffung.
DMA Faire und bestreitbare digitale Märkte bei benannten Gatekeepern Cloud-Computing ist nach Art. 2 DMA ein zentraler Plattformdienst. DMA greift nur nach Gatekeeper-Benennung und adressiert Marktmacht beziehungsweise Bestreitbarkeit; CADA arbeitet mit Assurance Levels und öffentlicher Nachfrage.
DSA Pflichten für Vermittlungs-, Hosting- und Plattformdienste Bestimmte Cloud-Funktionen können als Hosting-Dienst ein Vermittlungsdienst sein. Infrastruktur-Cloud ist nicht allein deshalb eine Online-Plattform; der DSA konzentriert sich auf Vermittlung und Inhalte, CADA auf Kapazität, Autonomie und Beschaffung.
EU-/deutsches Vergaberecht Wettbewerb, Transparenz, Gleichbehandlung, Verhältnismäßigkeit und Zuschlagswertung Art. 32 übernimmt zentrale Schutzlogiken des Art. 67 der Richtlinie 2014/24/EU: Auftragsbezug und kontrollierbares Ermessen. CADA würde zusätzliche sektorspezifische Kriterien und ein vorgeschaltetes Assurance-Regime schaffen. In Deutschland bleiben insbesondere die Grundsätze des § 97 GWB relevant.

Beim Datenschutz ist insbesondere eine Fehlinterpretation zu vermeiden. Artikel 29 CADA würde zwar Drittstaatenzugriff und personenbezogene Daten ausdrücklich in die Cloud-Risikoprüfung einbeziehen. Ein anerkanntes CADA-Angebot bliebe aber unter der DSGVO ein normal zu prüfendes Verarbeitungsszenario. Der öffentliche Verantwortliche müsste weiterhin einen tragfähigen Auftragsverarbeitungsvertrag nach Artikel 28 gewährleisten, ein risikoadäquates Sicherheitsniveau nach Artikel 32 bestimmen und gegebenenfalls eine Datenschutz-Folgenabschätzung durchführen.

Für Drittlandübermittlungen gelten weiterhin die Artikel 44 ff.; Artikel 48 DSGVO enthält zudem eine eigenständige Schranke für bestimmte nicht unionsrechtlich legitimierte Entscheidungen von Drittstaatsbehörden.

Beim Data Act besteht eine besonders praktische Komplementarität. Dessen Kapitel VI verpflichtet Anbieter von Datenverarbeitungsdiensten dazu, Hindernisse für effektives Switching abzubauen und ermöglicht auch Multi-Provider-Nutzung; Artikel 32 Data Act adressiert rechtswidrigen internationalen Behördenzugriff auf in der Union gehaltene nicht personenbezogene Daten. CADA Artikel 29 Absatz 9 verlangt seinerseits, in der Risikobewertung zu prüfen, ob eine Multi-Vendor- oder Multi-Cloud-Strategie angemessen ist. CADA macht Multi-Cloud damit nicht pauschal verpflichtend, sondern zu einer kontextbezogenen Risikooption.

DMA und CADA dürfen schon begrifflich nicht verwechselt werden. Der DMA bezeichnet bestimmte benannte Unternehmen als „Gatekeeper“ und zählt Cloud-Computing zu den möglichen zentralen Plattformdiensten; CADA errichtet dagegen ein Beschaffungstor für Dienste, das von der Sensitivität der öffentlichen Tätigkeit und der Anerkennungsstufe abhängt. Ein Cloud-Anbieter kann deshalb regulatorisch unter beide Regime fallen, ohne dass die Einstufung im einen automatisch die Rechtsfolge des anderen auslöst. Die Kommission selbst beschreibt die Zielsetzungen als komplementär: DMA zielt auf faire und bestreitbare Märkte, CADA unter anderem auf Nutzung, Resilienz und Autonomie.

Auch das DSA-Verhältnis ist enger, als der gemeinsame Begriff „Cloud“ vermuten lässt. Der DSA erfasst Vermittlungsdienste und insbesondere Hosting-Dienste, stellt aber ausdrücklich klar, dass Cloud- oder Webhosting-Infrastruktur nicht schon deshalb als Online-Plattform gilt, weil eine öffentliche Informationsverbreitung lediglich eine untergeordnete Nebenfunktion ist. Die CADA-Frage ist somit nicht, ob der Cloud-Anbieter illegale Inhalte moderiert, sondern unter anderem, ob seine Infrastruktur- und Kontrollstruktur für eine bestimmte öffentliche Nutzung das erforderliche Assurance Level erreicht.

Für das allgemeine Vergaberecht ist Artikel 32 dagegen unmittelbar anschlussfähig. Artikel 67 der Richtlinie 2014/24/EU verankert die Zuschlagsentscheidung anhand des wirtschaftlich günstigsten Angebots und verlangt bei qualitativen Kriterien eine Verbindung zum Auftragsgegenstand. In Deutschland verlangt § 97 GWB Wettbewerb, Transparenz, Wirtschaftlichkeit, Verhältnismäßigkeit und grundsätzlich Gleichbehandlung; Qualität und Innovation dürfen berücksichtigt werden, und Unternehmen haben einen Anspruch auf Einhaltung der Vergabebestimmungen.

Ein später verbindlicher CADA könnte besondere unionsrechtliche Vorgaben hinzufügen, beseitigte aber nicht die Notwendigkeit, sie transparent und verhältnismäßig in das bestehende Vergabesystem einzubauen.

Das ist auch wettbewerbsrechtlich relevant. Der CADA-Vorschlag schafft keine allgemeine Ausnahme von den Markt- und Wettbewerbsregeln für europäische Anbieter und auch keinen pauschalen Ausschluss ausländischer Wettbewerber. Gerade Artikel 32 verlangt die Verbindung mit dem konkreten Auftragsgegenstand und verbietet unbeschränkte Wahlfreiheit. Erwägungsgrund 63 des Vorschlags erinnert darüber hinaus an internationale Beschaffungsverpflichtungen.

Die spätere Ausgestaltung der Gewichtung, die Definition geeigneter Nachweise und der Umgang mit globalen Lieferketten werden daher darüber entscheiden, ob das Instrument als präzise Resilienzregel oder als faktisch herkunftsbezogene Marktabschottung wirkt.

Bei der Durchsetzung ist ebenfalls zwischen den Regelungsschichten zu unterscheiden. Artikel 24 verpflichtet die Mitgliedstaaten, für Verstöße von Cloud-Anbietern gegen das betreffende CADA-Kapitel wirksame, verhältnismäßige und abschreckende Sanktionen festzulegen. Zu berücksichtigen sind unter anderem Schwere, Umfang und Dauer des Verstoßes, Abhilfemaßnahmen, frühere Verstöße, wirtschaftliche Vorteile und der unionsweite Jahresumsatz. Eine unionsweit harmonisierte feste Bußgeldobergrenze ist im Vorschlag nicht spezifiziert. Empfänger von Cloud-Diensten sollen nach Unions- und nationalem Recht Ersatz für Schäden oder Verluste verlangen können, die auf entsprechenden Pflichtverstößen beruhen.

Artikel 25 verlangt grundsätzlich binnen eines Jahres nach Inkrafttreten die Benennung einer oder mehrerer nationaler zuständiger Behörden für dieses Kapitel. Für die Überwachung eines Cloud-Anbieters soll grundsätzlich der Mitgliedstaat seiner Hauptniederlassung ausschließlich zuständig sein. Artikel 26 sieht Ermittlungsbefugnisse einschließlich Informationsanforderungen vor. Das ist ein anderes Durchsetzungssystem als der vergaberechtliche Rechtsschutz gegen eine fehlerhafte Ausschreibung oder Wertung durch den öffentlichen Auftraggeber. Für Verstöße eines Auftraggebers gegen Artikel 30 oder 32 enthält Artikel 24 gerade kein allgemeines CADA-Bußgeldschema; die CADA-spezifische Geldbuße für eine fehlerhafte Zuschlagsmatrix ist daher nicht spezifiziert. Vergaberechtliche Kontroll- und Rechtsschutzmechanismen bleiben daneben maßgeblich.

Ereignis Frist im Kommissionsvorschlag Einordnung am 16.10.2026
Inkrafttreten, Art. 48 20. Tag nach Veröffentlichung des endgültigen Rechtsakts im Amtsblatt Noch nicht ausgelöst; CADA ist nicht angenommen oder als endgültige Verordnung veröffentlicht.
Allgemeine Anwendung, Art. 48 Ein Jahr nach Inkrafttreten Konkretes Kalenderdatum nicht spezifiziert, solange Annahme und Veröffentlichung fehlen.
Nationale zuständige Behörden, Art. 25 Spätestens ein Jahr nach Inkrafttreten Relative Vorbereitungsfrist; noch nicht laufend.
Erste Risikobewertungen, Art. 29 Abs. 1 Binnen eines Jahres nach Inkrafttreten; danach grundsätzlich alle zwei Jahre oder bei Bedarf Noch nicht laufend.
Migration nach geänderter Risikobewertung, Art. 29 Abs. 6 Angemessener Übergang, höchstens zwölf Monate Nur wenn die Risikobewertung einen Wechsel erfordert; technische Machbarkeit, Kontinuität und Portabilität sind zu berücksichtigen.
Übergang allein wegen späterem Anerkennungswiderruf Nicht spezifiziert als eigenständige, Art. 29 Abs. 6 entsprechende Frist Ein wesentlicher Punkt für Vertrags- und Exit-Gestaltung. Art. 22 regelt die Publikation von Widerrufen, aber nicht dieselbe ausdrückliche Zwölfmonatsregel.

Umsetzung: Nachweise, Risiken und Compliance

Für Cloud-Anbieter sollte die Vorbereitung – ohne vorwegzunehmen, dass der Text unverändert verabschiedet wird – in zwei getrennten Nachweisakten gedacht werden. Die erste ist eine Assurance-Akte: Gesellschafts- und Kontrollstruktur, Standorte von Infrastruktur und Assets, Datenflüsse einschließlich Metadaten und Telemetrie, Subunternehmer und Supportketten, Drittstaatenbezüge, Software- und Hardwareabhängigkeiten, Remote-Zugriffsmöglichkeiten, Auditnachweise sowie Migrations- und Kontinuitätsmechanismen. Diese Akte beantwortet die Artikel-17-bis-30-Frage: Ist der konkrete Dienst für die angestrebte öffentliche Nutzung anerkennungsfähig und beschaffbar?

Daneben gehört eine Artikel-32-Angebotsakte. Sie sollte konkret belegen, welche Teile der digitalen Lieferkette in der Union entwickelt oder hergestellt werden, welche europäischen Technologien, Standards, Softwarekomponenten, Modelle oder EU-finanzierten Forschungsergebnisse eingebunden sind und wie die Architektur Versorgungssicherheit erhöht. Wo europäische kritische Hardware technisch oder marktseitig nicht verfügbar ist, sollte gerade diese Nichtverfügbarkeit dokumentiert werden, weil Artikel 32 Absatz 3 ausdrücklich mit Marktverfügbarkeit und technischer Machbarkeit arbeitet. Ein bloßes Unternehmenssitz- oder Herkunftsetikett beantwortet diese Kriterien nicht.

Öffentliche Stellen benötigen spiegelbildlich eine Entscheidungsakte. Sie sollte die Artikel-29-Risikoklassifizierung, das daraus abgeleitete Assurance Level, einen aktuellen Registerabgleich, die Prüfung möglicher Ausnahmen nach Artikel 30 Absatz 4 sowie – bei Artikel 32 – die sachliche Verbindung jedes europäischen Mehrwertkriteriums mit dem Auftragsgegenstand, Gewichtung und Bewertungsmethode enthalten. Entscheidend ist die Trennung der Prüfphasen: Eine Zuschlagsmatrix sollte nicht nachträglich ein fehlendes Assurance Level „kompensieren“, und die Anerkennung sollte umgekehrt keine zusätzlichen Wertungspunkte erhalten, wenn diese Wertung nicht transparent als eigenes, rechtmäßiges Kriterium ausgestaltet wurde.

Für Datenschutz-, Informationssicherheits-, Beschaffungs- und Rechtsabteilungen folgt daraus ein gemeinsames Governance-Erfordernis. Dieselbe Cloud-Architektur muss parallel unter CADA, DSGVO, Data Act, NIS2 und – bei KI-Leistungen – AI Act geprüft werden, aber die Prüfergebnisse dürfen nicht ineinander aufgehen. Ein sinnvoller Kontrollsatz verknüpft beispielsweise den CADA-Nachweis über Daten- und Infrastrukturstandorte mit dem DSGVO-Auftragsverarbeitungsverzeichnis und Transfer-Mapping, den Data-Act-Switching-Klauseln sowie dem technischen Continuity- und Exit-Plan.

Die größte operative Rechtsunsicherheit liegt weniger in der abstrakten Existenz von vier Assurance Levels als in ihren Grenzfällen und dynamischen Veränderungen. Nicht abschließend geklärt ist etwa, wie „exclusive use“ in komplexen gemeinsamen Plattformen abzugrenzen ist; wann eine Beschaffung hinreichend „innovativ“ ist, damit Artikel 32 zwingend greift; welche Gewichtung praktisch noch „ancillary and not decisive“ bleibt; wie feingranular europäische Herkunft bei global zusammengesetzten Hardware- und Softwareketten nachzuweisen ist; und welche konkrete Bestandsvertragsfolge ein nachträglicher Verlust der Anerkennung auslöst. Wo der Vorschlag keine eindeutige Spezialregel enthält, sollte die Antwort ausdrücklich als nicht spezifiziert behandelt werden statt durch Compliance-Praxis vorweg erfunden zu werden.

Ein zweites Risiko ist institutionell: Artikel 29 verteilt Entscheidungsmacht zwischen Mitgliedstaaten und Kommission. Mitgliedstaaten kennen ihre öffentlichen Aufgaben und Sicherheitslagen; die Kommission soll durch Methodik und gegebenenfalls Korrektur eines unzureichenden Assurance Levels unionsweite Konsistenz sichern. Je sensibler die Tätigkeit, desto wichtiger wird deshalb die Grenze zwischen Binnenmarkt- beziehungsweise Beschaffungsregulierung und den Sicherheitszuständigkeiten der Mitgliedstaaten.

Der Vorschlag selbst versucht diese Spannung durch risikobasierte nationale Ausgangsbewertung und unionsweite Konsistenzmechanismen zu bearbeiten; ob Parlament und Rat diese Balance unverändert übernehmen, ist offen.

Ein drittes Risiko betrifft Kontinuität. Artikel 29 Absatz 6 verlangt bei einer durch die Risikoprüfung notwendig werdenden Migration einen angemessenen, höchstens zwölfmonatigen Übergang und nennt ausdrücklich technische Machbarkeit, Dienstkontinuität und Datenportabilität. Dieser Schutzmechanismus macht deutlich, dass „Souveränität“ im Vorschlag nicht nur eine Frage der Jurisdiktion, sondern auch der Fähigkeit ist, einen Anbieterwechsel durchzuführen, ohne einen kritischen öffentlichen Dienst zu verlieren.

Das korrespondiert mit den Switching-Regeln des Data Act und spricht für vorab getestete Exit-Pläne statt nur vertraglicher Exit-Klauseln.

Der aktuelle Gesetzgebungsstand begrenzt jede Prognose. Das Legislative Observatory des Europäischen Parlaments führt 2026/0138(COD) am 16. Oktober 2026 als „Awaiting committee decision“. Zuständig sind im Parlament gemeinsam ITRE und IMCO; die Ausschussbefassung wurde im September 2026 formell angezeigt. Der Rat hat den Vorschlag auf Arbeitsebene behandelt, doch die für Unternehmen relevante Rechtslage ist weiterhin der Kommissionsvorschlag als Verhandlungsgrundlage, nicht eine verabschiedete Verordnung.

Der EWSA-Beschluss vom 23. September ist deshalb als politischer Änderungsindikator zu lesen. Neben der stärkeren Gewichtung des europäischen Mehrwerts befürwortet der Ausschuss eine ambitioniertere Rolle innovativer KMU. Artikel 33 des Kommissionsvorschlags sieht bereits vor, dass Mitgliedstaaten die Innovationsbeschaffung beobachten, jährlich Bericht erstatten und als Ziel verfolgen, mindestens 25 Prozent ihrer Beschaffung von Cloud-Diensten und KI-Systemen an innovative KMU zu vergeben. Die Formulierung ist im Vorschlag ein zu verfolgendes Ziel und keine automatisch sanktionierte starre Zuschlagsquote; auch hier will der EWSA weiter gehen.

Für Compliance-Verantwortliche folgt daraus eine nüchterne Strategie: Noch keine Systeme so umbauen, als sei COM(2026) 502 bereits geltendes Recht, aber die schwer reversiblen Fakten früh kartieren. Gesellschaftskontrolle, Daten- und Supportpfade, Subunternehmerketten, Hardwareherkunft, Softwareabhängigkeiten und getestete Exit-Fähigkeit lassen sich wesentlich langsamer verändern als eine Vergabeklausel.

Gerade weil Artikel 48 nach dem aktuellen Entwurf nur ein Jahr zwischen Inkrafttreten und allgemeiner Anwendung vorsieht, wäre eine belastbare Bestandsaufnahme eine rationale Vorbereitung, ohne das Ergebnis des Gesetzgebungsverfahrens vorwegzunehmen.

Wichtigste Primärquellen