Alle Artikel
News 24. August 2026 11 Min. Lesezeit

Deutschland-Stack wird operativ: Was die Bundes-KI-Cloud dem Mittelstand vorgibt

Mit dem Zuschlag vom 21. Mai 2026 hat der Bund knapp 250 Millionen Euro in eine souveräne KI-Plattform investiert – ohne Anteil für einen US-Hyperscaler. Interessant sind weniger die Beteiligten als die Anforderungen, die dabei berichtet werden: Zero Trust, Bring Your Own Key und eine Bindung an offene Komponenten. Genau daraus lässt sich ein Mittelstands-Stack ableiten.

Deutschland-Stack – drei Ebenen, drei Anforderungen
Ebene 1 · Infrastruktur
Rechenzentrum & GPU-Ressourcen
BSI-zertifizierte Basis, Standort Deutschland
Ebene 2 · Plattform
Container, Orchestrierung, Modell-Serving
offene Schnittstellen statt proprietärer Formate
Ebene 3 · Anwendung
Chat, Dokumentenanalyse, Übersetzung
je Behörde ein eigenes Portal
Zero Trust
BYOK
Open Source
greifen über alle drei Ebenen
KI-Transparenzhinweis: Dieser Beitrag wurde teilweise mit Unterstützung von KI-Systemen erstellt und vor der Veröffentlichung redaktionell geprüft. Kennzeichnung gemäß EU-KI-Verordnung (Verordnung (EU) 2024/1689).
Kurz gefasst

Der Bund hat am 21. Mai 2026 den Zuschlag für eine souveräne KI-Cloud über knapp 250 Millionen Euro erteilt – 70 Prozent an T-Systems und SAP, 30 Prozent an ein Konsortium um SVA. Kein Los ging an einen US-Hyperscaler.

Für Unternehmen ist das kein Angebot, sondern eine Blaupause: Zero-Trust-Zugriff, eigene Schlüsselhoheit und offene Schnittstellen lassen sich als Mindestanforderung in jede eigene KI-Ausschreibung übernehmen – im Rack-Maßstab in Wochen statt in Jahren.

Öffentliche Großvergaben sind für den Mittelstand normalerweise Hintergrundrauschen: zu groß, zu langsam, zu weit weg vom eigenen Alltag. Die KI-Cloud des Bundes ist die Ausnahme. Nicht wegen der Summe und nicht wegen der Namen auf dem Vertrag, sondern weil hier zum ersten Mal öffentlich nachvollziehbar wird, welche Eigenschaften eine KI-Plattform haben muss, damit ein deutscher Beschaffer sie als souverän akzeptiert.

Genau das ist der Wert dieses Vorgangs für jedes Unternehmen, das gerade über eine eigene KI-Plattform nachdenkt: Sie müssen die Anforderungsliste nicht selbst erfinden. Sie existiert bereits – im Maßstab des Bundes, aber mit Prinzipien, die sich auf ein einzelnes Rack herunterbrechen lassen.

Was der Bund tatsächlich beschafft hat

Am 21. Mai 2026 teilte das Bundesministerium für Digitales und Staatsmodernisierung (BMDS) in Berlin mit, dass der Zuschlag für die KI-Cloud des Bundes erteilt ist. Die dpa spricht von „knapp 250 Millionen Euro“. Rechtskräftig wurde die Vergabe allerdings erst, nachdem das unterlegene Konkurrenzkonsortium aus Google und der Dortmunder adesso seine Vergaberüge bei der Vergabekammer zurückgezogen hatte – gemeldet am 20. Mai 2026, also einen Tag vor der Bekanntgabe. Der Vorgang war deutlich weniger glatt, als die Pressemitteilungen nahelegen.

Bewusst zweigeteilt

