Macht ein europäischer Betreiber die Cloud souverän?

Der vorangegangene Artikel Open Source und Unternehmenssicherheit: Kontrolle statt Vertrauen hat Kontrolle als Treppe beschrieben: Einsicht, Prüfung, Änderung, Lieferkette. Offener Quellcode macht diese vier Stufen begehbar, er trägt aber niemanden hinauf. Eine Stufe blieb dort ausdrücklich ausgespart, und sie ist die oberste: Selbst der gründlichst geprüfte und selbst gepflegte offene Stack nützt wenig, wenn er auf einer Infrastruktur läuft, über die rechtlich oder physisch ein Dritter bestimmt.

Um diese Stufe geht es jetzt. Sie lässt sich in eine einzige Frage fassen, die im Ernstfall über mehr entscheidet als jede Leistungszusage: Was passiert, wenn jemand den Zugang abstellt?

Nicht aus technischem Versagen, sondern weil eine Regierung es anordnet, eine Sanktionsliste es verlangt oder ein Handelskonflikt eskaliert. Das klang lange nach einem Gedankenspiel für Sicherheitsbeauftragte mit zu viel Fantasie. Seit 2025 klingt es anders.

Die Frage ist auch deshalb unbequemer als die nach dem Quellcode, weil sich der Betrieb eines fremden Rechenzentrums nur bedingt einsehen lässt.

Das heißt ausdrücklich nicht, dass man gar nichts prüfen könnte. Die großen Anbieter lassen sich regelmäßig auditieren und veröffentlichen die Ergebnisse, etwa nach ISO 27001, SOC 2 oder dem BSI-Kriterienkatalog C5. Große Kunden können Rechenzentren besichtigen und eigene Prüfungen vereinbaren. Nur klärt all das eine bestimmte Frage nicht: Solche Prüfungen bescheinigen, dass Prozesse und Kontrollen funktionieren. Sie sagen nichts darüber, wem ein Anbieter gehorcht, wenn eine Behörde seines Heimatstaates etwas anderes anordnet. Genau diese Lücke ist das Thema dieses Artikels.

Ein Konzern sortiert seine Anwendungen

Die Fälle, an denen sich das zeigt, sind bekannt. Der Open-Source-Artikel hat sie gestreift: die gesperrte E-Mail des Chefanklägers am Internationalen Strafgerichtshof nach den US-Sanktionen von Anfang 2025, von Microsoft bestritten und von außen nicht zu klären, sowie das KI-Modell Claude Fable 5 von Anthropic, das US-Exportauflagen rund zwei Wochen lang unerreichbar machten, bis diese wieder aufgehoben wurden.

Das Verbindende daran ist nicht die Empörung, sondern eine strukturelle Eigenschaft. Wer einen Vorgang nicht selbst nachvollziehen kann, ist auf die Darstellung des Anbieters angewiesen, auch dann, wenn dieser in eigener Sache spricht. Und das Muster lässt sich übertragen: Ein Unternehmen wird von Sanktionen erfasst, gerät in einen Handelskonflikt oder in einen Rechtsstreit, an dem eine ausländische Behörde ein Interesse hat. Wer dann feststellt, dass seine Buchhaltung, seine Konstruktionsdaten und seine Kommunikation auf einer Plattform liegen, über die er nicht verfügt, hat kein Sicherheitsproblem. Er hat ein Problem mit seiner Handlungsfähigkeit.

Dass diese Sorge inzwischen in vielen Unternehmen angekommen ist, zeigt der Cloud Report 2026 des Bitkom. Fast zwei Drittel der Unternehmen, die Cloud-Dienste nutzen, sehen sich durch die Politik der US-Regierung veranlasst, ihre Cloud-Strategie zu überdenken. Ein Jahr zuvor war es die Hälfte.

Interessanter als die Vorfälle ist deshalb die Frage, was jemand daraus macht. Im Juli 2026 ist das zum ersten Mal in einem Industriekonzern nachvollziehbar geworden. Airbus hat nach einer Ausschreibung den französischen Anbieter Scaleway als souveränen Cloud-Partner ausgewählt und beginnt damit, 70 geschäftskritische Anwendungen von Amazon Web Services zu verlagern. Betroffen sind unter anderem ERP-Systeme, die Fertigungssteuerung, CRM und das Produktdatenmanagement, also der Kern des Unternehmens. Der Umzug soll bis Ende 2028 abgeschlossen sein, und in einem Zeitraum von fünf bis sechs Jahren könnte das Programm bis zu 900 Anwendungen umfassen, die Airbus für den Weiterbetrieb des Konzerns als unverzichtbar einstuft.

Bewertet wurden die Anbieter dabei entlang von drei Dimensionen: technische Leistungsfähigkeit, betriebliche Zuverlässigkeit sowie rechtliche Absicherung, ausdrücklich einschließlich des Schutzes vor dem Zugriff durch Gesetze von Staaten außerhalb Europas. Catherine Jestin, bei Airbus verantwortlich für den digitalen Bereich, formuliert das Ziel so, dass die kritischen Datenbestände vor dem Zugriff fremder Gesetze abgeschirmt werden sollen.

Zwei Details an diesem Fall sind bedeutsamer als die Schlagzeile. Erstens ist es kein Ausstieg. Airbus behält den Multi-Cloud-Ansatz bei und nutzt US-Anbieter für weniger sensible Arbeitslasten weiter. Jestin sagt dazu, man beabsichtige nicht, sich von allen nicht-europäischen Lösungen zu trennen, sondern wäge nach der Kritikalität der Daten ab. Zweitens fiel die Entscheidung nicht allein aus politischen Gründen: Nach Jestins Darstellung überzeugte Scaleway mit einer starken technischen Antwort und einem im Vergleich zu den Public-Cloud-Angeboten der Hyperscaler wettbewerbsfähigen kommerziellen Angebot.

Das ist die eigentliche Nachricht. Nicht „europäisch statt amerikanisch“, sondern eine Sortierung nach Kritikalität. Genau darauf läuft dieser Artikel hinaus.

Warum „Daten in Frankfurt“ nichts beweist

Das naheliegende Gegenargument lautet: Die Daten liegen doch in Europa. Rechenzentrum in Frankfurt, Vertrag mit einer deutschen GmbH, Auftragsverarbeitung nach DSGVO. Damit sei die Sache erledigt.

Ist sie nicht, und den überzeugendsten Beleg dafür liefert nicht die Kritikerseite, sondern ein Anbieter selbst.

