KI-Cloud: 250 Millionen Euro und die neue Abhängigkeit

Die neue KI-Cloud des Bundes klingt nach digitaler Souveränität, riecht aber nach dem nächsten Anbieter-Lock-in. 250 Millionen Euro fließen an zwei Konsortien um T-Systems, SAP und SVA. Der eigentliche Test lautet deshalb nicht: Wer betreibt die Cloud? Sondern: Wem gehört am Ende die Kontrolle über Code, Daten und Wechselwege?

250 Millionen Euro für eine KI-Cloud, die der öffentlichen Verwaltung den nächsten Digitalisierungsschub geben soll: Auf dem Papier ist das genau die Art Nachricht, auf die deutsche Behörden seit Jahren warten. Mehr Rechenleistung. Eine zentrale Plattform. KI-Anwendungen für Dokumente, Übersetzungen, Zusammenfassungen und Fachverfahren. Endlich weniger PDF-Pingpong, weniger Amtsstube mit Faxgeruch.

Und trotzdem kratzt etwas an dieser Geschichte.

Denn die Bundesregierung verkauft den Zuschlag als Schritt zu digitaler Souveränität. Kritische Stimmen sehen darin eher einen Anbieterwechsel mit besserem Etikett. Weg von US-Konzernen, hin zu deutschen oder europäischen Konzernen. Das ist politisch leichter zu erklären. Technisch löst es aber nur einen Teil des Problems. Wer von Microsoft zu SAP wandert, ist nicht automatisch frei. Manchmal sitzt man nur in einem anderen goldenen Käfig.

Wir bei digital-magazin.de haben uns angeschaut, worum es bei der neuen KI-Cloud geht, warum die Vergabe an T-Systems, SAP und SVA so brisant ist und weshalb Open Source in dieser Debatte nicht als romantische Nebenidee behandelt werden sollte.

KI-Cloud des Bundes: Was konkret vergeben wurde

Das Bundesministerium für Digitales und Staatsmodernisierung hat ein europaweites Vergabeverfahren für eine souveräne KI-Cloud abgeschlossen. Laut Pressemitteilung des BMDS geht der Zuschlag an zwei Konsortien: Erstplatzierter Bieter ist ein Konsortium um T-Systems International, zweitplatziert ist ein Konsortium um die SVA System Vertrieb Alexander GmbH.

Das Volumen liegt bei knapp 250 Millionen Euro. Nach Medienberichten sollen rund 70 Prozent an das Telekom/SAP-Lager gehen, etwa 30 Prozent an SVA. Der Zuschnitt ist bewusst zweigeteilt. Die Idee dahinter: Wenn nicht ein einzelner Anbieter alles kontrolliert, sinkt das Risiko einer totalen Abhängigkeit.

Das klingt vernünftig. Zwei Türen sind besser als eine.

Nur entscheidet die Anzahl der Türen nicht darüber, ob man das Gebäude verlassen kann. Bei Cloud-Plattformen zählen andere Fragen: Sind Schnittstellen offen dokumentiert? Laufen Workloads portabel? Kann die Verwaltung Daten samt Fachlogik ohne teuren Spezialumbau umziehen? Sind Modelle, Komponenten und Betriebsprozesse austauschbar? Oder entsteht mit jeder neuen Anwendung eine weitere Schicht proprietärer Klebstoff?

Genau hier beginnt der Streit um digitale Souveränität. Der Bund will eine Plattform, die KI-Anwendungen für Behörden bündelt. Geplant ist unter anderem, die KI-Plattform KIPITZ auf diese neue Infrastruktur zu bringen. KIPITZ soll Beschäftigte in Behörden bei Aufgaben wie Dokumentenzusammenfassung, Übersetzung, Schwärzung, Transkription und Recherche unterstützen. Das klingt weniger nach Science-Fiction als nach dringend nötiger Verwaltungshygiene.

Wer sich tiefer mit dem Thema beschäftigt, landet schnell bei der größeren Frage, die wir schon in unserem Beitrag über digitale Souveränität als Cloud-Strategie beschrieben haben: Souveränität ist kein Herkunftsstempel. Sie ist eine technische Eigenschaft.

Digitale Souveränität ist mehr als „buy european“

Die politische Versuchung ist nachvollziehbar. Wenn US-Plattformen als Risiko gelten, kauft man europäisch. Wenn Microsoft-Lizenzen teuer werden, schaut man zu SAP, Telekom, IONOS, OVHcloud oder anderen europäischen Schwergewichten. Das lässt sich gut erklären. Es klingt nach Kontrolle, Arbeitsplätzen, strategischer Industriepolitik.

Aber die Gleichung „europäischer Anbieter = souveräne IT“ ist zu bequem.