Der Auftrag wurde geteilt, um die Abhängigkeit von einem einzigen Lieferanten zu vermeiden. Rund 70 Prozent gehen an das Konsortium aus der Telekom-Tochter T-Systems als Generalunternehmer und SAP als Technologiepartner mit der SAP Business AI Platform. Rund 30 Prozent gehen an ein Konsortium um die Wiesbadener SVA System Vertrieb Alexander GmbH. Kein Los ging an einen US-Hyperscaler.

Wie sich das zweite Konsortium intern aufteilt, berichtet die Fachpresse – amtlich bestätigt ist es nicht: SVA verantwortet demnach Architektur und Integration, Schwarz Digits liefert mit der BSI-zertifizierten StackIT-Cloud die Infrastrukturschicht, Codesphere den Plattform-Layer. Die dpa nennt in ihrer Meldung nur SVA.

Auch die verbreitete Einordnung als „Platform-as-a-Service“ stammt aus der Fachpresse, nicht aus dem Vergabewortlaut. BMDS und dpa formulieren neutraler: eine KI-Plattform beziehungsweise Cloud-KI-Dienste, die laut Ministerium „zur zentralen Schaltstelle für die öffentliche Verwaltung“ werden sollen. Digitalminister Karsten Wildberger (CDU) spricht vom „Rückgrat einer souveränen, digitalen und KI-fähigen Verwaltung in Deutschland“ und von „einer Infrastruktur, die wir selbst kontrollieren – sicher, skalierbar und europäisch anschlussfähig“. Telekom-Chef Tim Höttges wurde deutlicher: „Europa hat enormen Nachholbedarf, den wir nicht mit Diskussionen, sondern nur mit Taten beheben.“

Wie groß ist „groß“ eigentlich?

250 Millionen Euro klingen nach einer beeindruckenden Zahl. Der Vergleich mit den laufenden Lizenzausgaben des Bundes relativiert sie erheblich. netzpolitik.org hat die Werte am 27. Mai 2026 aus einer Antwort der Bundesregierung auf eine Schriftliche Frage der Linken-Abgeordneten Sonja Lemke zusammengetragen:

Posten Zeitraum Betrag
Microsoft-Lizenzen des Bundes Haushaltsjahr 2025 481 Mio. €
Microsoft-Lizenzen des Bundes Haushaltsjahr 2024 rund 348 Mio. €
Microsoft-Lizenzen des Bundes Haushaltsjahr 2023 rund 274 Mio. €
SAP-Lizenzen Haushaltsjahr 2025 110 Mio. €
SAP-Produkte und -Dienstleistungen Haushaltsjahr 2025 71 Mio. €
KI-Cloud des Bundes (Gesamtvolumen) Vergabe 21.05.2026 knapp 250 Mio. €

Die gesamte souveräne KI-Cloud kostet damit gut die Hälfte dessen, was der Bund in einem einzigen Jahr an Microsoft-Lizenzgebühren überweist. Wer diese Relation einmal gesehen hat, argumentiert im eigenen Haus anders über die Kosten einer On-Premise-Plattform: Der Vergleichsmaßstab ist nicht null, sondern die Summe der Lizenz- und API-Rechnungen, die ohnehin jedes Jahr fällig werden.

Die drei Anforderungen – und was daran belegt ist

Der spannendste Teil dieser Vergabe ist zugleich der am schwächsten dokumentierte. Nach Berichten über den Vergabetext – die Quelle dafür ist ausschließlich das Cloudmagazin – waren drei technische Punkte Bedingung: eine Zero-Trust-Architektur, Bring Your Own Key mit Schlüsselhoheit bei der nutzenden Behörde und eine Bindung an offene Schnittstellen beziehungsweise Open-Source-Komponenten. In den dpa-Meldungen und den BMDS-Mitteilungen tauchen diese drei Punkte nicht auf.