Im Juni 2025 sagte Anton Carniaux, Leiter der Rechts- und Regierungsbeziehungen bei Microsoft Frankreich, unter Eid vor dem französischen Senat aus. Der Berichterstatter fragte ihn, ob er garantieren könne, dass Daten der französischen Verwaltung niemals ohne ausdrückliche Zustimmung Frankreichs an US-Behörden gelangen. Carniaux antwortete, dass er das nicht garantieren könne.

Das ist keine Nachlässigkeit und kein Versäumnis in der Vertragsgestaltung. Es ist die logische Folge der Rechtslage. Der US CLOUD Act knüpft nicht an den Ort der Speicherung an, sondern an die Kontrolle über das Unternehmen. Wer als US-Konzern die Verfügungsgewalt über Daten hat, kann zu deren Herausgabe verpflichtet werden, unabhängig davon, in welchem Land die Server stehen. Hinzu kommt für die nachrichtendienstliche Seite Section 702 des Foreign Intelligence Surveillance Act, im US-Recht kodifiziert als 50 U.S.C. 1881a.

Eine deutsche Tochtergesellschaft, die weiterhin vom US-Mutterkonzern betrieben wird, ändert daran nichts. Eine Vertragsklausel ändert ebenfalls nichts daran, weil sie gegenüber einer gerichtlichen Anordnung keinen Bestand hat. Und in vielen Fällen erfährt der betroffene Kunde nicht einmal davon. Ob weiter gehende Konstruktionen mit einem eigenständigen europäischen Betreiber die Lage verändern, ist eine eigene Frage, zu der wir später kommen.

Damit ist nicht gesagt, dass ständig Daten abfließen. Es ist gesagt, dass die Möglichkeit strukturell besteht und der Kunde sie nicht ausschließen kann. Der Unterschied zwischen „passiert nicht“ und „kann nicht passieren“ ist genau der Unterschied, um den es in diesem Artikel geht.

Drei Ebenen, ohne die die Diskussion im Kreis läuft

Ein Grund, warum Gespräche über Cloud-Souveränität ergebnislos enden können, ist banal: Die Beteiligten meinen verschiedene Dinge. Der eine denkt an den Serverstandort, der andere an das Betriebspersonal, der dritte an die Frage, ob die Software ohne den Hersteller weiterläuft. Alle drei haben recht, und alle drei reden aneinander vorbei.

Für die oberste Stufe der Kontrolltreppe aus dem letzten Artikel, also für Betrieb und Datenhoheit, hilft eine weitere Aufteilung in drei Ebenen, wie sie unter anderem das Zentrum für Digitale Souveränität in seinem Whitepaper zum Souveränitäts-Washing verwendet.

Datensouveränität betrifft die Daten selbst. Wo liegen sie, wer hält die Schlüssel, gibt es externes Schlüsselmanagement, wird clientseitig verschlüsselt, und was steht in den Zugriffsprotokollen.

Betriebssouveränität betrifft die Menschen und Prozesse. Sitzt das Betriebspersonal in der EU, erfolgen administrative Zugriffe ausschließlich von dort, gibt es ein eigenes Security Operations Center, und existieren definierte Abläufe für den Fall, dass die Verbindung zum Hersteller getrennt wird und später wiederhergestellt werden soll.

Technologiesouveränität betrifft die Substanz. Ist der Quellcode verfügbar, wie sieht die Update- und Lieferkette aus, und vor allem: Läuft der Dienst weiter, wenn der Hersteller morgen nicht mehr liefert, und für wie lange.

Die dritte Ebene ist die anspruchsvollste und wird leicht übersehen. Eine souveräne Plattform, die auf Lizenzen und Updates eines einzigen Herstellers angewiesen ist, hat eine Halbwertszeit. Sie ist nicht unabhängig, sie merkt die Abhängigkeit nur später.

Wie weit die Angebote am Markt tatsächlich auseinanderliegen, hat das Magazin iX im Mai 2026 untersucht. Siebzehn Anbieter wurden anhand von 31 Kriterien verglichen. Das Ergebnis war unbequem für alle Seiten: Es gab keinen Gesamtsieger. Europäische Anbieter warben mit EU-Eigentümerschaft, wiesen aber technische Lücken auf. US-Hyperscaler verdeckten die Risiken, die sich aus der Rechtsordnung ihres Heimatstaates ergeben, mit EU-Tochtergesellschaften. Und quer durch beide Lager lag die schwächste Stelle an derselben Stelle, nämlich bei Kryptografie und Schlüsselkontrolle.

Wer selbst vergleichen möchte, findet die zugrunde liegenden Daten im frei zugänglichen Sovereign Cloud Compass , der inzwischen mit 43 Kriterien arbeitet.

Seit April 2026 gibt es ein Maß

Bis vor kurzem war das die eigentliche Schwäche der ganzen Diskussion. „Souverän“ war ein Wort ohne Definition, und wo es keine Definition gibt, gewinnt die bessere Marketingabteilung. Das hat sich geändert, und zwar nicht durch ein Gesetz, sondern durch eine Ausschreibung.

Die Europäische Kommission stand vor demselben Problem wie jedes Unternehmen: Sie wollte souveräne Cloud-Dienste beschaffen und musste dafür erst festlegen, was das überhaupt bedeutet. Das Ergebnis heißt Cloud Sovereignty Framework und übersetzt Souveränität in messbare Vergabekriterien. Es ist damit kein neutraler Standard, sondern das Beschaffungsinstrument einer Institution, die selbst ein Interesse am Ergebnis hat. Darauf kommen wir zurück. Als Prüfraster ist es trotzdem das Brauchbarste, was derzeit vorliegt.

Bewertet wird entlang von 48 Kriterien in acht Kategorien: strategisch, Recht und Zuständigkeit, Daten und KI, operativ, Lieferkette, Technologie, Sicherheit und Compliance sowie ökologische Nachhaltigkeit. Daraus ergibt sich eine Einstufung in die Sovereignty Effectiveness Assurance Levels, kurz SEAL, von Stufe 0 bis Stufe 4.

• SEAL-0 bedeutet keine Souveränität, also vollständige Kontrolle durch Nicht-EU-Akteure.
• SEAL-1 steht für jurisdiktionelle Souveränität, also für die Frage, welches Recht überhaupt greift. EU-Recht ist formal anwendbar, praktisch aber kaum durchsetzbar.
• SEAL-2 steht für Datensouveränität. EU-Recht ist durchsetzbar, ohne dass der Kunde selbst zusätzliche technische Maßnahmen ergreifen muss. Wesentliche Abhängigkeiten von außerhalb der EU bleiben aber bestehen.
• SEAL-3 steht für digitale Resilienz und technologische Autonomie. Dienst, Technologie und Betrieb sind gegen Lieferkettenunterbrechungen durch Drittstaaten immun.
• SEAL-4 steht für vollständige Souveränität mit durchgehend europäischer Lieferkette, in den Worten der Kommission „from chips to software“.

