Der Cloud and AI Development Act: Welches Problem Europa damit wirklich lösen will

Der Cloud and AI Development Act zeigt so deutlich wie kein Text zuvor, was europäische Technologiepolitik inzwischen ist. Er ist kein Verbraucherschutzgesetz und kein Sicherheitsgesetz. Er ist Industriepolitik, und er zielt auf ein einziges Problem: Europa betreibt den Großteil seiner digitalen Wirtschaft auf Infrastruktur, die es nicht kontrolliert.

Das ist eine andere Art von Regulierung als die DSGVO oder die KI-Verordnung, und sie erreicht Sie über einen anderen Mechanismus. Zu verstehen, welcher das ist, bringt mehr, als die Erwägungsgründe zu lesen.

Das Problem, auf das er reagiert

Die Zahlen dahinter bestreitet niemand. Der überwiegende Teil der europäischen Cloud-Ausgaben geht an nichteuropäische Anbieter. Die größten KI-Modelle, die europäische Unternehmen einsetzen, werden außerhalb Europas trainiert und betrieben. Die europäische Rechenkapazität ist ein kleiner Bruchteil des weltweiten Bestands.

Ein Jahrzehnt lang galt das als Ergebnis des Marktes. Seit 2022 gilt es als strategische Schwachstelle, und zwar aus Gründen, die mit Technik nichts zu tun haben: Handelskonflikte, Exportkontrollen und die Einsicht, dass Abhängigkeit von fremder Infrastruktur ein Druckmittel ist.

Der Cloud and AI Development Act ist der gesetzgeberische Arm dieser Neubewertung. Er steht neben dem AI Continent Action Plan, der InvestAI-Initiative, dem Programm für KI-Gigafabriken und der breiteren Wettbewerbsagenda, die aus dem Draghi-Bericht hervorgegangen ist.

Was der Vorschlag vorsieht

Die Kommission hat den Vorschlag am 3. Juni 2026 als COM(2026) 502 vorgelegt, zusammen mit einem Chips Act 2.0. Es handelt sich um eine Verordnung, aufgebaut um drei Ziele und eine Reihe von Maßnahmen für den öffentlichen Sektor:

Forschung und Innovation. Cloud and AI Leadership Initiatives für große sektorübergreifende Projekte, ein Netz von AI Experience and Acceleration Centres auf Grundlage der Europäischen Digitalen Innovationszentren, Rechenleistung für vorrangige Projekte im Bereich Frontier-KI und eine nationale Cloud- und KI-Strategie in jedem Mitgliedstaat binnen eines Jahres nach Inkrafttreten.

Rechenzentrumskapazität. Die Mitgliedstaaten weisen Beschleunigungsgebiete für Rechenzentren aus, mit einer einheitlichen Anlaufstelle und schnelleren Genehmigungen, und die Kommission kann strategische Rechenzentrumsprojekte benennen. Erklärtes Ziel ist, die Rechenzentrumskapazität der EU bis 2030 mindestens zu verdreifachen, wobei jede Genehmigung für ein neues Rechenzentrum in weniger als 18 Monaten zu bekommen sein soll.

Ein Souveränitätsrahmen für Cloud. Vier Vertrauenswürdigkeitsstufen der Union. Stufe 1 ist eine Selbstbewertung; die Stufen 2 bis 4 werden von Dritten geprüft. Stufe 3 setzt voraus, dass der Anbieter nicht aus einem Drittland kontrolliert wird, es sei denn, die Kommission hat anerkannt, dass dieses Land ausreichende Garantien bietet. Anerkannte Dienste werden in ein zentrales EU-Verzeichnis aufgenommen.

Einsatz im öffentlichen Sektor. Hier liegt der eigentliche Hebel. Öffentliche Auftraggeber müssen Cloud-Dienste beschaffen, die mindestens auf Stufe 1 anerkannt sind. Ergibt eine Risikobewertung, dass eine Tätigkeit zur öffentlichen Ordnung beiträgt (unter anderem in den NIS2-Sektoren, bei nationaler Sicherheit, Verteidigung, Justiz und Strafverfolgung), sind nur die Stufen 2, 3 oder 4 zulässig. Außerdem müssen die Mitgliedstaaten beim Einkauf von Cloud und KI Kriterien des Unionsmehrwerts anwenden, über eine EuroCloud Federation können öffentliche Stellen Cloud-Dienste gemeinsam nutzen, und öffentliche Stellen müssen den Einsatz von Open Source gegenüber proprietärer Software fördern und erleichtern.

Wenig, was private Käufer bindet. Unternehmen in NIS2-Sektoren können dieselbe Risikobewertung freiwillig durchführen, und die Kommission könnte sie für hochkritische Sektoren per delegiertem Rechtsakt verpflichtend machen. Nach dem Vorschlag gilt die Verordnung ein Jahr nach Inkrafttreten, sie muss aber erst noch durch Parlament und Rat.

Der Mechanismus, der Sie tatsächlich erreicht

