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 verabschiedet, 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 Zahl: Bei zentralen digitalen Produkten, Diensten und Infrastrukturen ist die EU nach Angaben der Kommission zu über 80 Prozent von Anbietern außerhalb Europas 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.

Wichtig ist dabei die Abgrenzung zweier Stufenmodelle, die leicht durcheinandergeraten: Während der Leitfaden zur KI-Souveränität für Behörden und KRITIS die Betriebs- und Architekturstufen beschreibt, von der EU-gehosteten Lösung bis zum eigenbetriebenen Stack, definiert der CADA die rechtliche Klassifizierung desselben Grundgedankens. Beide teilen dieselbe Einsicht: Zwischen einer rein außereuropäischen Lösung und vollständiger Eigenkontrolle liegen mehrere realistische Zwischenschritte. Der Leitfaden beantwortet die Frage „Wie betreibe ich souverän?“, dieser Beitrag die Frage „Wie schreibe ich Souveränität rechtssicher in eine Vergabe?“.

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 im Glossar.

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. Genau darauf zielt die parallele Entwicklung im deutschen Vergaberecht, etwa im geplanten Vergabebeschleunigungsgesetz: Digitale Souveränität wird 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

Zwei Hebel des deutschen Vergaberechts greifen 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.

Die Kombination ist mächtig: Das Zuschlagskriterium belohnt souveräne Architektur bei der Auswahl, die Ausführungsbedingung sichert sie im laufenden Vertrag. Wer das sauber trennt, vermeidet, dass anfangs versprochene Souveränität nach Vertragsschluss still verwässert.

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. Ergänzend prüfen die Kriterien des BSI, vom etablierten C5-Testat bis zu neueren Souveränitätskriterien, ob ein Cloud-Dienst tatsächlich selbstbestimmt nutzbar ist oder nur formal in Europa steht.

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. Wer das verinnerlicht, baut Ausschreibungen, die auch einer Nachprüfung standhalten.

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.
• Lock-in vermeiden: Offene Standards, dokumentierte Schnittstellen und Exit-Strategien verbindlich fordern. Wie das gelingt, zeigt der Leitfaden Vendor Lock-in vermeiden.
• Datenhoheit absichern: Datenstandort, Löschkonzepte und vollständige Datenportabilität als native Funktion verlangen, nicht als kostenpflichtige Zusatzleistung.
• Auf Open Source setzen: Quelloffene Technologien sind das Fundament jeder höheren Souveränitätsstufe, prüfbar, anpassbar, austauschbar.

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

Das EU-Souveränitätspaket wird im Newszyklus bald von der nächsten Schlagzeile abgelöst. Sein eigentlicher Wert liegt unter der Oberfläche, und er bleibt: Souveränität wird messbar, abstufbar und vergaberechtlich greifbar. Damit verschiebt sich die Diskussion von Symbolpolitik zu konkreten Architektur- und Beschaffungsentscheidungen. Und die 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.