Digitale Souveränität besteht aus mehreren Schichten. Erstens: rechtliche Kontrolle. Wo werden Daten verarbeitet? Welche Rechtsräume greifen? Wer darf Zugriffe erzwingen? Zweitens: technische Kontrolle. Sind Systeme nachvollziehbar, überprüfbar und ersetzbar? Drittens: organisatorische Kontrolle. Hat die öffentliche Hand selbst genug Wissen, um Architekturentscheidungen zu treffen, Anbieter zu steuern und Wechsel vorzubereiten?

Deutschland scheitert oft nicht an der ersten Schicht, sondern an der dritten. Behörden kaufen ein System, lassen es von externen Dienstleistenden anpassen, bauen Fachverfahren darum herum und merken Jahre später: Ein Wechsel wäre möglich, aber nur mit Migrationsprojekt, Datenchaos, Beratungsbudget und politischem Pulsrasen.

Das ist der Lock-in-Effekt. Er fragt nicht nach Nationalität.

Netzpolitik.org berichtet, dass die Linksfraktions-Abgeordnete Sonja Lemke genau davor warnt: US-Konzerne hätten kein Patent darauf, Kundschaft abhängig zu machen. Entscheidend sei, wie ein IT-Produkt gebaut ist. Wenn Daten, Prozesse und Erweiterungen tief in proprietäre Strukturen rutschen, wird der spätere Ausstieg teuer. Egal, ob das Logo aus Redmond, Walldorf oder Bonn kommt.

Ich finde diese Warnung ziemlich treffend. Nicht, weil SAP oder T-Systems automatisch schlechte Partner wären. Das wäre zu billig. Sondern weil die öffentliche Hand seit Jahrzehnten beweist, dass sie Abhängigkeit oft erst dann bemerkt, wenn die Rechnung schon im Haushalt steht.

Cloud-Kosten: Microsoft zeigt, wie teuer Gewohnheit wird

Der Blick auf Microsoft macht das Problem greifbar. Der Bund gab laut Berichten im Haushaltsjahr 2025 rund 481 Millionen Euro für Microsoft-Lizenzen aus. In den Jahren davor stiegen die Kosten deutlich: von rund 274 Millionen Euro auf rund 348 Millionen Euro und dann weiter nach oben. Das ist nicht nur ein Lizenzthema. Das ist ein Strukturthema.

Wer jahrelang E-Mail, Office, Identitätsverwaltung, Dateiablage, Kollaboration und Fachprozesse an einen Ökosystemanbieter koppelt, zahlt nicht nur für Software. Er zahlt für Gewohnheit, Schulungsmaterial, Administrationsroutinen, Kompatibilität, Makros, Schnittstellen und Angst vor Ausfällen. Die Lizenzrechnung ist nur der sichtbare Teil.

Deshalb geht es bei der KI-Cloud nicht bloß um 250 Millionen Euro. Diese Summe ist der Einstieg. Spannender sind die Folgekosten: Welche Anwendungen entstehen auf der Plattform? Welche Behörden hängen sich daran? Welche Datenflüsse werden aufgebaut? Welche Betriebsprozesse werden auf einen Anbieterzuschnitt trainiert?

Wenn die Architektur offen genug ist, kann die KI-Cloud ein Baustein werden, der Behörden tatsächlich beweglicher macht. Wenn nicht, baut Deutschland die nächste zentrale Plattform, deren Wechselkosten später politisch niemand anfassen möchte.

Das Team von digital-magazin.de sieht bei solchen Plattformentscheidungen immer denselben Mechanismus: Am Anfang ist alles modular. In der Praxis kommen Zeitdruck, Sonderwünsche und knappe IT-Teams dazu. Dann werden Abkürzungen genommen. Aus einer Plattform wird ein Dickicht. Und irgendwann heißt es: „Das können wir nicht einfach migrieren.“ Genau dort beginnt Abhängigkeit.

Open Source ist kein Feigenblatt, sondern Exit-Strategie

Das BMDS betont, dass offene Standards, Schnittstellen und Open-Source-Komponenten die technische Basis der KI-Cloud bilden sollen. Dieser Satz ist wichtig. Aber er reicht nicht.

Open Source kann sehr unterschiedlich gemeint sein. Es kann heißen: Einzelne Bibliotheken unter freier Lizenz laufen irgendwo im Maschinenraum. Es kann aber auch heißen: zentrale Komponenten, Schnittstellen, Deployment-Rezepte, Konfigurationslogik und Sicherheitsprüfungen sind nachvollziehbar, wiederverwendbar und öffentlich prüfbar. Zwischen diesen beiden Varianten liegen Welten.

Die Free Software Foundation Europe bringt das seit Jahren mit dem Satz „Public Money? Public Code!“ auf den Punkt. Wenn öffentliche Gelder Software finanzieren, sollte der Code auch öffentlich nutzbar sein. Das ist keine Folklore aus der Linux-Ecke. Es ist eine Beschaffungsstrategie.

