Souveränität von KI-Agenten: Das eigentliche Problem ist nicht das Modell, sondern die Abhängigkeit

Fable 5: der Präzedenzfall des KI-„Kill Switch“

Der Fall Fable 5 hat für Aufsehen gesorgt, weil er eine neuartige Abhängigkeit veranschaulicht: die von fortgeschrittenen KI-Modellen, die als Entwicklungsassistenten und als Werkzeuge zur Erweiterung menschlicher Arbeit eingesetzt werden.

Wenn ein Team sich auf einen KI-Agenten stützt, um zu programmieren, ein Projekt zu analysieren, Refactorings vorzuschlagen, Tests zu generieren oder beim Debugging zu unterstützen, hängt es nicht nur von der Qualität der Antworten ab. Es hängt auch von der Verfügbarkeit des Modells ab, von seiner Geschäftspolitik, seiner Rechtsordnung, seinen Sicherheitsregeln, seinen Schutzmechanismen, seinen Nutzungsbedingungen und mitunter sogar von politischen Entscheidungen, die im Ausland getroffen werden.

Ein Modell kann nicht mehr nutzbar sein, und zwar nicht deshalb, weil es technisch überholt ist, sondern weil eine Regierung, ein Anbieter oder eine Regulierungsbehörde entscheidet, dass es unter bestimmten Bedingungen nicht mehr zugänglich sein darf.

Für ein Entwicklungsteam ist das kein Detail. Wenn ein KI-Agent in den Arbeitsalltag integriert ist - Code lesen, Funktionen generieren, Unterstützung beim Entwurf, Interaktion mit einer IDE - dann führt sein Wegfall nicht zwangsläufig zu einer sichtbaren Störung, wohl aber zu einem abrupten Produktivitätsverlust und zu einem Bruch in den Arbeitsgewohnheiten.

Genau hier wird KI-Souveränität zu einem konkreten Thema, und zwar nicht nur für automatisierte Workflows, sondern auch für Werkzeuge, die Menschen unmittelbar unterstützen.

Mistral im öffentlichen Sektor: Souveränität oder verlagerte Abhängigkeit?

Frankreich fördert inzwischen souveräne Lösungen rund um Mistral AI für Beschäftigte im öffentlichen Dienst. Auf dem Papier ist die Logik nachvollziehbar: Öffentliche Daten müssen in einem kontrollierten Rahmen verarbeitet werden, auf konformen Infrastrukturen, mit einem europäischen Akteur, der den Anforderungen an Sicherheit, Vertraulichkeit und Governance gerecht wird.

Das ist eine pragmatische Antwort auf eine übermäßige Abhängigkeit von den großen amerikanischen Anbietern. Für den Staat ist es kaum hinnehmbar, dass Verwaltungsdokumente, interne Zusammenfassungen oder sensible Daten über nicht kontrollierte Infrastrukturen laufen.

Echte Souveränität bedeutet nicht nur, „ein nationales Modell zu nutzen“. Sie bedeutet, das Modell wechseln zu können, die Inferenz zu verlagern, die eigenen Daten zu behalten, die Prompts zu beherrschen, die Workflows zu versionieren, die Qualität der Antworten zu messen und den Dienst intelligent zu degradieren, wenn das Hauptmodell nicht mehr verfügbar ist.

Ein souveräner KI-Agent sollte deshalb nicht um ein einziges Modell herum konzipiert werden. Er sollte um eine Multi-Modell-Architektur herum konzipiert werden.

Nicht jeder Workflow braucht ein Frontier-Modell

Ein häufiger Fehler besteht in der Annahme, dass jeder KI-Einsatz das leistungsfähigste verfügbare Modell erfordert. Das ist falsch. In vielen Fällen ist das leistungsfähigste Modell vor allem das teuerste, das langsamste, das am stärksten von einem externen Anbieter abhängige und das am schwersten zu steuernde.

Für die Extraktion strukturierter Daten kann ein kleines, gut abgestecktes Modell genügen. Wenn die Eingabe sauber ist, das Ausgabeschema strikt, die Beispiele gut sind und dahinter eine automatische Validierung existiert, ist der Einsatz eines riesigen Modells nicht zwingend erforderlich.

Bei der asynchronen Klassifikation ist der Bedarf noch einmal anders gelagert. Man sucht nicht immer eine perfekte Antwort in Echtzeit. Man sucht geringe Kosten, ausreichende Robustheit und die Fähigkeit, Volumen zu verarbeiten. In diesem Fall kann ein kleines oder mittelgroßes lokales Modell interessanter sein als ein sehr leistungsfähiges Cloud-Modell. Es ist sogar möglich, vergleichsweise langsame Modelle einzusetzen, die nur wenige Tokens pro Sekunde erzeugen, dabei aber eine gute Ergebnisqualität liefern. Bei asynchronen Aufgaben ist diese Latenz oft akzeptabel. So lassen sich bestehende Infrastrukturen weiternutzen, etwa ältere Server mit begrenztem Arbeitsspeicher, und diese Hardware-Einschränkungen in einen wirtschaftlichen Vorteil verwandeln.