Diese Einschränkung ist wichtig, ändert aber am praktischen Nutzen wenig. Denn die drei Punkte sind keine exotischen Sonderwünsche, sondern exakt das Anforderungstrio, das jedes Unternehmen an einen KI-Anbieter stellen sollte:

  • Zero Trust für jeden Zugriff. Kein Nutzer, kein Dienst und kein Netzsegment gilt als vertrauenswürdig, nur weil er sich innerhalb der Perimetergrenze befindet. Jeder Zugriff auf ein Modell, einen Index oder ein Dokument wird einzeln authentifiziert und autorisiert. Für KI-Plattformen ist das doppelt relevant, weil ein Sprachmodell technisch nicht zwischen berechtigter und unberechtigter Frage unterscheidet – die Grenze muss davor gezogen werden.
  • BYOK: Schlüsselhoheit bleibt beim Nutzer. Die Verschlüsselung der Daten erfolgt mit Schlüsseln, die der Kunde erzeugt, verwaltet und jederzeit zurückziehen kann. Der Betreiber sieht Chiffrat, keinen Klartext.
  • Offene Schnittstellen gegen Lock-in. Der Auftraggeber will die Möglichkeit behalten, Komponenten auszutauschen, ohne die Plattform neu zu bauen. Das ist keine ideologische Frage, sondern eine Verhandlungsposition bei der nächsten Vertragsverlängerung.

Die Gegenrede: Souveränität entsteht nicht durch Anbieterwechsel

Opposition und Fachleute warnen, dass die Vergabe an europäische Anbieter allein noch keine Souveränität schafft. Sonja Lemke (Die Linke) formuliert es so: US-Konzerne hätten „kein Patent darauf“, Kunden abhängig zu machen. Lock-in hänge nicht am Firmensitz, sondern an der Produktgestaltung – „wer einmal SAP nutzt, kann die eigenen Daten nicht mehr einfach zu einem anderen Anbieter umziehen“. Die Free Software Foundation Europe pocht ergänzend auf „Public Money, Public Code“.

Das ist der entscheidende Prüfstein, auch für die eigene Beschaffung: Ein Anbieter aus Deutschland, dessen Datenmodell proprietär und dessen Exportfunktion rudimentär ist, erzeugt denselben Lock-in wie ein Hyperscaler – nur mit besserem Gefühl. Die Frage lautet nicht „Wo sitzt der Anbieter?“, sondern „Was kann ich mitnehmen, wenn ich gehe?“.

Die brauchbare Testfrage: Lassen Sie sich vom Anbieter nicht die Souveränität erklären, sondern den Exit demonstrieren. Wie kommen Modelle, Prompts, Vektorindizes, Rechteregeln und Protokolldaten in einem dokumentierten Format aus dem System – ohne Zutun des Anbieters? Wer darauf keine Antwort in Werkzeugform hat, verkauft Lock-in mit europäischem Etikett.

Warum BYOK on-premise kein Zusatzprodukt ist

BYOK ist in der Cloud eine aufwendige Konstruktion. Der Betreiber muss Schlüsselmaterial fernhalten, das er technisch erreichen könnte; er muss Prozesse, Rollen und Auditpfade so bauen, dass die eigene Administration ausgeschlossen bleibt. Das funktioniert – aber es ist ein nachträglich eingezogener Sicherheitsmechanismus gegen den Betreiber selbst. Entsprechend erscheint BYOK bei vielen Anbietern erst in den höheren Tarifstufen.

Auf eigener Hardware entfällt dieses ganze Konstrukt, weil es das Problem nicht gibt, gegen das es sich richtet. Es existiert kein Dritter, der Klartext sehen könnte. Die Schlüssel liegen im eigenen Hardware-Security-Modul oder in einem selbst betriebenen Vault, die Rotation folgt der eigenen Policy, und der Widerruf eines Schlüssels muss mit niemandem abgestimmt werden.

