EU-Souveränitätspaket: Was digitale Souveränität jetzt für die Vergabe bedeutet

Das EU-Souveränitätspaket im Überblick

Am 3. Juni 2026 hat die Europäische Kommission das European Technological Sovereignty Package vorgelegt, ein Bündel aus Gesetzesinitiativen und Strategien, das die strategischen Abhängigkeiten Europas in vier Feldern reduzieren soll: Halbleiter, Cloud, künstliche Intelligenz und Open Source. Den Anlass liefert eine ernüchternde Einschätzung der Kommission selbst: Bei zentralen digitalen Produkten, Diensten und Infrastrukturen sieht sie Europa zu über 80 Prozent von Anbietern außerhalb der EU abhängig.

Das Paket bündelt mehrere Bausteine, die jeweils ein eigenes Stück dieser Abhängigkeit adressieren:

• Cloud and AI Development Act (CADA): der zentrale Rechtsakt für Cloud- und KI-Infrastruktur
• Chips Act 2.0: Ausbau der europäischen Halbleiterkapazitäten
• Open-Source-Strategie: offene Technologien als Fundament europäischer Unabhängigkeit
• Roadmap für Digitalisierung und KI im Energiesektor: Rechenleistung und Energieversorgung zusammengedacht

Wichtig für die nüchterne Einordnung: CADA und Chips Act 2.0 sind zunächst Vorschläge. Sie müssen das ordentliche Gesetzgebungsverfahren durch Europäisches Parlament und Rat durchlaufen, bevor sie verbindlich werden. Wer heute plant, arbeitet also mit der Richtung, nicht mit einem fertigen Gesetzbuch. Genau deshalb lohnt der frühe Blick: Die Logik des Pakets ist bereits erkennbar, und sie verändert die Spielregeln der Beschaffung.

Was steckt im Cloud and AI Development Act?

Der Cloud and AI Development Act verfolgt zwei Stoßrichtungen, die oft durcheinandergeraten. Die erste ist industriepolitisch: schnellerer Aufbau energieeffizienter Rechenzentren, kürzere Genehmigungsverfahren, der Ausbau sogenannter AI Factories und AI Gigafactories, die europäischen Unternehmen und Forschung Zugang zu Hochleistungs-Rechenkapazität verschaffen sollen. Heute bremsen lange Genehmigungswege sowie der knappe Zugang zu Energie, Flächen und Finanzierung den Ausbau digitaler Infrastruktur in Europa.

Die zweite Stoßrichtung ist die regulatorisch interessantere und für die öffentliche Hand die wichtigere: CADA führt einen EU-weiten Rahmen ein, der unterschiedliche Souveränitätsstufen für Cloud-Computing bei sensiblen Workloads öffentlicher Stellen definiert. Damit wird digitale Souveränität von einem politischen Schlagwort zu einer einordnenbaren, klassifizierbaren Eigenschaft. Und das ist der Punkt, an dem das Gesetz den Verwaltungsalltag erreicht.

Der eigentliche Hebel: vier Stufen digitaler Souveränität

Die Kernidee des CADA ist denkbar pragmatisch: Souveränität ist für das Gesetz keine Ja/Nein-Eigenschaft, sondern eine abgestufte Skala. Statt ganze Anbieter pauschal zuzulassen oder auszuschließen, beschreibt der Rechtsakt abgestufte Anforderungen, von der reinen Datenlokalisierung bis zur vollständigen Kontrolle über die Lieferkette. Jeder Workload lässt sich so einer Stufe zuordnen, die zum tatsächlichen Schutzbedarf passt.

Zwei Stufenmodelle geraten hier leicht durcheinander, und die Unterscheidung lohnt sich. Der Leitfaden zur KI-Souveränität für Behörden und KRITIS beschreibt Betriebs- und Architekturstufen, von der EU-gehosteten Lösung bis zum eigenbetriebenen Stack. Der CADA klassifiziert dagegen rechtlich, ordnet also nicht die Technik ein, sondern die Zusicherung. Gemeinsam ist beiden die Einsicht, dass zwischen einer außereuropäischen Lösung und vollständiger Eigenkontrolle mehrere realistische Zwischenschritte liegen. Das eine Modell klärt den Betrieb, das andere die Ausschreibung.