Der Vorteil liegt nicht nur darin, dass irgendwer auf GitHub mitlesen darf. Freier Code verändert die Verhandlungsmacht. Wenn eine Behörde eine Software prüfen, betreiben, weiterentwickeln und im Zweifel an andere Dienstleistende übergeben kann, sinkt die Erpressbarkeit. Wartung bleibt ein Markt, kein Monopol.

Natürlich löst Open Source nicht jedes Problem. Auch freie Software braucht Pflege, Sicherheitsprozesse, Dokumentation, Verantwortliche und Geld. Wer glaubt, man könne proprietäre Millionenverträge einfach durch „da ist ein Repo“ ersetzen, hat noch nie ein Behördenprojekt von innen gesehen.

Aber Open Source ist die Voraussetzung dafür, dass öffentliche IT nicht immer wieder in denselben Tunnel läuft. Das gilt für Chat- und Kollaborationssysteme genauso wie für KI-Plattformen. Unser Vergleich zu Open-Source-Chat-Servern als europäische Alternative zeigt denselben Kern: Die Frage ist nicht, ob freie Software hübscher ist. Die Frage ist, ob man später noch selbst entscheiden kann.

KIPITZ: gute Idee, kritische Infrastruktur

KIPITZ ist einer der spannendsten Teile der Geschichte. Das ITZBund beschreibt die Plattform als behördenübergreifendes Werkzeug für generative KI. Beschäftigte sollen mit Sprachmodellen chatten, Dokumente zusammenfassen, Dateien befragen, Texte übersetzen, Inhalte schwärzen und Sprache transkribieren können. Außerdem sollen Wissensdatenbanken angebunden werden, damit Behörden eigenes Wissen über Retrieval-Augmented Generation nutzbar machen können.

Für die Verwaltung kann das sehr sinnvoll sein. Wer je mit Akten, Formularen, Fachverfahren und langen Abstimmungsketten gearbeitet hat, weiß: Gute Assistenzsysteme könnten enorm viel stumpfe Sortierarbeit reduzieren. Nicht jede KI-Anwendung ist ein Chatbot mit Zauberhut. Manchmal ist sie schlicht ein brauchbares Werkzeug, das eine 80-seitige Anlage schneller erschließt.

Gerade deshalb ist die Plattform kritisch.

Wenn KIPITZ zur zentralen Arbeitsumgebung für KI in Bundesbehörden wird, entsteht ein neuer Machtpunkt. Dort laufen Dokumente, Metadaten, Suchindizes, Modellzugriffe, Berechtigungen und behördenspezifisches Wissen zusammen. Wer diese Ebene kontrolliert, prägt später auch, welche KI-Modelle leicht angebunden werden, welche Sicherheitsprüfungen Standard sind und wie teuer Wechsel werden.

Das ITZBund schreibt, KIPITZ habe keine Herstellerbindung an bestimmte KI-Modelle und könne verschiedene Modelle anwendungsbezogen ansteuern. Das ist gut. Jetzt muss diese Offenheit in der Beschaffung, im Betrieb und in der Weiterentwicklung auch wirklich hart verdrahtet werden. Nicht als Marketingzeile. Als Architekturprinzip mit Tests, Dokumentation und Ausstiegspfaden.

Souveränität braucht harte Kriterien, keine hübschen Pressezitate

Wenn der Bund aus der Microsoft-Erfahrung lernen will, sollte er die KI-Cloud nicht nur nach Verfügbarkeit, Preis und Compliance bewerten. Er braucht harte Souveränitätskriterien. Sonst wird das Wort zur politischen Tapete.

Ein paar Fragen gehören in jedes Lastenheft:

• Portabilität: Können Anwendungen mit vertretbarem Aufwand zu einem anderen Betreiber wechseln, ohne dass Fachverfahren neu gebaut werden müssen?
• Datenkontrolle: Lassen sich Daten, Vektordatenbanken, Protokolle und Modellartefakte vollständig exportieren, dokumentiert und maschinenlesbar?
• Schnittstellen: Sind APIs offen beschrieben, versioniert und unabhängig von proprietären Sonderfunktionen?
• Code-Zugang: Welche Teile werden als freie Software veröffentlicht, welche bleiben geschlossen und warum?
• Betriebswissen: Baut die Verwaltung eigenes Know-how auf oder entsteht wieder eine Beraterkaskade?

Das klingt trocken. Ist es auch. Aber genau an solchen Punkten entscheidet sich, ob Souveränität später mehr ist als ein hübscher Satz in einer Pressemitteilung.