Praktisch heißt das drei Dinge:

  1. Kein Betreiber im Vertrauensmodell. Die Frage „Wer könnte theoretisch mitlesen?“ hat auf eigener Infrastruktur eine kurze Antwort: nur, wer im eigenen Haus dazu berechtigt ist. Das vereinfacht auch die Dokumentation gegenüber dem Datenschutzbeauftragten erheblich.
  2. Schlüsselverwaltung als Hausaufgabe, nicht als Vertragsgegenstand. HSM oder Vault, Rotationsintervall, Vier-Augen-Prinzip beim Restore – alles interne Prozessfragen, keine Verhandlungspunkte.
  3. Keine Aufpreisdiskussion um Souveränitätsfunktionen. Was in der Cloud ein kostenpflichtiges Enterprise-Feature ist, ist im eigenen Rack der Auslieferungszustand.

Fairerweise gehört dazu die andere Seite der Medaille: Wer die Schlüssel hält, haftet auch für ihren Verlust. Ein verlorener Master-Key bedeutet auf eigener Hardware unwiederbringlich verlorene Daten, ohne Support-Ticket als Rettungsanker. Schlüsselhoheit ist eine Verantwortung, kein Komfortmerkmal – und sie verlangt ein dokumentiertes Backup- und Wiederherstellungsverfahren, bevor das erste produktive LLM ans Netz geht.

Compliance-Basis und die nächste Stufe: C3A

Als Sicherheitsniveau gelten in solchen Vergaben ISO 27001 und der BSI-Kriterienkatalog C5. Beides ist Einstiegsniveau, kein Alleinstellungsmerkmal: C5 bescheinigt einem Cloud-Dienst geprüfte Informationssicherheit, sagt aber nichts darüber aus, wer im Zweifel Zugriff auf die Infrastruktur erzwingen kann.

Genau diese Lücke adressiert der neue Katalog C3A – „Criteria enabling Cloud Computing Autonomy“, den das BSI am 27. April 2026 veröffentlicht hat, zunächst in englischer Sprache; eine deutsche Fassung war für Ende des zweiten Quartals 2026 angekündigt. C3A setzt voraus, dass ein Anbieter die C5-Kriterien bereits erfüllt, übernimmt Struktur und Ziele des EU Cloud Sovereignty Framework und baut auf BSI C5:2026 auf.

Ein Missverständnis ist dabei häufig und teuer: C3A ist keine Zertifizierung und keine Pflichtstufe. Das BSI bezeichnet den Katalog ausdrücklich als „richtungsweisenden Handlungsrahmen“, der „von sich aus jedoch nicht verbindlich“ ist. BSI-Präsidentin Claudia Plattner und Vizepräsident Thomas Caspers ordnen ihn in die Bedrohungskategorie „CyberDominance“ ein – es geht um die Frage, wie handlungsfähig eine Organisation bleibt, wenn ein Anbieter oder dessen Heimatstaat Druck ausübt.

Für die eigene Anbieterbewertung ist C3A trotzdem – oder gerade deshalb – das derzeit brauchbarste Werkzeug. Er liefert eine Struktur, mit der sich Souveränitätsversprechen in prüfbare Einzelfragen zerlegen lassen, ohne dass Sie ein eigenes Bewertungsraster erfinden müssen. Wer ein KI-Angebot einholt, kann C3A als Referenzrahmen benennen und den Anbieter bitten, seine Erfüllung Kriterium für Kriterium zu kommentieren. Die Qualität der Antwort ist bereits ein Ergebnis.

Die erste produktive Anwendung heißt KIPITZ

Anders als vielfach berichtet entsteht auf der neuen Cloud kein völlig neuer „Bundes-KI-Assistent“. Die erste produktive Anwendung ist KIPITZ – die bereits bestehende KI-Plattform des Bundes, entwickelt und betrieben vom ITZBund, die auf die neue KI-Cloud umziehen soll. Das berichtete netzpolitik.org am 27. Mai 2026 unter Berufung auf das BMDS.