Stufe 1 bis 4: was die Klassifizierung unterscheidet

Der CADA-Entwurf staffelt die Souveränitätsanforderungen in vier Stufen, im Verordnungstext als Union Assurance Levels (UAL 1 bis UAL 4) bezeichnet, die mit jedem Schritt strenger werden:

• Stufe 1 (Basis): Daten werden auf Infrastruktur innerhalb der EU verarbeitet und gespeichert. Geografische Lokalisierung als Fundament.
• Stufe 2 (Erhöht): Zusätzlich nachgewiesene Unabhängigkeit von Drittstaaten und Transparenz über die Software-Lieferkette.
• Stufe 3 (Streng): EU-Eigentum und -Kontrolle, ergänzt um Kriterien wie die Staatsangehörigkeit des Betriebspersonals, mit der Möglichkeit, qualifizierte Drittanbieter im Einzelfall anzuerkennen.
• Stufe 4 (Maximal): Volle Transparenz und Kontrolle über die gesamte Software-Lieferkette, ohne Einflussmöglichkeit aus Drittstaaten. Besonders sensible Bereiche wie die Verteidigungsbeschaffung fallen in diese Stufe.

Entscheidend ist die ehrliche Lesart: Auch Stufe 1 ist bereits ein realer Zugewinn an Kontrolle. Nicht jedes Fachverfahren braucht Stufe 4, und ein gut konfigurierter europäischer Cloud-Betrieb bleibt für viele unkritische Verfahren eine legitime Option. Die Stufen sind kein Ranking von „schlecht“ zu „gut“, sondern ein Werkzeug, um Aufwand und Schutzbedarf bewusst in Einklang zu bringen. Wo genau diese Kontrolle anfängt und aufhört, vertieft der Beitrag zur souveränen Cloud.

Der Gegenspieler: Zugriffsrechte aus Drittstaaten

Die Stufen beschreiben, was eine Behörde verlangen kann. Sie sagen nicht, wogegen. Der praktische Anlass liegt in Zugriffsrechten, die außerhalb der EU begründet werden und trotzdem Daten in Europa erreichen. Der US CLOUD Act von 2018 verpflichtet Anbieter mit Sitz oder Geschäftstätigkeit in den USA zur Herausgabe von Kundendaten, unabhängig davon, wo die Server stehen. Genau deshalb genügt in UAL 1 die Datenlokalisierung allein nicht, sobald der Betreiber einer fremden Rechtsordnung unterliegt, und genau deshalb fragt UAL 2 nach nachgewiesener Unabhängigkeit von Drittstaaten. Der CLOUD Act und seine Folgen für ein einzelnes Fachverfahren sind damit die andere Hälfte derselben Frage: Welche Datenarten sind überhaupt betroffen, und wie lässt sich die Einordnung später revidieren? Die CADA-Stufen setzen den Rahmen, die Zuordnung der eigenen Daten bleibt Arbeit in der Verwaltung.

Vom Gesetz zur Ausschreibung: digitale Souveränität in der Vergabe

Hier wird es konkret, und hier hebt sich das Paket von früheren Souveränitätsdebatten ab. Eine Klassifizierung entfaltet ihre Wirkung erst, wenn sie sich in Vergabeunterlagen übersetzen lässt. Die Hebel dafür hält das deutsche Vergaberecht längst bereit, es fehlte bisher nur der Maßstab, an dem sie ansetzen. Das Vergabebeschleunigungsgesetz, seit dem 1. Juli 2026 in Kraft, liefert ihn nicht: Es vereinfacht Verfahren, hebt Wertgrenzen und nennt als weitere Aspekte Nachhaltigkeit sowie umweltbezogene, soziale und innovative Kriterien. Ein eigenes Souveränitätskriterium führt es nicht ein. Den Maßstab liefert die europäische Klassifizierung, und erst mit ihr wird digitale Souveränität vom Wunsch zum justiziablen Kriterium. Für IT-Leitungen, Vergabestellen und Digitalisierungsbeauftragte verschiebt sich damit die zentrale Frage, weg von „Dürfen wir Souveränität fordern?“ hin zu „Wie formulieren wir sie rechtssicher?“.