Im April 2026 hat die Kommission dieses Raster erstmals angewendet und darüber Verträge über bis zu 180 Millionen Euro auf sechs Jahre vergeben. Voraussetzung für eine Berücksichtigung war mindestens SEAL-2. Bewusst wurden vier Anbieter beauftragt statt einem, ausdrücklich um eine Abhängigkeit von einem einzelnen Lieferanten zu vermeiden.

Zum Zuge kamen ein luxemburgisch-französisches Konsortium unter Führung von Post Telecom mit OVHcloud und CleverCloud, das deutsche Unternehmen STACKIT aus der Schwarz Gruppe, das französische Unternehmen Scaleway aus der Iliad-Gruppe sowie ein belgisch-französisch-luxemburgisches Konsortium unter Führung von Proximus, das auf Dienste von S3NS, Clarence und Mistral zurückgreift.

Zwei Ergebnisse dieser Vergabe sind aufschlussreicher als jede Anbieterbroschüre.

Ein SEAL-Zertifikat im eigentlichen Sinn gibt es allerdings nicht. Keine Akkreditierungsstelle vergibt SEAL-Stufen. Eine Einstufung entsteht erst, wenn ein öffentlicher Auftraggeber einen Anbieter in einem konkreten Vergabeverfahren bewertet. Wer damit wirbt, „SEAL-3 zu erfüllen“, ohne an einem solchen Verfahren teilgenommen zu haben, beschreibt eine Selbsteinschätzung.

Erstens erreichte keiner der vier beauftragten Anbieter SEAL-4. Die drei Konsortien mit eigener Technologie, also Post Telecom mit seinen Partnern, STACKIT und Scaleway, kamen auf SEAL-3. Das Proximus-Konsortium erreichte SEAL-2. Die durchgehend europäische Lieferkette vom Chip bis zur Software hat also nicht einmal unter den Bestbewerteten jemand vorzuweisen. Was daraus folgt, dazu später mehr.

Zweitens ist S3NS ein Gemeinschaftsunternehmen von Thales und Google Cloud. Ein Anbieter also, dessen Technologiebasis amerikanisch ist, erreichte das geforderte Mindestmaß. Die Kommission schreibt dazu in ihrer eigenen Mitteilung, es zeige sich, dass auch nicht-europäische Technologien das erforderliche Mindestmaß an Souveränität erreichen können, sofern sie in einem strengen und geeigneten Rahmen betrieben werden.

Bemerkenswert ist, von wem dieser Satz stammt: von der Institution, die allen Anlass hätte, ihn anders zu formulieren. Souveränität ist demnach keine Frage der Flagge auf dem Firmenlogo, sondern der Betriebsbedingungen.

Nun unterliegt kein Unternehmen dem Vergaberecht der EU, und niemand muss eine SEAL-Stufe erreichen. Brauchbar ist das Raster für Unternehmen trotzdem, und zwar aus einem einfachen Grund: Es ist die bislang einzige öffentlich dokumentierte Bewertung souveräner Cloud-Angebote nach offengelegten Kriterien. Verbindlich ist sie außerhalb der Beschaffung für niemanden, als Fragenkatalog für das nächste Anbietergespräch taugt sie trotzdem. Die Kommission empfiehlt sie ausdrücklich auch privaten Organisationen zur Selbstbewertung, und sie ist frei verfügbar.

Hinzu kommt, dass aus dem internen Prüfraster verbindliches Recht werden soll. Der von der Europäischen Kommission im Juni 2026 vorgeschlagene Cloud and AI Development Act will daraus ein einheitliches EU-weites Bewertungsraster für Cloud- und KI-Souveränität machen. Souveränität wäre dann keine Absichtserklärung mehr, sondern eine Bedingung in der Ausschreibung.

Bis dahin ist es allerdings ein weiter Weg. Der Gesetzentwurf liegt seit Juni 2026 vor, mit einer Verabschiedung wird nicht vor Ende 2027 gerechnet. Wer nicht warten will, kann das Raster schon heute anwenden, ohne dass es jemand vorschreibt.

Was die großen Anbieter daraus gemacht haben

Alle drei US-Hyperscaler haben auf die europäische Debatte reagiert, und zwar mit erstaunlich unterschiedlichen Ansätzen. Es lohnt sich, sie nicht als Produktvergleich zu lesen, sondern als drei verschiedene Antworten auf dieselbe Frage: Wie viel Kontrolle kann man abgeben, ohne das Geschäft aufzugeben?

Amazon Web Services (AWS) hat den organisatorisch konsequentesten Weg gewählt. Die AWS European Sovereign Cloud ist seit dem 15. Januar 2026 allgemein verfügbar, die erste Region liegt in Brandenburg. Sie ist physisch und logisch von den übrigen AWS-Regionen getrennt und läuft über eine eigene deutsche Rechtsentität mit ausschließlich in der EU ansässigem Personal. Getrennt sind auch Identitätsverwaltung, Abrechnung, DNS und die Zertifizierungsstelle, also genau die Bestandteile, an denen sich sonst zeigt, wo eine vermeintlich eigenständige Umgebung doch am globalen Konzernnetz hängt. Amazon investiert dafür nach eigenen Angaben mehr als 7,8 Milliarden Euro und kündigte eine Ausweitung nach Belgien, in die Niederlande und nach Portugal an.

Microsoft setzt stärker auf technische Kontrollen als auf organisatorische Trennung. Das Angebot gliedert sich in eine Sovereign Public Cloud, eine Sovereign Private Cloud für den Betrieb in eigenen oder Partner-Rechenzentren sowie eine Reihe von Einzelkontrollen. Dazu zählen manipulationssichere Zugriffsprotokolle und External Key Management, bei dem die Verschlüsselungsschlüssel in Hardware-Sicherheitsmodulen außerhalb der Cloud liegen. Als Partner dafür nennt Microsoft unter anderem das Aachener Unternehmen Utimaco.