Der Funktionsumfang von KIPITZ ist öffentlich dokumentiert und liest sich wie das Pflichtenheft einer mittelständischen KI-Plattform:

  • Apps für Chat mit einem Sprachmodell, Zusammenfassung und Befragung von Dokumenten, Übersetzung, Schwärzen von Dokumenten und Sprach-Transkription
  • Anbindung behördeneigener Wissensdatenbanken per Retrieval-Augmented Generation
  • API-Schnittstellen zur Integration in bestehende Fachanwendungen
  • Betrieb on-premise in bundeseigenen ITZBund-Rechenzentren, mit VS-NfD-Freigabe für eingestufte Daten
  • keine Herstellerbindung an bestimmte Modelle: „vor allem Open-Source-basierte Sprachmodelle“, proprietäre Modelle sind anbindbar
  • jede Behörde erhält ein eigenes, selbst konfigurierbares Portal; neue Apps werden nach dem EfA-Prinzip („Einer für Alle“) bereitgestellt

Die Plattform ist kein Papierprojekt: Sie belegte beim eGovernment-Wettbewerb 2024 den zweiten Platz in der Kategorie „Digitalisierungsschub durch KI und moderne Infrastruktur“. Die amtlich genannten Anwendungsfälle sind laut dpa verbesserte Dokumentenverarbeitung in Behörden, automatisierte Zusammenfassungen von Texten sowie die Beschleunigung von Planungs- und Genehmigungsverfahren. Flankierend hatte Wildberger zuvor bereits einen „Agentic AI Hub“ gestartet, über den KI-Agenten Beschäftigte etwa bei der Vollständigkeitsprüfung von Dokumenten unterstützen sollen.

Übersetzt in den Mittelstand: Nehmen Sie die KIPITZ-Funktionsliste und ersetzen Sie „Behörde“ durch „Fachabteilung“. Aus der Befragung von Verwaltungsvorgängen wird die Befragung von Angebots- und Vertragsordnern. Aus dem Schwärzen von Dokumenten wird die Anonymisierung von Bewerbungsunterlagen und Schadensmeldungen, bevor sie ein Modell überhaupt zu sehen bekommt. Aus VS-NfD wird die Trennung zwischen offenem Firmenwissen und Konstruktionsdaten. Aus dem behördeneigenen Portal wird ein Mandant je Standort. Kein einziger dieser Bausteine ist verwaltungsspezifisch – der Bund hat lediglich denselben Anforderungskatalog früher und formaler aufgeschrieben.

Governance: Wer den Deutschland-Stack eigentlich baut

Die KI-Cloud ist nur ein Element des Deutschland-Stacks, eines BMDS-Projekts aus dem Koalitionsvertrag 2025. Der IT-Planungsrat hat am 22. Juni 2026 Zuständigkeiten und Finanzierung geklärt: Bund und FITKO übernehmen Konzeption und Entwicklung von fünf Bausteinen – digitale Identität via eID und EUDI-Wallet, Datenaustausch über FIT-Connect, Datenabruf per NOOTS, Zahlungsabwicklung über ZBDS sowie das Postfach- und Benachrichtigungssystem ZaPuk. Die Länder verpflichten sich zur flächendeckenden Anbindung. Neu eingerichtet wurde ein Portfolio-Board mit dem Bund sowie Bayern, Brandenburg, Bremen, Nordrhein-Westfalen und Thüringen; Vorsitzender des IT-Planungsrats ist Dr. Markus Richter, Staatssekretär im BMDS.

Für Unternehmen ist das vor allem ein Zeitsignal. Eine föderale Architektur mit fünf Bausteinen, sechzehn Ländern und einem Portfolio-Board bewegt sich in Jahren. Eine Plattform für 200 Mitarbeitende bewegt sich in Wochen. Der Vorsprung liegt nicht beim Bund.

Der Deutschland-Stack im Mittelstandsmaßstab