Bei der Codegenerierung, bei komplexer Analyse, bei Softwarearchitektur oder mehrstufigem Schlussfolgern steigt der Bedarf schnell an. Das Modell muss den Kontext verstehen, über mehrere Dateien hinweg schlussfolgern, Halluzinationen vermeiden, kohärente Korrekturen vorschlagen und mitunter komplexe technische Abhängigkeiten handhaben. Hier behalten die leistungsfähigeren Modelle einen echten Vorteil. Anders gesagt: Souveränität bedeutet nicht „alles lokal machen“, sondern zu wissen, was lokal laufen muss, was in der Cloud laufen kann und wofür eine Rückfallstrategie nötig ist.

Was sich wirklich lokal umsetzen lässt

Heute lassen sich nützliche Modelle auf vergleichsweise bescheidenen Maschinen betreiben. Nicht, um die besten Cloud-Modelle systematisch zu ersetzen, sondern um einen erheblichen Teil der Workflows abzudecken.

Auf einer Maschine mit 8 bis 16 GB RAM lassen sich bereits kleine quantisierte Modelle betreiben, für einfache Klassifikation, Feldextraktion, das Routing von Anfragen, Umformulierungen oder grundlegende Prüfungen.

Auf einer Maschine mit 32 GB RAM oder mit einer Grafikkarte mit ausreichend VRAM lassen sich komfortablere Modelle mit 7B, 8B, 14B oder je nach Quantisierung auch mehr einsetzen. Das öffnet die Tür für interne Agenten, die Dokumente verarbeiten, auf Basis einer Wissensdatenbank antworten, Formulare vorausfüllen oder Fachteams unterstützen können.

Auf einer leistungsfähigeren Workstation mit 24 GB VRAM oder mehr kann man beginnen, größere Modelle für Code, fortgeschrittene Analysen, längeres Schlussfolgern oder ambitioniertere mehrstufige Agenten ins Auge zu fassen.

Man sollte sich jedoch nichts vormachen: Ein lokales Modell auf einer kleinen Maschine liefert nicht dieselbe Qualität wie ein Frontier-Modell in der Cloud. Es wird begrenzter sein, teilweise langsamer, schwächer beim komplexen Schlussfolgern, weniger zuverlässig bei mehrdeutigen Aufgaben. Sein Nutzen liegt woanders: Es bleibt verfügbar, kontrollierbar, im großen Maßstab wirtschaftlich und unabhängig von einer externen API.

Eine realistische Strategie: Aufgaben nach Kritikalitätsstufe routen

Der richtige Ansatz besteht darin, KI-Workflows in mehrere Stufen einzuteilen.

Erste Stufe: die einfachen, wiederkehrenden und prüfbaren Aufgaben. Extraktion von Datumsangaben, Beträgen, Referenzen, Kategorien, Kundenabsicht, Sprache, Dokumenttyp. Diese Aufgaben können häufig kleinen lokalen Modellen anvertraut werden, vor allem wenn ihnen Validierungsregeln nachgelagert sind.

Zweite Stufe: die asynchronen Aufgaben. Klassifikation von E-Mails, Voranalyse von Tickets, Scoring von Anfragen, Vorbereitung von Entwürfen, unkritische interne Zusammenfassungen. Hier ist Latenz nicht immer ein Problem: Man kann akzeptieren, dass eine Verarbeitung einige Sekunden länger dauert, wenn Kosten und Souveränität dafür besser ausfallen.

Dritte Stufe: die sensiblen Aufgaben. Vertrauliche Daten, Kundeninformationen, öffentliche Dokumente, regulierte Daten, Betriebsgeheimnisse. Diese Aufgaben müssen in einer kontrollierten Umgebung verarbeitet werden: lokal, in einer souveränen Cloud oder auf einer zertifizierten Infrastruktur.

Vierte Stufe: die komplexen Aufgaben. Entwicklung, Architektur, juristisches Schlussfolgern, Vertragsanalyse, fachliche Abwägung, kritische Entscheidungen. Hier muss das Modell leistungsfähiger sein, es darf aber nicht sich selbst überlassen bleiben. Klassische RAG-Ansätze sind heute in vielen Fällen überholt: Der Trend geht zu deutlich leistungsfähigeren MCP-Architekturen (Model Context Protocol), die Quellen, Werkzeuge und Umgebungen dynamisch anbinden können.

Diese Logik vermeidet zwei Fallen: ein zu leistungsfähiges Modell für einfache Aufgaben einzusetzen, oder ein kleines lokales Modell für Aufgaben zu verwenden, die seine Fähigkeiten klar übersteigen.

Das Lokale als Kontinuitätsplan