Google geht bei der Betreibertrennung am weitesten. Neben einer Data Boundary in der Public Cloud und einer vollständig vom Netz getrennten Air-Gapped-Variante gibt es Google Cloud Dedicated, das von einem lokalen Partner betrieben wird. Für Deutschland ist das Thales. Nach der Ankündigung sollen der kryptografische Vertrauensanker, also die oberste Instanz, von der sich alle weiteren Schlüssel ableiten, dazu die Schlüssel selbst, IP-Adressen, Identitäten und der gesamte Betrieb bei Thales liegen, Google selbst soll darauf keinen Zugriff haben. Betreiber ist eine neue deutsche Gesellschaft, die rechtlich und operativ von Google getrennt ist. Nach einem Reuters-Bericht vom 20. Mai 2026 befindet sich die Lösung in der Preview-Phase, der allgemeine Start bleibt für Ende 2026 vorgesehen. Wie die Schlüsselverwaltung im Detail funktioniert, ist bislang nicht öffentlich dokumentiert. In Frankreich existiert mit S3NS bereits ein vergleichbares Konstrukt, ein Gemeinschaftsunternehmen von Thales und Google, ausgelegt auf den französischen Standard SecNumCloud.

Wie weit ein solcher Aufbau tragen kann, zeigt ein deutsches Beispiel: Die Bundeswehr nutzt Google-Dienste unter Auflagen in einer Air-Gapped-Konfiguration, also als private Cloud-Instanzen in eigenen Rechenzentren, physisch vom offenen Internet getrennt. Die Frage lautet dort nicht „US-Anbieter ja oder nein“, sondern unter welchen Bedingungen.

Der gemeinsame Rest

So verschieden die drei Wege sind, sie enden am selben Punkt. Keine dieser Konstruktionen räumt die Frage nach der Rechtsordnung aus. Die Konzernmutter bleibt US-amerikanisch, und der CLOUD Act knüpft an die Kontrolle über das Unternehmen an.

Hier ist allerdings eine Differenzierung nötig. Der CLOUD Act greift auf Daten zu, die sich im Besitz, Gewahrsam oder unter der Kontrolle eines US-Anbieters befinden. Ob eine Konstruktion wie die von Thales betriebene deutsche Google-Gesellschaft diese Voraussetzung noch erfüllt, ist juristisch umstritten und, soweit öffentlich bekannt, gerichtlich nicht geklärt. Man kann also nicht pauschal sagen, alle Souveränitätsangebote von US-Anbietern seien wirkungslos. Man kann aber sagen, dass die Rechtslage ungeklärt ist und das Risiko damit beim Kunden bleibt. Wer auf ein juristisches Restrisiko setzt, das im Ernstfall erst ein Gericht klären würde, sollte das bewusst tun und nicht, weil eine Broschüre das Gegenteil suggeriert.

Es wäre allerdings zu einfach, diese Angebote als reines Marketing abzutun. Die Trennung von Betrieb, Identitäten und Schlüsseln senkt das Risiko messbar, auch wenn sie es nicht auf null bringt. Sie kostet die Anbieter erhebliche Summen und schafft Strukturen, die sich nicht über Nacht zurückbauen lassen. Wer den Unterschied zwischen einer gewöhnlichen EU-Region und einer eigenen Rechtsentität mit getrennter Identitätsverwaltung für bedeutungslos hält, verkennt, wie viel Aufwand dahintersteckt. Der Punkt ist nicht, dass sich nichts geändert hätte. Der Punkt ist, dass das verbleibende Risiko beim Kunden liegt und nicht beim Anbieter.

Wobei die Kunden das durchaus registrieren. 87 Prozent der deutschen Unternehmen vermissen bei den Souveränitätsangeboten internationaler Anbieter ausreichende Transparenz über Datenverarbeitung und Zugriffsrechte. Das ist der höchste Einzelwert im gesamten Bitkom Cloud Report 2026 und bemerkenswert, weil er nicht die Angebote als solche kritisiert, sondern deren Nachprüfbarkeit. Also genau das, worum es in diesem Artikel geht.

Bezeichnend ist der Befund aus der EU-Vergabe. Google geht bei der Betriebstrennung am weitesten, lässt den Partner sogar die Schlüssel halten. Trotzdem erreichte das Konsortium mit S3NS nur SEAL-2, während die Anbieter mit eigener Technologie SEAL-3 erreichten. Der Grund liegt in der Systematik: SEAL-3 bewertet nicht, wer den Betrieb führt, sondern ob Dienst und Technologie gegen eine Unterbrechung der Lieferkette durch Drittstaaten immun sind. Betriebstrennung und Technologieunabhängigkeit sind zwei verschiedene Dinge, und die zweite ist die anspruchsvollere: Würde Google etwa aufgrund von US-Sanktionen den Software-Nachschub stoppen, könnte die europäische Hülle Thales die komplexen Cloud-Dienste technologisch nicht eigenständig weiterentwickeln oder patchen. Genau diese technologische Eigenständigkeit wäre für SEAL-3 aber zwingend erforderlich.

Die europäische Seite

Wer nun erwartet, dass auf der anderen Seite eine geschlossene europäische Alternative steht, wird enttäuscht. Aber es tut sich mehr, als der Ruf der Branche vermuten lässt.

Der interessanteste Fall ist STACKIT aus der Schwarz Gruppe, also dem Konzern hinter Lidl und Kaufland. Interessant weniger wegen der Technik als wegen der Finanzierungslogik: Hier fließt kein Fördergeld, sondern Handelsgeld. In Lübbenau in Brandenburg ist der Spatenstich für ein Rechenzentrum mit 200 Megawatt Anschlussleistung erfolgt, in dem bis zu 100.000 GPUs betrieben werden sollen. Nach Medienberichten investiert Schwarz Digits dafür elf Milliarden Euro, was die größte Einzelinvestition der Unternehmensgeschichte wäre. Der Konzern selbst hat diese Summe nicht bestätigt.

Belastbarer als die Investitionssumme ist ohnehin der Umsatz. Die Sparte Schwarz Digits kam 2025 auf 2,2 Milliarden Euro, ein Plus von 15,8 Prozent gegenüber dem Vorjahr. Zur Einordnung: Die Unternehmen der Schwarz Gruppe erzielten 2025 insgesamt rund 185,6 Milliarden Euro Umsatz und investieren 2026 mehr als zehn Milliarden Euro, davon etwa fünf Milliarden in Deutschland. Die Cloud ist hier kein Imageprojekt, sondern ein wachsendes Geschäft.

Zwei Einschränkungen gehören dazu. Erstens ist Lübbenau in erster Linie eine Wette auf KI-Rechenlast, nicht auf klassische Unternehmens-Workloads. Zweitens ist ein Rechenzentrum noch keine Plattform. Kapazität in Megawatt lässt sich schneller aufbauen als Funktionsumfang und Betriebsreife.

Was für STACKIT spricht, ist unabhängig belegt: SEAL-3 in der Ausschreibung der EU-Kommission, gleichauf mit OVHcloud und Scaleway. Dazu Kunden im Finanzsektor wie Helaba, L-Bank und Nord/LB sowie die Ankündigung von SAP aus dem Februar 2025, STACKIT als Souveränitätsoption für SAP-Kunden einzubinden.