Dieselben Architekturprinzipien lassen sich in einem einzelnen Rack abbilden – mit denselben drei Ebenen und derselben Klammer aus Zero Trust, Schlüsselhoheit und offenen Komponenten. Nur die Größenordnung und die Laufzeit sind andere:

Ebene Bund (KI-Cloud) Mittelstand (eigenes Rack)
Infrastruktur Rechenzentren zweier Konsortien, BSI-zertifizierte Basis 1–2 GPU-Server im eigenen Serverraum oder im Colocation-Rack
Plattform PaaS-Layer, mandantenfähig für Bund, Länder, Kommunen Container-Orchestrierung, Modell-Serving, Vektorindex, Rechteschicht
Anwendung KIPITZ mit Chat, Dokumentenbefragung, Übersetzung, Schwärzung Chat auf Firmenwissen, Angebots- und Vertragsanalyse, Support-Assistent
Schlüsselhoheit BYOK gegenüber dem Betreiber (berichtet) eigenes HSM/Vault – kein externer Betreiber vorhanden
Zeit bis produktiv Vergabeverfahren, Rüge, Migration bestehender Plattform – Jahre Wochen

Technisch ist die Plattformebene heute keine Forschungsaufgabe mehr. Docker-Container für Modell-Serving, Vektordatenbank und Anwendungsschicht, darüber Kubernetes oder eine schlanke Alternative für Ausfallsicherheit und Rollouts – das ist Standardhandwerk. Der Unterschied zwischen einer souveränen und einer nur „deutsch gehosteten“ Plattform entsteht nicht in der Technik, sondern in den Entscheidungen darüber, welche Formate, welche Schnittstellen und welche Modelle Sie sich vertraglich vorbehalten.

Die Vorgaben als Vorlage für die eigene Ausschreibung

Wer im nächsten Quartal ein KI-Angebot einholt, kann die folgenden fünf Punkte wörtlich in die Anfrage übernehmen:

  1. Zero Trust auf Anwendungsebene. Jeder Modell-, Index- und Dokumentzugriff wird einzeln autorisiert und protokolliert. Verlangen Sie ein Beispiel-Auditlog, keine Architekturfolie.
  2. Schlüsselhoheit beim Kunden. Wer erzeugt, verwahrt und rotiert die Schlüssel? Welche Rolle beim Anbieter könnte technisch auf Klartext zugreifen? Antworten gehören in den Vertrag, nicht ins Vorgespräch.
  3. Offene Schnittstellen und Exportpfad. Dokumentierte APIs, dokumentierte Datenformate, ein getestetes Exportverfahren für Indizes und Konfiguration. Der Exit wird beim Einstieg verhandelt oder gar nicht.
  4. Keine Modellbindung. Wie KIPITZ sollte Ihre Plattform bevorzugt offene Sprachmodelle nutzen und den Austausch eines Modells ohne Umbau der Anwendungsschicht erlauben. Modellzyklen sind kürzer als Abschreibungszeiträume.
  5. Prüfbare Sicherheits- und Souveränitätsbasis. ISO 27001 und C5 als Einstieg, C3A als Referenzrahmen für die Souveränitätsfragen – im Wissen, dass C3A ein Orientierungsrahmen ist und keine Zertifizierung.

Dazu kommt die Compliance-Klammer, die für Unternehmen ohnehin gilt: Was der Bund als Nachvollziehbarkeit und Protokollierung beschafft, verlangt der EU AI Act von Betreibern in vergleichbarer Form – Transparenz über eingesetzte Systeme, dokumentierte Verantwortlichkeiten und nachvollziehbare Ergebnisse. Wer die fünf Punkte oben erfüllt, hat den größten Teil dieser Dokumentation als Nebenprodukt.

