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 er leisten soll

Der Vorschlag war als Flaggschiff des Kommissionsarbeitsprogramms für die erste Jahreshälfte 2026 angesetzt. Die erklärten Ziele ziehen sich unverändert durch alle Ankündigungen:

Europas Fähigkeit stärken, Cloud und KI zu entwickeln, auszurollen und zu skalieren. In der Praxis geht es um Rechenleistung, Rechenzentren und die Fähigkeit, große Modelle innerhalb der EU zu trainieren und zu betreiben.

Regulatorische Lücken schließen. Der bestehende Rahmen erfasst Cloud vor allem über die Wechselvorschriften des Data Act und die Sicherheitspflichten aus NIS2. Weder das eine noch das andere befasst sich mit Kapazität oder strategischer Abhängigkeit.

Interoperabilität fördern. Gemeint ist, die technischen Kosten eines Anbieterwechsels zu senken. Das ist dasselbe politische Ziel, das der Data Act von der vertraglichen Seite her angeht.

Eine EU-weite Cloud-Politik für öffentliche Verwaltungen und die Beschaffung verankern. Hier liegt der eigentliche Hebel. Ein gemeinsamer Ansatz dafür, wie öffentliche Stellen der Mitgliedstaaten Cloud einkaufen, mit einer europäischen Präferenz.

Ein sicheres und wettbewerbsfähiges europäisches Cloud- und KI-Ökosystem unterstützen. Der Sammelposten für alles Übrige.

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 von dem, was angekündigt wurde, deutet darauf hin, dass privaten Unternehmen die Nutzung nichteuropäischer Anbieter untersagt wird. 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. Ob das eine künftige Vergaberegel erfüllt, ist genau die Frage, die das Gesetz beantworten muss, und beantwortet hat es sie bislang nicht.

Es ist ein Vorschlag. Solange kein Text mit Positionen von Rat und Parlament vorliegt, lassen sich die Details nicht beurteilen. Beurteilen lässt sich die Richtung, und die 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 Interoperabilitä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, beobachten Sie die Vergabeseite genauer als das Gesetz selbst. Dort taucht die Anforderung zuerst auf, nämlich als Eignungskriterium.

Migrieren Sie nicht auf Verdacht. Infrastruktur wegen eines unveröffentlichten Vorschlags zu verlagern, 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.