Daneben steht ein Feld, das man kennen sollte: Scaleway aus der Iliad-Gruppe, seit Juli 2026 Partner von Airbus. OVHcloud und CleverCloud, die gemeinsam mit Post Telecom ebenfalls SEAL-3 erreichten. IONOS, die Open Telekom Cloud, der einzelne Marktvergleiche unter den europäischen Anbietern den Funktionsumfang mit der größten Nähe zu Azure bescheinigen, sowie Hetzner, plusserver und das finnische UpCloud.

Für keinen dieser Anbieter gibt es eine SEAL-Einstufung, und das ist kein Makel. Eine Stufe entsteht nur in einem konkreten Vergabeverfahren. Wer nicht mitbietet, wird nicht bewertet.

Und dann die ehrliche Zahl: 43 Prozent der deutschen Unternehmen sagen, für ihre Anforderungen gebe es derzeit keine gleichwertige europäische Alternative zu den US-Hyperscalern. Die Lücke schließt sich, aber sie besteht.

Was aus Gaia-X wurde, und was man daraus lernen kann

Wer über europäische Cloud-Projekte schreibt, kommt an Gaia-X nicht vorbei. 2019 als deutsch-französisches Leuchtturmprojekt gestartet, sollte es eine europäische Infrastruktur schaffen. Als Infrastruktur ist es gescheitert. Heute konzentriert sich Gaia-X auf Interoperabilitätsstandards und ein Trust Framework, der Nachfolger für den Infrastrukturteil heißt 8ra, ein kommerzielles Ausgründungsprojekt, das die Gaia-X-Prinzipien nun tatsächlich in eine nutzbare, föderierte Cloud-Infrastruktur umsetzen soll, da Gaia-X selbst nur das Regelwerk liefert.

Über die Ursachen wird gestritten. Kritiker aus dem Umfeld der EuroStack-Initiative führen an, das Projekt habe seinen Zweck verloren, nachdem Microsoft, Google und AWS der Trägervereinigung beitraten, der Gaia-X Association AISBL mit Sitz in Brüssel. Sie gehörten dort zu den Gründungsmitgliedern, ebenso wie später Alibaba Cloud. Andere verweisen auf zu viele Beteiligte, zu wenig konkretes Ergebnis und zu viel Bürokratie. Beides dürfte zutreffen, und beides ist keine technische Diagnose. Bei Gaia-X scheiterte es jedenfalls nicht an der Technik, sondern an der Frage, wer entscheidet.

Das Marktsignal aus der öffentlichen Beschaffung

Für Unternehmen ist ein Nebenaspekt relevanter, als er klingt: Der Staat kauft inzwischen anders ein, und das verändert das Angebot.

Die EU-Kommission verteilte ihre 180 Millionen Euro bewusst auf vier Anbieter statt auf einen, ausdrücklich um Abhängigkeit von einem einzelnen Lieferanten zu vermeiden. Der Bund ging bei der Souveränen KI-Plattform ähnlich vor: Der Auftrag über rund 250 Millionen Euro auf vier Jahre wurde gesplittet, 70 Prozent an ein Konsortium aus T-Systems und SAP, 30 Prozent an ein von SVA geführtes Konsortium, an dem auch Schwarz Digits beteiligt ist. Fällt einer aus, übernimmt der andere. Nach Berichten von heise wurde Souveränität in dieser Vergabe erstmals stärker gewichtet als der Preis.

Der Vorgang hatte eine Vorgeschichte, die zur Einordnung gehört: Ein Konsortium aus Google und dem Dienstleister adesso war wegen Formfehlern nicht in die engere Wahl gekommen und hatte daraufhin die Vergabekammer angerufen. Die Anträge wurden später zurückgezogen, das Projekt konnte starten. Ein Nachprüfungsantrag ist ein reguläres Rechtsmittel und kein Skandal. Bemerkenswert bleibt die Konstellation trotzdem.

Lock-in: der Teil, der Unternehmen sofort betrifft

Bis hierher ging es um Rechtsordnung, Betrieb und Technologie. Der praktisch wirksamste Hebel ist aber ein anderer, und er hat mit Souveränität auf den ersten Blick wenig zu tun: die Fähigkeit, den Anbieter zu wechseln.

Der Zusammenhang ist einfach. Wer nicht wechseln kann, verhandelt nicht. Er nimmt hin, was angeboten wird, bei Preisen ebenso wie bei Vertragsbedingungen und Zusicherungen. Souveränität ohne Ausstiegsoption ist eine Formulierung im Vertrag, keine Position.

Die Zahlen dazu sind ernüchternd. Nur etwa ein Drittel der deutschen Unternehmen hat überhaupt schon einmal den Cloud-Anbieter gewechselt, 26 Prozent einmal, acht Prozent mehrfach. 20 Prozent haben einen Wechsel fest vor, 43 Prozent wollen bleiben. Als größtes Hindernis nennen 59 Prozent Lock-in-Effekte, also schwierige Datenexporte und Migrationen. Dahinter folgen fehlender strategischer Bedarf mit 49 Prozent, Personalaufwand und Komplexität mit je 45 Prozent, Zufriedenheit mit 43 Prozent sowie finanzieller Aufwand mit 41 und technischer Aufwand mit 32 Prozent.

Interessant wird es, wenn man diese Zahlen neben die Auswahlkriterien legt. Bei der Wahl eines Anbieters gilt für 95 Prozent das Vertrauen in Sicherheit, Datenschutz und Compliance als Muss-Kriterium, für 91 Prozent die Leistungsfähigkeit. Eine einfache Wechselmöglichkeit halten dagegen nur 37 Prozent für unverzichtbar.

Das ist ein bemerkenswerter Widerspruch. Bei der Auswahl ist die Ausstiegsfähigkeit das Kriterium mit der geringsten Priorität. Beim Ausstieg ist sie das größte Hindernis. Die Ursache dafür wird nicht in der Cloud liegen, sondern in der menschlichen Neigung, den Anfang gründlicher zu planen als das Ende.

Was der EU Data Act daran ändert

Seit dem 12. September 2025 ist der EU Data Act anwendbar . Die Artikel 23 bis 31 verpflichten Anbieter von Datenverarbeitungsdiensten, den Wechsel technisch, vertraglich und finanziell zu erleichtern.