Souveränität als Zuschlagskriterium und Ausführungsbedingung

Das Vergaberecht kennt zwei Stellen, an denen eine Anforderung wirksam wird, und sie unterscheiden sich in der Härte. Die eine bewertet ein Angebot beim Zuschlag, die andere bindet den Auftragnehmer über die gesamte Laufzeit. Zwei Hebel greifen dabei ineinander:

• Zuschlagskriterium (§ 58 VgV): Angebote lassen sich anhand von Souveränitätsaspekten bewerten, interoperable Systeme, Transparenz der Datenkontrolle, Anforderungen an Personal und Datenlokalisierung, Widerstandsfähigkeit gegen unbefugten Zugriff. Souveränität wird so zu einem gewichteten Faktor im Wettbewerb, nicht zur reinen Ja/Nein-Hürde.
• Ausführungsbedingung (§ 128 GWB): Der schärfere Hebel. Er verpflichtet den Auftragnehmer über die gesamte Vertragslaufzeit zur Einhaltung, etwa zu Datenstandort, geregelten Zugriffsrechten und zertifizierter Infrastruktur. Souveränität bleibt damit nicht nur Versprechen im Angebot, sondern wird zur Dauerpflicht im Betrieb.

Warum beide Hebel zusammen wirken

Die Kombination ist mächtig: Das Zuschlagskriterium belohnt souveräne Architektur bei der Auswahl, die Ausführungsbedingung sichert sie im laufenden Vertrag. Eine saubere Trennung beider Ebenen verhindert, dass anfangs versprochene Souveränität nach Vertragsschluss still verwässert. Dieselbe Mechanik gilt für weitere Qualitätsanforderungen: Auch bei der Barrierefreiheit im Vergabeverfahren entscheidet die Unterscheidung zwischen Mindestanforderung und gewichtetem Zuschlagskriterium darüber, ob eine Vorgabe im Verfahren tatsächlich greift.

Sovereignty Score und SEAL-Level in der Bewertung

Damit Souveränität vergleichbar wird, braucht es Maßeinheiten. Das europäische Cloud Sovereignty Framework übersetzt die Souveränitätsziele in gestaffelte Assurance-Level (SEAL) und daraus ableitbare „Sovereignty Scores“, die sich direkt in der Angebotsbewertung verwenden lassen. Damit ein Punktwert trägt, muss er allerdings an prüfbare Nachweise anknüpfen und nicht an Selbstauskünfte der Anbieter.

Auf nationaler Ebene liefert das BSI diese Nachweise in zwei Schichten. Das etablierte C5-Testat prüft die Informationssicherheit eines Cloud-Dienstes und sagt über Souveränität zunächst nichts. Seit April 2026 ergänzt der Kriterienkatalog C3A, ausgeschrieben Criteria enabling Cloud Computing Autonomy, genau diese Lücke: Er fragt, ob ein Dienst selbstbestimmt nutzbar bleibt oder nur formal in Europa steht. Für eine Vergabestelle ist das der praktisch wichtigere Teil, weil sich C3A-Kriterien in eine Leistungsbeschreibung übernehmen lassen, während ein Sovereignty Score bislang keine anerkannte Prüfstelle hinter sich hat.

Für die Praxis heißt das: Aus „möglichst souverän“ wird ein Punktwert, den ein Angebot erreicht oder eben nicht. Das macht Entscheidungen nachvollziehbar, auditierbar und, im Streitfall, begründbar. Genau diese Belegbarkeit ist der Unterschied zwischen einer politischen Absichtserklärung und einer tragfähigen Vergabeentscheidung.

Die Grenze: Souveränität ja, Diskriminierung nein