Eines sollte man an diesem Dossier verstehen. Die meiste Technologieregulierung erreicht Privatunternehmen direkt: Sie verarbeiten personenbezogene Daten, also gilt die DSGVO. Der Cloud and AI Development Act wird die meisten Unternehmen dagegen sehr wahrscheinlich indirekt erreichen, nämlich über die Beschaffung.

Der öffentliche Sektor der EU gibt gewaltige Summen für Technologie aus. Wenn öffentliche Stellen der Mitgliedstaaten verpflichtet oder nachdrücklich angehalten werden, europäische Cloud einzukaufen, verschiebt das den erreichbaren Markt für jeden Anbieter im öffentlichen Geschäft, und über die Generalunternehmer setzt es sich bis zu deren Zulieferern fort.

Das Muster kennt man aus der Barrierefreiheit. Die Europäische Barrierefreiheitsrichtlinie begründet direkte Pflichten, aber ein Großteil der Arbeit an Barrierefreiheit entstand in der Praxis durch Vergaberegeln, die nicht konforme Anbieter schon lange vor Geltungsbeginn ausgeschlossen haben.

Hier wird es genauso laufen. Wenn Sie Software an europäische öffentliche Auftraggeber verkaufen, wandern die Fragen danach, wo Ihre Infrastruktur läuft, wer sie kontrolliert und ob sie sich migrieren lässt, aus dem Sicherheitsfragebogen in die Eignungskriterien.

Was das für die Architektur bedeutet

Der Reflex beim Lesen einer Souveränitätsagenda ist entweder Ignorieren oder panisches Migrieren. Beides ist falsch. Vernünftig ist, dafür zu sorgen, dass Sie die Frage beantworten können.

Finden Sie heraus, wo Ihre Daten und Ihre Rechenleistung wirklich liegen

Das klingt trivial und ist es nicht. In einem gewachsenen System umfasst die ehrliche Antwort auf „wo läuft das eigentlich“ oft eine primäre Region, eine Backup-Region, ein CDN mit unklaren Edge-Standorten, eine Managed-Datenbank, drei SaaS-Abhängigkeiten mit eigenen Unterauftragsverarbeitern, einen Observability-Anbieter und eine KI-Schnittstelle, deren Inferenzstandort nirgends dokumentiert ist.

Eine saubere Karte zu zeichnen ist die erste echte Arbeit, und es ist dieselbe Karte, die Sie für die DSGVO-Übermittlungsanalyse und für Lieferkettenfragen nach NIS2 brauchen. Machen Sie sie einmal richtig.

Trennen Sie das Portable vom Nichtportablen

Fast jedes System hat einen portablen Kern und daneben eine Reihe anbieterspezifischer Abhängigkeiten. Der portable Kern ist meist die Anwendung selbst. Nichtportabel sind meist die Managed Services: proprietäre Datenbanken, Serverless-Laufzeiten, Queues, Identitätsdienste und zunehmend die Modell-Schnittstellen.

Sie müssen diese Abhängigkeiten nicht beseitigen. Sie müssen nur wissen, welche es sind, denn diese Liste ist die ehrliche Antwort darauf, wie aufwendig eine Migration wäre, und genau danach fragt ein Beschaffungsfragebogen.

Behandeln Sie Modellanbieter als Abstraktionsgrenze

Das ist der jüngste Punkt und der, den die meisten überspringen. Wer die Modell-API eines einzigen Anbieters direkt aufruft und anbieterspezifische Prompt-Formate und Antwortlogik über die ganze Codebasis verteilt, hat unbemerkt eine Abhängigkeitsentscheidung getroffen.

Eine dünne Abstraktion über den Modellaufrufen kostet beim Bauen kaum etwas und verschafft Ihnen die Möglichkeit, auf einen europäischen Anbieter, auf ein Modell mit offenen Gewichten auf europäischer Infrastruktur oder auf einen ganz anderen Anbieter umzuschalten. So schnell wie sich der Modellmarkt bewegt, lohnt sich das schon rein kommerziell.

Testen Sie den Ausstieg, dokumentieren Sie ihn nicht nur

Der Data Act gibt Ihnen bereits ein Recht auf Anbieterwechsel, und ab dem 12. Januar 2027 entfallen die Wechselentgelte vollständig. Nur wenige Kunden nutzen dieses Recht, und noch weniger prüfen, ob der Export, auf den sie Anspruch haben, ihren Dienst tatsächlich wieder zum Laufen bringen würde.

Ziehen Sie den Export einmal. Versuchen Sie, ihn zu lesen. Zwischen dem, was ein Anbieter als exportierbar bezeichnet, und dem, was am Ende brauchbar ist, klafft eine Lücke, und genau dort sitzt der Lock-in. Sie ist zugleich die ehrliche Antwort auf jede Souveränitätsfrage.

Was er nicht ist

Eine gewisse Skepsis ist angebracht, und es ist besser, sich jetzt nichts vorzumachen, als sich später zu wundern.

Das ist kein Verbot amerikanischer Cloud. Nichts im Vorschlag untersagt privaten Unternehmen die Nutzung nichteuropäischer Anbieter. Der Mechanismus heißt Beschaffungspräferenz und Kapazitätsaufbau, nicht Verbot.