Konkret bedeutet das drei Dinge. Erstens dürfen Anbieter in der Übergangsphase bis Ende 2026 für den Datenexport nur noch die tatsächlich anfallenden Kosten berechnen. Ab dem 12. Januar 2027 sind Wechselgebühren vollständig verboten, Egress-Gebühren als Bindungsinstrument entfallen damit. Zweitens müssen Daten in einem maschinenlesbaren, standardisierten Format bereitgestellt werden. Drittens gilt für den Wechsel eine Übergangsfrist von grundsätzlich 30 Tagen, die sich verlängern lässt, wenn das technisch nicht anders machbar ist. Für Großprojekte wie die eingangs erwähnte Migration von Airbus mit hunderten geschäftskritischen Anwendungen wird der Data Act damit zu einem mächtigen Hebel: Solche massiven Wechsel werden künftig zumindest von der künstlichen Kostenbremse der Egress-Gebühren befreit, was die Verhandlungsposition von Unternehmen auf der Suche nach souveränen Alternativen stärkt.

Was er nicht ändert

Die Verordnung senkt rechtliche und finanzielle Hürden. Die technischen räumt sie nicht weg. Proprietäre Datenformate und tief integrierte Managed Services bleiben das eigentliche Problem, und gegen sie hilft kein Gesetz. Wer seine Anwendung um einen herstellerspezifischen Dienst herum gebaut hat, kann die Daten kostenfrei exportieren und steht trotzdem vor einer Neuentwicklung.

Hinzu kommt eine offene Flanke im Text selbst: Für vorzeitige Kündigungen erlaubt die Verordnung „verhältnismäßige Gebühren“, ohne diese zu definieren. Wie belastbar die neuen Rechte sind, wird sich erst zeigen. Bekannte Streitfälle oder behördliche Auslegungen gibt es bislang nicht.

Fünf Fragen, die vor der Unterschrift geklärt sein sollten

1. Wer hält die Schlüssel? Liegen sie beim Anbieter, bei uns oder in einem Hardware-Sicherheitsmodul unter unserer Kontrolle?
2. Wer kann administrativ zugreifen? Von wo aus, unter welcher Rechtsordnung, und wird es protokolliert?
3. Läuft der Dienst weiter, wenn der Hersteller morgen nicht mehr liefert? Und wie lange?
4. Wie sieht der Ausstiegspfad aus? Nicht in der Krise, sondern als Teil der Architekturentscheidung. Und: Wie viel herstellerspezifische Dienste verträgt diese Architektur, bevor der Pfad theoretisch wird?
5. Was steht zu Kündigungsgebühren im Vertrag? Die gesetzliche Wirkung ab 2027 ist eindeutig, die Ausnahme für vorzeitige Kündigungen ist es nicht.

Und wenn man kein Konzern ist?

Die Beispiele in diesem Artikel sind groß. Airbus, die EU-Kommission, die Bundesregierung, die Schwarz Gruppe. Daraus lässt sich leicht der Schluss ziehen, das Thema betreffe nur Organisationen mit eigener Rechtsabteilung und dreistelligen Millionenbudgets.

Der Schluss wäre falsch, aus drei Gründen. Erstens skaliert der abgestufte Ansatz nach unten. Kein mittelständisches Unternehmen wird eine Souveränitätsstrategie verfassen, aber jedes kann bei der nächsten Vertragsverlängerung die fünf Fragen von oben stellen. Das kostet eine Stunde. Zweitens gilt der Data Act unabhängig von der Unternehmensgröße, die Rechte aus den Artikeln 23 bis 31 stehen dem Zwanzig-Personen-Betrieb genauso zu wie dem Konzern. Drittens stammen die zitierten Bitkom-Zahlen aus einer Befragung von Unternehmen ab 20 Beschäftigten. Es sind keine Konzernzahlen.

Der Unterschied zwischen groß und klein liegt nicht in der Frage, sondern in der Antwort. Ein Konzern kann sich einen zweiten Anbieter leisten. Ein kleineres Unternehmen entscheidet möglicherweise, das Risiko bewusst zu tragen. Das ist eine vertretbare Entscheidung. Sie ist nur dann keine, wenn sie nie getroffen wurde.

Souveränität ist nicht dasselbe wie Sicherheit

An dieser Stelle ist ein Einschub nötig, weil der Artikel sonst mehr verspricht, als das Thema hergibt.

Souveränität ist keine Sicherheitseigenschaft. Ein europäischer Anbieter kann schlechter abgesichert sein als ein Hyperscaler. Die großen amerikanischen Anbieter unterhalten die personalstärksten Sicherheitsteams der Branche, und ein Wechsel zu einem kleineren Anbieter kann bedeuten, ein Risiko aus der fremden Rechtsordnung gegen ein Betriebsrisiko zu tauschen. Das ist kein Argument gegen den Wechsel. Es ist ein Argument dafür, beide Risiken zu benennen, statt eines davon für das einzige zu halten.

Verfügbarkeit hat mit Herkunft nichts zu tun. Am 20. Oktober 2025 fiel AWS für rund fünfzehn Stunden aus, bei Downdetector gingen über 17 Millionen Meldungen ein. Elf Tage zuvor legte eine Störung von Azure Front Door für rund neun Stunden große Teile der Azure-Verwaltung lahm. Beides zeigt ein Konzentrationsrisiko, kein Herkunftsproblem. Ein europäischer Monolith fällt genauso aus. Das Gegenmittel heißt Diversifizierung, und bezeichnenderweise haben genau das die EU-Kommission mit ihren vier Anbietern und der Bund mit seiner Siebzig-zu-dreißig-Aufteilung getan. Nicht Europa statt Amerika, sondern zwei statt einer.

Autarkie ist weder erreichbar noch das Ziel. Von den vier Anbietern, die die EU-Kommission beauftragt hat, erreichte keiner SEAL-4, also die durchgehend europäische Lieferkette vom Chip bis zur Software. Das ist zwar kein Beweis, dass es europaweit niemanden gäbe, denn bewertet wurden nur die Bieter dieser Ausschreibung. Aber wenn schon unter den vier bestbewerteten europäischen Anbietern keiner die höchste Stufe erreicht, sollte man vorsichtig sein mit der Forderung nach vollständiger Unabhängigkeit. Sinnvoll ist etwas anderes: ein abgestuftes Risikoprofil mit höheren Anforderungen für sensible und kritische Systeme und Standardanforderungen für den Rest. Genau das empfiehlt auch der Bitkom in seinem Positionspapier zu Kriterien für Cloud-Souveränität, und genau das macht Airbus.

