Am 3. Juni 2026 hat die Europäische Kommission den Entwurf des Cloud and AI Development Act vorgelegt. Der Verordnungsvorschlag führt erstmals ein EU-weit harmonisiertes Souveränitätsframework für Cloud-Dienste ein und verbindet es mit verbindlichen Beschaffungsvorgaben für den öffentlichen Sektor. Für Hersteller, die Cloud-Backends betreiben oder kritische Infrastrukturen beliefern, lohnt ein genauer Blick.
Der Cloud and AI Development Act ist ein Verordnungsvorschlag der EU-Kommission zur Stärkung des europäischen Cloud- und KI-Ökosystems. Er kombiniert Fördermaßnahmen für Forschung und Rechenzentrumsausbau mit einem Souveränitätsframework aus vier Union Assurance Levels, das festlegt, welche Cloud-Dienste der öffentliche Sektor künftig nutzen darf. Die Verordnung soll ein Jahr nach Inkrafttreten anwendbar werden.
Warum legt die Kommission den Entwurf vor?
Die Begründung des Entwurfs ist deutlich: Drei außereuropäische Hyperscaler kontrollieren über 70 Prozent des europäischen Cloud-Marktes, während der Marktanteil europäischer Anbieter von 29 Prozent (2017) auf 15 Prozent (2022) gefallen ist und seither stagniert. Die Kommission sieht darin Risiken für Datenhoheit, Betriebskontinuität und öffentliche Ordnung, insbesondere durch extraterritorial wirkende Drittstaatengesetze, die Datenzugriffe ermöglichen oder Dienste unterbrechen könnten.
Der Entwurf reagiert mit einem Bündel aus drei Stoßrichtungen: angebotsseitige Förderung (Cloud and AI Leadership Initiatives, Rechenzentrums-Beschleunigungszonen mit maximal zwölf Monaten Genehmigungsdauer), nachfrageseitige Maßnahmen (Beschaffungspflichten, EuroCloud Federation für den öffentlichen Sektor) und das Souveränitätsframework als verbindendes Element.
Wie funktioniert das Souveränitätsframework?
Kern des Entwurfs ist Titel IV. Artikel 16 etabliert vier Union Assurance Levels, deren kumulative Kriterien Anhang II festlegt. Die Stufen unterscheiden sich vor allem in drei Dimensionen: Niederlassung und Datenlokalisierung, Kontrolle durch Drittstaaten und Nachweisverfahren.
- Level 1 verlangt Niederlassung in der EU, Infrastruktur und Kundendaten in der EU sowie Transparenz über Subunternehmer. Der Nachweis erfolgt per Konformitätsselbstbewertung mit EU-Konformitätserklärung (Artikel 19).
- Level 2 ergänzt unabhängige Drittaudits, Anforderungen an die Software-Lieferkette inklusive SBOM und ein Cybersicherheitszertifikat mindestens der Stufe „substanziell”. Drittstaatenkontrolle bleibt zulässig, wenn rechtliche, technische und organisatorische Schutzmaßnahmen Datenzugriffe und Dienstunterbrechungen verhindern.
- Level 3 schließt Anbieter unter Drittstaatenkontrolle grundsätzlich aus. Eine Ausnahme gilt nur für Drittstaaten, die die Kommission per Durchführungsrechtsakt nach Artikel 18 anerkannt hat, unter anderem auf Basis eines DSGVO-Angemessenheitsbeschlusses und gegenseitigen Marktzugangs.
- Level 4 verlangt vollständige Freiheit von Drittstaatenkontrolle ohne Ausnahmemöglichkeit, EU-Staatsbürgerschaft des Personals und ein Cybersicherheitszertifikat der Stufe „hoch”. Level 3 und 4 sollen auch das Hosting von EU-Verschlusssachen ermöglichen.
Das Anerkennungsverfahren läuft über die nationale Behörde am Hauptsitz des Anbieters). Eine erteilte Anerkennung gilt EU-weit und wird in einem öffentlichen zentralen Register erfasst.Für Level 2 bis 4 ist eine jährliche Überprüfung des Auditberichts vorgesehen.
Bemerkenswert ist die Verzahnung mit bestehenden Rechtsakten: Anhang II übernimmt die SBOM-Definition des Cyber Resilience Act und verweist beim Zertifizierungsnachweis auf ein künftiges europäisches Zertifizierungsschema für Cloud-Dienste nach dem Cybersecurity Act. Die Kommission kündigt im Entwurf ausdrücklich an, die Arbeiten am lange blockierten EUCS-Schema wieder aufzunehmen. Bis dahin gelten nationale Schemata oder, wo keine existieren, der Nachweis höchster marktüblicher Cybersicherheitsstandards.
Wer muss die Union Assurance Levels künftig nutzen?
Mitgliedstaaten und EU-Einrichtungen müssen binnen eines Jahres nach Inkrafttreten Risikobewertungen durchführen und festlegen, welche öffentlichen Tätigkeiten welche Assurance Levels erfordern. Für die Beschaffung gilt dann eine zweistufige Logik: Alle öffentlichen Stellen müssen mindestens Level-1-Dienste nutzen. Auftraggeber, deren Tätigkeiten als relevant für die öffentliche Ordnung eingestuft wurden, etwa in den NIS-2-Sektoren, bei Verteidigung, Justiz oder Strafverfolgung, dürfen nur noch Dienste der Levels 2 bis 4 beschaffen. Ausnahmen sind eng gefasst, etwa wenn kein geeigneter anerkannter Dienst verfügbar ist.
Für die Privatwirtschaft ist der Entwurf zunächst zurückhaltend: Unternehmen der NIS-2-Sektoren mit hoher Kritikalität (Anhang I) können vergleichbare Impact Assessments freiwillig durchzuführen. Die Kommission kann solche Bewertungen samt Risikominderungsmaßnahmen jedoch per delegiertem Rechtsakt verpflichtend machen. Der Grund dafür ist klar benannt: Beschaffungsanforderungen des öffentlichen Sektors werden erfahrungsgemäß von regulierten Branchen gespiegelt und verschieben den Markt insgesamt.
Hinzu kommen Vergabekriterien mit europäischem Mehrwert: Bei der Beschaffung innovativer Cloud-Dienste und KI-Systeme sollen Auftraggeber bewerten, inwieweit Anbieter zur europäischen Lieferkette beitragen, etwa durch in der EU entwickelte Software oder Hardware. Das Kriterium bleibt ausdrücklich nachrangig gegenüber technischen und finanziellen Kriterien.
Was bedeutet der Entwurf für Hersteller?
Hersteller im Maschinen-, Anlagen- und Gerätebau sind vom Cloud and AI Development Act nicht unmittelbar adressiert, aber auf zwei Wegen betroffen.
Erstens über die Kundenkette: Ein Hersteller von Pumpensystemen mit Cloud-Plattform für Monitoring und Fernwartung, dessen Kunden Wasserversorger sind, liefert an Betreiber, die unter NIS 2 Anhang I fallen. Stufen deren Risikobewertungen die Versorgungstätigkeit als relevant für die öffentliche Ordnung ein, dürfen diese Betreiber künftig nur noch anerkannte Cloud-Dienste der Levels 2 bis 4 nutzen. Die Frage, auf welcher Cloud-Infrastruktur das Hersteller-Backend läuft, wird damit zum Beschaffungskriterium beim Kunden, nicht erst zur technischen Detailfrage.
Zweitens über die eigene Cloud-Strategie: Wer heute ein IoT-Backend auf einem Hyperscaler aufbaut, sollte die Souveränitätsdiskussion in die Architekturentscheidung einbeziehen. Der Entwurf schafft erstmals einen einheitlichen, auditierbaren Maßstab dafür, was „souveräne Cloud” in der EU bedeutet, und beendet damit absehbar den Wildwuchs nationaler Kriterienkataloge und herstellereigener „Sovereign-Cloud”-Angebote, denen die Kommission im Entwurf ausdrücklich attestiert, die Kernprobleme nicht zu lösen.
Der Entwurf geht nun in das ordentliche Gesetzgebungsverfahren von Parlament und Rat. Inhaltliche Änderungen sind zu erwarten, insbesondere bei den Drittstaatenregelungen und den Kriterien in Anhang II. Die Grundarchitektur aus abgestuften Assurance Levels und verbindlicher Beschaffung dürfte jedoch Bestand haben. Die Verordnung soll ein Jahr nach Inkrafttreten gelten, die Risikobewertungen der Mitgliedstaaten folgen im selben Zeitraum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Kommentar hinzufügen