Man sieht das auch bei Unternehmen, die Microsoft 365 ersetzen wollen. Die eigentliche Herausforderung ist selten das einzelne Tool, sondern das Geflecht aus Identitäten, Dateien, Kalendern, Workflows und Gewohnheiten. Wer unseren Überblick zu Open-Source-Alternativen zu Microsoft 365 gelesen hat, kennt das Muster: Die Technik ist machbar. Der Wechsel scheitert oft an Organisation, Mut und sauberem Migrationsplan.

Der blinde Fleck: Verwaltungskompetenz

Eine souveräne KI-Cloud kann nicht allein von Dienstleistenden gebaut werden. Sie braucht eine Verwaltung, die selbst technische Entscheidungen treffen kann. Das ist unbequem, weil es nicht mit einem Zuschlag erledigt ist. Es heißt: bessere IT-Karrieren im öffentlichen Dienst, weniger Projektwissen in externen Präsentationen, mehr Architekturkompetenz in den Behörden.

Deutschland kauft sich gern Digitalisierung ein. Das funktioniert für Standarddienste. Bei strategischer Infrastruktur wird es riskant. Wenn die öffentliche Hand nicht versteht, was sie beschafft, kann sie auch keine echte Kontrolle ausüben. Dann wird aus „Partner steuern“ schnell „Partner glauben“.

Die KI-Cloud berührt außerdem Sicherheitsfragen. Behörden werden dort nicht nur harmlose Textbausteine verarbeiten. Es geht um Verwaltungsdokumente, interne Vorgänge, möglicherweise eingestufte Informationen und Wissensbestände, die in falschen Händen sehr nützlich wären. Eine souveräne Architektur muss deshalb erklären können, wie Logging, Zugriffskontrolle, Modellwahl, Prompt-Daten, RAG-Indizes und Löschkonzepte zusammenspielen.

Bei KI-Agenten wird diese Frage noch schärfer. Sobald Systeme nicht mehr nur Antworten geben, sondern Werkzeuge bedienen, Akten prüfen oder Vorgänge anstoßen, steigt das Risiko. In unserem Artikel zu Open-Source-KI-Agenten im Enterprise-Einsatz ging es genau um diese neue Lage: Agenten brauchen Leitplanken, Auditierbarkeit und Grenzen. Für Behörden gilt das doppelt.

Was der Bund jetzt beweisen muss

Der Auftrag an T-Systems, SAP und SVA ist nicht automatisch falsch. Im Gegenteil: Eine zentrale, sichere KI-Infrastruktur für die Verwaltung ist überfällig. Wenn Deutschland ernsthaft digitale Verwaltungsprozesse beschleunigen will, braucht es Plattformen, auf denen Fachverfahren, Assistenzsysteme und generative Dienste kontrolliert laufen können.

Aber der Bund muss jetzt beweisen, dass er aus der Vergangenheit gelernt hat.

Dazu gehört Transparenz über Architekturentscheidungen. Dazu gehört ein klarer Plan, welche Komponenten offen veröffentlicht werden. Dazu gehört ein Exit-Konzept, das nicht erst dann geschrieben wird, wenn der erste Anbieterwechsel politisch gewünscht ist. Und dazu gehört die Bereitschaft, öffentliche IT nicht nur als Einkaufsproblem zu behandeln.

Meine Einschätzung: Die KI-Cloud wird nur dann ein Souveränitätsprojekt, wenn der Bund die unbequemen Details öffentlich macht. Welche Standards gelten? Welche proprietären Komponenten sind gesetzt? Welche Open-Source-Anteile sind Kernbestandteil und welche nur Beiwerk? Wie wird verhindert, dass KIPITZ und spätere Fachverfahren an eine bestimmte Betriebslogik gekettet werden?

Sonst bleibt am Ende eine vertraute deutsche IT-Geschichte: viel Geld, große Worte, gute Absichten und später ein System, aus dem niemand mehr raus will, weil der Ausgang zu teuer geworden ist.

Der Punkt ist: Kontrolle muss messbar sein

Digitale Souveränität ist kein Gefühl. Sie lässt sich messen: an offenen Schnittstellen, überprüfbarem Code, portablen Daten, dokumentierten Betriebsprozessen und interner Kompetenz. Genau daran sollte die neue KI-Cloud gemessen werden.

Wenn der Bund für 250 Millionen Euro eine Plattform bekommt, die Behörden sicherer, schneller und unabhängiger macht, wäre das gut angelegtes Geld. Wenn er nur neue Abhängigkeiten mit europäischer Verpackung kauft, wird die Rechnung später höher. Nicht nur finanziell, sondern politisch.

Die Verwaltung braucht KI-Werkzeuge. Klar. Aber sie braucht noch dringender die Fähigkeit, diese Werkzeuge selbstbestimmt zu betreiben, zu prüfen und wieder zu verlassen. Alles andere ist keine Souveränität. Es ist Outsourcing mit besserer Pressearbeit.