Der Protektionismus-Einwand ist ernst zu nehmen. Herkunftsbezogene Vergabekriterien sind handelspolitisch angreifbar, und das ist keine theoretische Sorge. Das europäische Zertifizierungsschema EUCS hängt seit 2024 fest, weil sich die Mitgliedstaaten über genau diese Souveränitätsanforderungen nicht einigen können. Auch das SEAL-Modell ist kein neutraler Standard, sondern ein Instrument, das die Kommission für ihre eigene Beschaffung entwickelt und selbst angewendet hat. Es ist deshalb nützlich als Prüfraster, aber es ist keine unabhängige Zertifizierung. Wer souveräne Beschaffung fordert, sollte sagen können, wo für ihn die Grenze zwischen berechtigter Vorsorge und der Abschottung des europäischen Marktes gegen ausländische Anbieter verläuft.

Und schließlich der unbequemste Punkt. Nur zwölf Prozent der deutschen Unternehmen würden für eine Cloud, die Daten ausschließlich in Deutschland und geschützt vor ausländischem Zugriff verarbeitet, einen um zehn bis zwanzig Prozent höheren Preis zahlen. Das liest sich wie ein Beleg für Bequemlichkeit. Man kann es aber auch anders lesen: als rationale Risikoabwägung von Unternehmen, die für ihre Daten kein realistisches Zugriffsszenario sehen.

Bemerkenswert ist dabei, dass Airbus den Preis offenbar gar nicht als Hindernis erlebt hat. Nach Darstellung des Konzerns war das Angebot von Scaleway gegenüber den Public-Cloud-Angeboten der Hyperscaler wettbewerbsfähig. Ein Einzelfall trägt keine allgemeine Preisaussage, und die Bitkom-Frage zielte auf ein strengeres Produkt, nämlich eine rein deutsche Cloud. Trotzdem lohnt die Frage, ob das eigentliche Hindernis wirklich die Zahlungsbereitschaft ist oder die Annahme, es müsse überhaupt einen Aufpreis geben.

Was als Nächstes kommt, und was schon gilt

Wer die Debatte politisch verfolgt, könnte den Eindruck gewinnen, das eigentliche Regelwerk stehe noch aus. Das stimmt und führt zugleich in die Irre.

Am 3. Juni 2026 hat die Europäische Kommission das European Technological Sovereignty Package vorgelegt. Es besteht aus vier Teilen: dem Cloud and AI Development Act, einem Chips Act 2.0, einer EU Open Source Strategy und einer Roadmap für Digitalisierung und KI im Energiesektor.

Für unser Thema ist der Cloud and AI Development Act der zentrale Teil. Da über den Entwurf viel geschrieben und wenig zitiert wird, lohnt ein Blick in das Dokument selbst.

Vier Stufen, und der Nachweis wird ernst. Der Entwurf führt vier sogenannte Union Assurance Levels ein, deren Kriterien in Anhang II stehen. Stufe 1 lässt sich durch Selbstauskunft nachweisen, für die Stufen 2 bis 4 verlangt der Entwurf eine unabhängige Prüfung durch Dritte. Das ist der eigentliche Unterschied zum heutigen Zustand: Souveränität soll nicht mehr behauptet, sondern testiert werden.

Nicht jede Behörde muss die höchste Stufe beschaffen. Nach Artikel 30 müssen öffentliche Auftraggeber mindestens Stufe 1 beschaffen. Nur wenn eine Risikobewertung ergibt, dass die betreffende Tätigkeit für die öffentliche Ordnung relevant ist, sind die Stufen 2, 3 oder 4 zwingend. Der Erwägungsgrund dazu formuliert es unmissverständlich: Die meisten öffentlichen Dienste würden die höchsten Stufen nicht benötigen. Wer aus dem Gesetzentwurf eine europäische Abschottung herausliest, liest ihn nicht.

Die Tür für Drittstaatenanbieter bleibt ausdrücklich offen. Das ist der Fund, der mich beim Lesen am meisten überrascht hat. Der Entwurf sieht vor, dass die Kommission für Stufe 3 entscheiden kann, dass auch ein Dienst, der der Kontrolle eines Drittstaats oder einer dort ansässigen Rechtsperson unterliegt, gegen die Prüfkriterien auditiert werden darf. Voraussetzung ist, dass der Drittstaat Vorkehrungen getroffen hat, die einen unbefugten Zugriff auf Daten aus der EU sowie eine Beeinträchtigung von Qualität und Kontinuität des Dienstes ausschließen. Ausdrücklich zu prüfen ist dabei, ob ein Angemessenheitsbeschluss nach Artikel 45 DSGVO vorliegt und wie weit dieser reicht.

Das ist dieselbe Haltung, die schon aus der oben beschriebenen Vergabe vom April 2026 sprach, bei der ein Konsortium mit Google-Technologie das geforderte Mindestmaß erreichte. Es geht nicht um die Herkunft des Anbieters, sondern um überprüfbare Bedingungen.

Und der Preisdeckel für den Heimatbonus. Öffentliche Auftraggeber sollen einen europäischen Mehrwert in die Qualitätsbewertung einbeziehen, also den Beitrag zur digitalen Lieferkette in der Europäischen Union, die Integration europäischer Technologien und Hardwarekomponenten. Der Entwurf schränkt das aber selbst ein: Dieses Kriterium soll für die Vergabe nicht ausschlaggebend sein, und als Orientierung nennt er eine Höchstgewichtung von 15 von 120 Punkten. Das sind 12,5 Prozent. Wer Protektionismus befürchtet, sollte diese Zahl kennen.

Für Unternehmen steht ein Artikel drin, der leicht übersehen wird. Artikel 31 erlaubt Unternehmen aus den Sektoren der NIS2-Richtlinie, dieselben Bewertungen durchzuführen wie öffentliche Stellen. Der zugehörige Erwägungsgrund begründet das offen: Anforderungen des öffentlichen Sektors würden von privaten Unternehmen in regulierten Branchen typischerweise gespiegelt, mit Ausstrahlung auf den übrigen Markt. Die Kommission rechnet also damit, dass ihr Raster über die Beschaffung hinaus zum Marktstandard wird, und schafft dafür gleich die Rechtsgrundlage.

Und hier schließt sich der Bogen zum Open-Source-Artikel

Der Entwurf widmet Open Source ein eigenes Kapitel. Artikel 41 verpflichtet Unionsstellen und öffentliche Einrichtungen, den Einsatz quelloffener Lösungen gegenüber proprietären zu fördern und zu erleichtern. Artikel 42 regelt das Teilen und die Wiederverwendung von Software, Artikel 43 einen von der Kommission zu führenden Open Source Solutions Catalogue, Artikel 44 ein Netz nationaler Open Source Programme Offices.