Hier liegt die wichtigste Fußnote, die in vielen Beiträgen fehlt. Souveränitätskriterien dürfen nicht zur verdeckten Bevorzugung bestimmter Herkunftsländer werden. Pauschale geografische Ausschlüsse ohne konkreten, dokumentierten Anwendungsbezug kollidieren mit dem Diskriminierungsverbot und dem WTO-Beschaffungsübereinkommen (GPA). Zulässig ist Souveränität als Kriterium dann, wenn sie an ein belegtes Risiko des konkreten Verfahrens anknüpft, nicht an die pauschale Frage, wo ein Anbieter seinen Hauptsitz hat.

Eng begrenzte Ausnahmen für wirklich sicherheitskritische Systeme erlaubt Artikel 346 AEUV, etwa im Verteidigungsumfeld. Dieser Weg ist aber die Ausnahme für einen schmalen Anteil der Beschaffung, nicht der Regelfall. Für den Alltag gilt: Souveränität sauber an den Schutzbedarf koppeln, nicht an die Flagge. Eine Ausschreibung, die den Schutzbedarf statt der Herkunft begründet, hält auch einer Nachprüfung stand.

Was Behörden, KRITIS und Mittelstand jetzt tun sollten

Die gute Nachricht für die Verwaltung: Auf die wichtigsten Schritte lässt sich nicht warten, bis das Gesetz final ist, sie zahlen sich ohnehin aus. Die Souveränitätsstufen liefern lediglich den Rahmen, in dem ohnehin sinnvolle Architekturentscheidungen jetzt eine klare Sprache bekommen.

• Workloads klassifizieren: Jedes Fachverfahren einer Schutzbedarfs- und Souveränitätsstufe zuordnen. Das Bürgerportal hat einen anderen Bedarf als das Melderegister.
• Souveränität in die Unterlagen schreiben: Zuschlagskriterien und Ausführungsbedingungen früh definieren, statt sie nachträglich aufzusetzen. Welche Nachweise bei KI-Systemen dazugehören, listet die KI-Beschaffung.
• Lock-in vermeiden: Offene Standards, dokumentierte Schnittstellen und Exit-Strategien verbindlich fordern. Die Austauschbarkeit gehört dabei in die Vergabeunterlagen, denn Vendor Lock-in vermeiden lässt sich nachträglich kaum noch durchsetzen.
• Datenhoheit absichern: Datenstandort, Löschkonzepte und vollständige Datenportabilität als native Funktion verlangen, nicht als kostenpflichtige Zusatzleistung. Für den Wechsel selbst greift seit September 2025 zusätzlich der Data Act.
• Auf Open Source setzen: Quelloffene Technologien sind das Fundament jeder höheren Souveränitätsstufe, prüfbar, anpassbar, austauschbar.

Das Betriebsmodell folgt dem Schutzbedarf

Beim Betriebsmodell lohnt Augenmaß statt Dogma: On-Premise, souveräne Cloud in Deutschland oder ein hybrider Aufbau sind je nach Schutzbedarf unterschiedlich sinnvoll, das ist eine projektabhängige Architekturentscheidung, keine pauschale Glaubensfrage. Welche Optionen sich wann eignen, ordnet der Beitrag zu souveränen Cloud-Lösungen ein. Speziell für die Verwaltung vertieft das der Leitfaden zur souveränen Softwareentwicklung für Behörden.

Einordnung: Souveränität ist Architektur, nicht Herkunft

Ob CADA in dieser Form beschlossen wird, ist offen, und das Gesetzgebungsverfahren dauert Jahre. Unabhängig vom endgültigen Wortlaut überlebt aber die Logik dahinter: Souveränität wird messbar, abstufbar und vergaberechtlich greifbar. Damit verschiebt sich die Diskussion von Symbolpolitik zu Architektur- und Beschaffungsentscheidungen, und diese Entscheidungen trifft am Ende nicht Brüssel, sondern jede IT-Leitung für sich.

Der entscheidende Gedanke dahinter ist älter als jedes Gesetz: Souveränität entsteht nicht allein durch den Standort eines Rechenzentrums und schon gar nicht durch die Nationalität eines Logos, sondern durch Kontrolle über die gesamte Kette, von der Datenhaltung über offene Schnittstellen bis zur Fähigkeit, den Anbieter jederzeit zu wechseln. Genau das beschreibt unser umfassender Leitfaden zur digitalen Souveränität in der Softwareentwicklung.