Kapazität entsteht nicht, weil ein Gesetz es anordnet. Die europäische Cloud-Kapazität ist begrenzt, weil Rechenzentren zu bauen und Spitzenmodelle zu trainieren kapitalintensiv ist und Europa bis vor Kurzem kein Kapital in der nötigen Größenordnung bereitgestellt hat. Die Förderprogramme aus unserem Leitfaden zur EU-Technologieförderung sind hier das eigentliche Instrument. Das Gesetz ist nur der Rahmen darum.

Ein Souveränitätslabel ist noch keine Souveränität. Etliche Angebote vermarkten sich als souveräne Cloud, laufen aber unter Lizenz auf nichteuropäischer Technologie, mit sehr unterschiedlichen Graden operativer Unabhängigkeit. Die Antwort des Vorschlags sind die Vertrauenswürdigkeitsstufen: Kontrolle aus einem Drittland hält einen Dienst aus Stufe 3 und höher heraus, es sei denn, die Kommission erkennt dieses Land an. Wo die Grenze zwischen Stufe 2 und 3 am Ende verläuft, entscheiden die Verhandlungen.

Es ist ein Vorschlag. Inzwischen liegt ein Text vor, aber Stand 10. Oktober 2026 haben weder Rat noch Parlament eine Position dazu, und im Parlament liegt das Dossier noch bei den Ausschüssen ITRE und IMCO. Am ehesten werden sich die Vertrauenswürdigkeitsstufen noch bewegen. Die Richtung ist seit drei Jahren in jeder Kommissionsäußerung dieselbe.

Wie das mit allem anderen zusammenhängt

Der Cloud and AI Development Act ist Teil eines abgestimmten Vorstoßes, und für sich gelesen wirkt er schwächer, als er ist.

Die KI-Verordnung reguliert, wie sich KI-Systeme verhalten. Der Data Act greift die Cloud-Bindung von der vertraglichen Seite an. NIS2 drückt die Prüfung der Lieferkette über die Anbieter nach unten durch. Der Cyber Resilience Act legt Produkten Sicherheitspflichten auf. InvestAI und das Gigafabrikenprogramm stecken Geld in Rechenkapazität. Der Cloud and AI Development Act ergänzt die Ebene von Beschaffung und Souveränität.

Einzeln sieht jedes davon nach zusätzlicher Last aus. Zusammen ergeben sie eine ziemlich schlüssige Wette: dass Europa sich mit einer Kombination aus Marktzugangsregeln und öffentlichem Geld zu einer eigenen Technologiebasis regulieren kann.

Ob die Wette aufgeht, ist eine berechtigte Frage. Dass sie platziert wird, nicht.

Was in den nächsten zwölf Monaten zu tun ist

Zeichnen Sie die Infrastrukturkarte. Wo läuft was, wer betreibt es, wie sieht der vertragliche Ausstiegspfad aus. Diese Karte brauchen Sie noch an vier weiteren Stellen.

Bestimmen Sie Ihre wirklich nichtportablen Abhängigkeiten und beziffern Sie eine Migration ehrlich, auch wenn Sie sie nie durchführen. Das beantwortet die Beschaffungsfrage und ist ohnehin gute Architekturhygiene.

Legen Sie eine Abstraktion über die Modellanbieter, falls noch nicht geschehen. Jetzt billig, später teuer, und nützlich aus Gründen, die mit Politik nichts zu tun haben.

Wenn Sie an europäische öffentliche Auftraggeber verkaufen, klären Sie, welche Vertrauenswürdigkeitsstufe Ihr Dienst erreichen könnte. In den Vergaberegeln des Gesetzes würde die Anforderung zuerst als Eignungskriterium auftauchen, und der am 9. September 2026 vorgeschlagene Public Procurement Act setzt einen allgemeinen Rahmen für eine europäische Präferenz obendrauf.

Migrieren Sie nicht auf Verdacht. Infrastruktur wegen eines Vorschlags zu verlagern, über den noch niemand verhandelt hat, ist genau der Weg, auf dem Organisationen ein Jahr und ein großes Budget für etwas ausgeben, das sich am Ende als gar nicht erforderlich herausstellt.

Hilfe bekommen

Wir entwerfen und bauen Cloud-Infrastruktur, Datenplattformen und KI-Anbindungen für Unternehmen in Europa, samt der unspektakulären Arbeit, ein System ehrlich portabel statt nur auf dem Papier portabel zu machen.

Wenn Sie eine Infrastruktur- und Abhängigkeitskarte, einen Ausstiegstest bei Ihrem aktuellen Anbieter oder eine Abstraktionsschicht über den Modellanbietern brauchen, schreiben Sie an office@c9group.dev. Mehr zu unserer Infrastrukturarbeit auf der Seite zur AWS-Kostenoptimierung und zu unserer europäischen Arbeit auf der Seite zum EU-Markteintritt.

Das größere gesetzgeberische Bild steht in unserer EU-Gesetzespipeline, und das Geld hinter dieser Agenda ist in unserem Leitfaden zur EU-Technologieförderung aufgeschlüsselt.

Wir sind Ingenieure, keine Politikberater. Das hier ist eine Planungssicht auf einen Vorschlag, keine Rechtsberatung.