Warum der Staat KI nicht per Knopfdruck souverän bekommt
Souveränität lässt sich nicht einschalten. Sie ist kein Schalter und kein Häkchen, das man zur bestehenden Lösung dazubucht. Sie entscheidet sich eine Ebene tiefer, in der Architektur, und das macht sie unbequem.
Eine Entwicklerin in einer Landesbehörde kennt die KI-Werkzeuge, die ihre Kollegen in der Privatwirtschaft seit zwei Jahren schneller machen. Sie würde sie gern nutzen. Sie darf nicht. Der Code, an dem sie arbeitet, darf das eigene Rechenzentrum nicht verlassen. Die Server müssen in Deutschland stehen. Jeder Schritt, den eine KI tut, muss hinterher nachvollziehbar sein. Und die Lizenzkosten solcher Cloud-Dienste werden pro Kopf schnell vierstellig im Monat, in einem öffentlichen Projekt schwer zu rechtfertigen. Also bleibt das Werkzeug aus.
Aus dieser Lage wünscht man sich einen Ausweg, der so einfach ist wie ein Knopf. Eine souveräne Variante des Cloud-Dienstes, die man anklickt. „Wir haben die DE-Version aktiviert.“ Der Knopf trägt nicht. Hinter ihm läuft dieselbe Cloud-Architektur weiter, dieselben Abhängigkeiten, dieselben Datenwege. An einem fremden Haus tauscht man das Fundament nicht aus, indem man die Klingel wechselt. Souveränität ist kein Feature. Sie ist eine Architektur-Entscheidung.
Was unter dem Knopf liegt
Wer sie ernst nimmt, baut sie von unten. Drei Dinge muss eine solche Architektur können. Sie bereitet den Kontext für die KI beim Entwickler auf, im eigenen Haus. Sie lässt den Agenten in kontrollierbaren Teilschritten arbeiten, jeder davon einsehbar. Und sie schickt jedes Ergebnis durch eine deterministische Prüfung, bevor es zählt. So liefern auch kleinere, lokal betriebene Modelle verlässliche Resultate, ohne dass Code oder Daten je das Haus verlassen.
Das ist die Pointe der Architektur-Frage: Sie verlegt die Kontrolle dorthin, wo die Verantwortung liegt. Datensouveränität ohne Umweg über einen Anbieter, dessen Heimatrecht im Zweifel über dem eigenen steht. Audit-Trails, die schon beim Arbeiten mitlaufen und auf die Nachweispflichten des AI Act vorbereiten. Eine Modellwahl nach Schutzbedarf, vom lokalen Open-Source-Modell bis zur Cloud, je nachdem, was die Aufgabe verträgt. Das klingt unspektakulär. Es ist der Unterschied zwischen einer Aussage über Souveränität und einer Infrastruktur, die sie hält.
Was die Entscheidung kostet
Architektur-Entscheidungen haben einen Preis, den ein Knopf nicht hat. Sie sind in der Anschaffung teurer als ein Monatsabo. Sie sind langsamer, weil man Fundament legt, statt eine Oberfläche zu mieten. Und sie sind politisch unbequem, weil sie sich nicht als schnelle Erfolgsmeldung verkaufen lassen. Rechnet man Audit-Aufwand, Compliance-Risiko und den schlichten Erhalt der eigenen Handlungsfähigkeit dazu, kehrt sich die Rechnung über die Jahre um. Nur zeigt sich diese Umkehr spät, und die Haushaltslogik belohnt das Frühe.
Hier trifft sich der technische Befund mit dem politischen. Wenn Karsten Wildberger von einer eigenen souveränen Cloud-Infrastruktur für den Staat spricht, ist das kein Beschaffungsvorgang fürs nächste Quartal. Es ist die Ansage, das Fundament selbst zu bestimmen. Eingelöst wird sie erst durch hunderte solcher Architektur- Entscheidungen in Rechenzentren, Vergabestellen und Fachverfahren.
Es geht nicht um ein Produkt
Und es geht um mehr als eine einzelne Lösung. Das ZenDiS prüft mit seinem Souveränitätscheck nach verwandten Kriterien, welche Software dem Anspruch standhält. Berlin hat sich mit seiner Open-Source- Strategie auf dieselbe Linie festgelegt. Im Umfeld des Deutschland- Stack wird an den Schichten unter der Oberfläche gearbeitet. Was diese Vorhaben verbindet, ist weniger eine Technologie als eine Haltung: Sie behandeln Souveränität als Frage des Substrats, also dessen, was unter der Anwendung liegt und wem es gehört.
Das ist die unbequeme Seite des Souveränitäts-Diskurses. Die teure, langsame, sperrige Antwort ist die einzige, die das Versprechen einlöst, das Deutschland sich gerade selbst gibt. Ein Knopf wäre billiger. Er würde nur nichts tragen.