Lokales Hosting sollte nicht allein als ideologische Alternative zur Cloud gesehen werden. Es sollte als Kontinuitätsplan verstanden werden.

Selbst wenn ein Unternehmen weiterhin sehr leistungsfähige Cloud-Modelle nutzt, sollte es sich fragen: Was passiert, wenn die API nicht mehr verfügbar ist? Wenn sich die Preise ändern? Wenn bestimmte Nutzungen untersagt werden? Wenn der Anbieter eine Datenspeicherung vorschreibt, die mit unserer internen Richtlinie unvereinbar ist?

Ein lokales Modell kann, auch wenn es weniger leistungsfähig ist, einen eingeschränkten Betrieb aufrechterhalten. Wenn der Hauptagent zum Beispiel keine vollständige Antwort mehr erzeugen kann, kann ein lokales Modell weiterhin Anfragen klassifizieren, die wichtigen Felder extrahieren, einen Entwurf vorbereiten oder den Vorgang an einen Menschen weiterleiten.

Das ist nicht perfekt, aber besser als ein vollständiger Stillstand.

Die eigentliche Herausforderung: austauschbare KI-Agenten entwerfen

Ein KI-Agent sollte niemals als unmittelbare Abhängigkeit von einem einzigen Modell gebaut werden. Der fachliche Workflow muss von der Inferenz-Engine getrennt werden. Das Modell muss ein austauschbarer Baustein sein, nicht der unausbaubare Kern des Systems.

Das setzt mehrere bewährte Praktiken voraus:

• Ein- und Ausgaben standardisieren;
• strikte JSON-Schemas verwenden;
• Prompts und Prompt-Versionen aufbewahren;
• die Qualität pro Aufgabe messen;
• je nach Anwendungsfall mehrere Modelle vorsehen;
• eine lokale oder souveräne Fallback-Fähigkeit behalten;
• wichtige Entscheidungen nachvollziehbar protokollieren;
• automatisch validieren, was sich automatisch validieren lässt;
• den Menschen bei sensiblen Entscheidungen in der Schleife behalten.

In dieser Logik kann der Einsatz eines LLM-Proxys wie LiteLLM eine Schlüsselrolle spielen. Ein solches Werkzeug vereinheitlicht die Aufrufe an verschiedene Anbieter (OpenAI, Mistral, Anthropic, lokale Modelle usw.) hinter einer einzigen Schnittstelle. So macht man sich unabhängig von unterschiedlichen API-Formaten, von Parameteränderungen oder von anbieterspezifischen Weiterentwicklungen. Konkret ermöglicht das:

• das Modell zu wechseln, ohne den Anwendungscode zu ändern;
• Anfragen dynamisch nach Kosten, Latenz oder erwarteter Qualität zu routen;
• Fallback-Strategien einfach umzusetzen;
• die Verwaltung von Schlüsseln, Kontingenten und Logs zu zentralisieren;
• mehrere Modelle für denselben Anwendungsfall zu testen, ohne aufwendiges Refactoring.

Diese Art der Abstraktion ist entscheidend, um Agenten wirklich austauschbar zu machen und zu verhindern, dass anfängliche technische Entscheidungen zu strukturellen Zwängen werden. KI-Souveränität lässt sich also nicht darauf reduzieren, Mistral, OpenAI, Anthropic, Google, Meta oder ein Open-Source-Modell zu wählen: Sie besteht darin, das eigene Unternehmen nicht zum Gefangenen einer einzigen Entscheidung zu machen.

Fazit: Souveränität heißt Architektur vor Flagge

Der Fall Fable 5 erinnert daran, dass ein KI-Modell zu einem strategischen Bruchpunkt werden kann. Der Einsatz von Mistral im öffentlichen Sektor zeigt, dass Frankreich die Kontrolle über seine kritischen Anwendungen zurückgewinnen will. Die lokalen Modelle zeigen, dass es einen dritten Weg gibt: zu akzeptieren, dass nicht alle Workflows dasselbe Leistungsniveau benötigen.

Die richtige Strategie besteht weder darin, alles in die Cloud zu verlagern, noch darin, alles lokal zu betreiben. Die richtige Strategie besteht darin, KI-Agenten zu bauen, die das passende Modell für die passende Aufgabe wählen können. Für die Datenextraktion kann ein kleines lokales Modell genügen. Für die asynchrone Klassifikation ist ein leichtes Modell oft ein ausgezeichneter Kompromiss. Für Entwicklung, komplexe Analysen oder Agenten mit langem Zeithorizont bleiben leistungsfähigere Modelle notwendig. In jedem Fall aber muss die Architektur den Wechsel vorsehen.

KI-Souveränität gewinnt man nicht allein mit einem nationalen Champion. Man gewinnt sie mit Systemen, die einen Ausfall, eine Preisänderung, eine regulatorische Einschränkung, einen Anbieterwechsel und die nächste geopolitische Krise überstehen.