Die eigentliche Botschaft der 250-Millionen-Vergabe ist deshalb nicht, dass der Bund viel Geld ausgibt. Sie lautet: Der Anforderungskatalog für eine souveräne KI-Plattform liegt jetzt öffentlich vor, in einer Form, die man einem Anbieter vorlegen kann. Für ein mittelständisches Unternehmen ist das ein geschenktes Lastenheft – und die Umsetzung dauert bei Ihnen nicht Jahre, sondern Wochen. Wie ein solcher Aufbau konkret aussieht, zeigen wir im KI-Full-Stack-Providing; die Zugriffsseite behandeln wir unter Zero-Trust für KI.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

  1. it-daily.net: Bund vergibt KI-Großauftrag an Telekom und SAP dpa-Meldung vom 21.05.2026 – Volumen „knapp 250 Millionen Euro“, Aufteilung 70/30, Anwendungsfälle, Zitate Wildberger, Höttges, Klein.
  2. netzpolitik.org: Für 250 Millionen Euro schafft der Bund neue Abhängigkeiten von IT-Konzernen Esther Menhard, 27.05.2026 – KIPITZ-Migration, Lizenzausgaben des Bundes, Gegenpositionen von Sonja Lemke und der FSFE.
  3. Cloudmagazin: Deutschland-Stack – Bundes-KI-Cloud souverän 21.05.2026 – einzige Quelle für Zero Trust, BYOK und Open-Source-Bindung als Vergabebedingungen; im Text entsprechend als Bericht gekennzeichnet.
  4. Cloudmagazin: Deutschland-Stack wird operativ 19.06.2026 – Rollenverteilung im SVA-Konsortium (SVA, Schwarz Digits/StackIT, Codesphere), PaaS-Einordnung.
  5. BSI-Pressemitteilung zum Kriterienkatalog C3A 27.04.2026 – Veröffentlichung, Einordnung als nicht verbindlicher Handlungsrahmen, Aussagen von Claudia Plattner und Thomas Caspers.
  6. BSI: C3A – Criteria enabling Cloud Computing Autonomy Themenseite – Verhältnis zu C5:2026 und zum EU Cloud Sovereignty Framework, deutsche Fassung angekündigt.
  7. ITZBund: KI-Plattform KIPITZ Funktionsumfang, RAG-Anbindung, API, On-Premise-Betrieb, VS-NfD-Freigabe, EfA-Prinzip, eGovernment-Wettbewerb 2024.
  8. it-daily.net: Deutschland-Stack – Klarheit über Zuständigkeiten und Geld 22.06.2026 – Beschlüsse des IT-Planungsrats, fünf Bausteine, Portfolio-Board, Vorsitz Dr. Markus Richter.

Häufig gestellte Fragen zur Bundes-KI-Cloud

Können private Unternehmen die Bundes-KI-Cloud nutzen?

Nein, sie ist für die Verwaltung gedacht und soll über den Deutschland-Stack Ländern und Kommunen geöffnet werden. Für Unternehmen ist sie eine Architektur-Blaupause, kein Angebot.

Was bedeutet BYOK konkret?

Bring Your Own Key: Die Schlüsselhoheit liegt beim Kunden, der Betreiber kann die Daten nicht im Klartext sehen. Bei eigener Hardware ist das kein Feature, sondern der Ausgangszustand.

Warum ist die Open-Source-Bindung wichtig?

Sie verhindert, dass die Plattform an einen Anbieter gebunden bleibt. Offene Schnittstellen und Komponenten sind die Voraussetzung für einen späteren Wechsel ohne Neubau.

Was können wir als Mittelständler konkret übernehmen?

Die drei Vorgaben als Mindestanforderung an jedes KI-Angebot: Zero-Trust-Zugriff, eigene Schlüsselhoheit und offene Schnittstellen ohne proprietäre Formate.

Ihren eigenen Stack – im Rack statt im Vergabeverfahren

Wir bauen die drei Ebenen der Bundes-Blaupause im Mittelstandsmaßstab: eigene Hardware, eigene Schlüssel, offene Komponenten. Erstgespräch kostenlos, Pilot in wenigen Wochen.