Die Begründung dafür steht in den Erwägungsgründen, und sie liest sich wie eine Zusammenfassung des Open-Source-Artikels: Der Zugang zum Quellcode ermögliche Prüfbarkeit, fördere Zusammenarbeit und Wiederverwendung und verringere die Abhängigkeit von einem einzelnen Anbieter, wodurch das Risiko eines Lock-in begrenzt werde.

Das ist keine ideologische Setzung, sondern folgt aus der Systematik. Wer Technologiesouveränität verlangt, also die Fähigkeit, einen Dienst ohne den Hersteller weiterzubetreiben, landet zwangsläufig bei offenem Quellcode. Nicht weil offener Code sicherer wäre, das war die Pointe des Open-Source-Artikels, sondern weil geschlossener Code diese Fähigkeit strukturell ausschließt. Souveränität und Open Source sind damit keine zwei Themen, sondern zwei Formulierungen derselben Frage.

Eine Einschränkung gehört dazu: Anhang II mit den konkreten Kriterien der vier Stufen ist in der öffentlich verfügbaren Fassung des Entwurfs nicht enthalten. Wie streng die Stufen im Einzelnen ausfallen, lässt sich daher noch nicht beurteilen. Und ob die vier Stufen des Entwurfs sich eins zu eins auf die fünf SEAL-Stufen des Bewertungsrasters abbilden lassen, sagt der Text nicht. Das Bewertungsraster der Kommission ist der praktische Vorläufer, der Gesetzentwurf ist ein eigenes Instrument.

Nun der Realismus. Der Cloud and AI Development Act ist ein Vorschlag, kein Gesetz. Er muss durch Rat und Parlament, und mit einer Verabschiedung wird nicht vor Ende 2027 gerechnet. Wie zäh solche Verfahren werden können, zeigt das europäische Zertifizierungsschema für Cloud-Dienste, EUCS. Es liegt seit 2024 auf Eis, weil sich die Mitgliedstaaten über die Souveränitätsanforderungen nicht einigen können, also über genau die Frage, um die es auch hier geht.

Wer also auf die Regulierung wartet, wartet lange. Bemerkenswert ist deshalb, wie viel bereits gilt.

Der EU Data Act ist seit September 2025 anwendbar, und ab Januar 2027 sind Wechselgebühren verboten. Das ist geltendes Recht mit einem festen Datum und wirkt unabhängig davon, was aus dem Cloud and AI Development Act wird. Das Cloud Sovereignty Framework existiert, ist frei verfügbar und wurde in einer realen Vergabe angewendet. Und die drei Ebenen aus Daten-, Betriebs- und Technologiesouveränität lassen sich schon heute als Fragenkatalog benutzen, ohne dass irgendjemand sie vorschreibt.

Die interessante Beobachtung dabei: Was heute schon wirkt, wirkt nicht über Verbote, sondern über Beweglichkeit und Nachprüfbarkeit. Der Data Act zwingt niemanden zu wechseln, er macht das Wechseln nur möglich. Das Framework verbietet keinen Anbieter, es macht Unterschiede sichtbar. Man kann darin eine Schwäche sehen. Man kann darin auch den Grund sehen, warum es funktioniert.

Fazit

Der Artikel Open Source und Unternehmenssicherheit: Kontrolle statt Vertrauen endete mit einem unbequemen Befund: Offener Quellcode macht Software nicht automatisch sicher, er ermöglicht nur die Kontrolle. Und diese Möglichkeit nützt nichts, wenn niemand sie ausübt.

Bei der Cloud verschiebt sich der Satz um eine Nuance, und die Nuance ist entscheidend. Prüfen lässt sich hier durchaus einiges. Zertifizierungen, unabhängige Audits und Einsichtsrechte decken Technik und Prozesse weitgehend ab. Was sie nicht abdecken, ist die Frage, wem ein Anbieter im Konfliktfall folgt. Für diesen einen Punkt gibt es keinen Prüfbericht, sondern nur eine Zusicherung.

Genau deshalb ist das, was im April 2026 geschehen ist, wichtiger als jede Produktankündigung der Cloud-Anbieter im vergangenen Jahr. Zum ersten Mal wurde Souveränität nicht behauptet, sondern gemessen, nach offengelegten Kriterien, mit einem Ergebnis, das die Beteiligten nicht selbst formuliert haben. Das Raster ist nicht neutral und nicht perfekt, aber es ist überprüfbar. Und überprüfbar ist genau das, was diesem Thema bislang gefehlt hat.

Die Ergebnisse fallen dabei unbequem für beide Lager aus. Der Anbieter, der bei der Betriebstrennung am weitesten geht, erreicht nicht die höchste Stufe, weil Betrieb und Technologie zwei verschiedene Dinge sind. Und die höchste Stufe erreicht ohnehin niemand. Wer vollständige Unabhängigkeit fordert, fordert etwas, das derzeit niemand liefert, und wer den europäischen Angeboten pauschal die Substanz abspricht, ignoriert drei Anbieter, die in einem geprüften Verfahren besser abgeschnitten haben als das Feld erwarten ließ.

Was bleibt, ist eine Frage der Sortierung. Airbus verlässt Amazon nicht, sondern verlagert die Anwendungen, ohne die der Konzern nicht arbeiten kann, und lässt den Rest, wo er ist. Die EU-Kommission wählt vier Anbieter statt einem. Der Bund teilt seinen Auftrag siebzig zu dreißig. In allen drei Fällen lautet die Entscheidung nicht Europa statt Amerika, sondern: Welche Systeme müssen weiterlaufen, wenn etwas passiert, das wir nicht steuern?

Diese Frage kann jede Organisation beantworten, unabhängig von ihrer Größe. Am Ende steht zunächst keine Migration, sondern eine Liste mit den wenigen wirklich kritischen Systemen. Für diese Liste lohnen die strengeren Anforderungen, für den Rest genügen die üblichen.

Damit ist auch die oberste Stufe der Kontrolltreppe beschrieben, die der Open-Source-Artikel offen gelassen hatte. Sie unterscheidet sich von den vier darunter in einem Punkt: Die anderen kann man selbst erklimmen, wenn man Personal und Zeit investiert. Diese hier hängt an einer Entscheidung, die vor dem Vertrag getroffen werden muss.

Souveränität ist deshalb kein Zustand, den man erreicht, und kein Produkt, das man kauft. Sie ist eine Entscheidung darüber, welche Abhängigkeiten man bewusst eingeht. Der Unterschied zwischen einem souveränen und einem abhängigen Unternehmen liegt weniger in der Wahl des Anbieters als in der Frage, ob diese Entscheidung überhaupt jemals getroffen wurde.