Digitale Souveränität: KI-Fallback ohne US-Abhängigkeit

Ein Exportverfahren erreicht erstmals ein Softwareprodukt

Der Vorgang bricht mit einer Annahme, die vielen KI-Projekten zugrunde liegt. Ein SaaS-Modell galt als Dienst, dessen Verfügbarkeit von Technik und Vertrag abhängt. Für die Architektur eines KI-Agenten ist die Ursache eines Ausfalls zweitrangig. Ein Buchhaltungsagent, der Eingangsrechnungen liest und kontiert, arbeitet nicht mehr, sobald das hinterlegte Modell keine Antworten liefert. Die Frage lautet damit nicht mehr, ob ein Anbieter zuverlässig arbeitet, sondern welche Ebene den Ausfall abfängt.

Martin Kuppinger, Gründer und Principal Analyst bei KuppingerCole, verortet den Kern der Aufgabe in der Produktauswahl. Nach seiner Einschätzung stellen CIOs eine Frage zu selten, nämlich die nach dem Ausstieg. „Ich glaube, es ist in vielen Fällen sehr viel wichtiger, den Weg zu wissen zum Exit, als ihn zwingend jetzt durchzuführen“, sagt er. Eine Fallback-Architektur ist die technische Form dieser Antwort.

Unternehmen sollten sich auf solche Fälle vorbereiten – vor allem, da KI und KI-Agenten zunehmend zum Einsatz kommen. Zur Planung gehören europäische Modellanbieter wie

• das aus dem Programm Digitales Europa geförderte Konsortium OpenEuroLLM,
• Inferenz-Engines für den Eigenbetrieb,
• Gateways mit Fallback-Logik,
• sowie lokal betriebene Open-Source-Modelle.

Europäische Anbieter decken den Regelbetrieb ab

Mistral AI liefert die produktionsreifste europäische Option. Mistral Large 3 steht unter Apache 2.0 und lässt sich als API-Dienst nutzen oder komplett selbst hosten. Die Gewichte sind offen, das Modell hat einen Kontext von 256.000 Tokens und passt damit auf Dokumentenverarbeitung mit langen Anhängen.

Aleph Alpha verfolgt einen anderen Zuschnitt. PhariaAI kommt über STACKIT als Dienst aus deutschen Rechenzentren und richtet sich an Organisationen, die Datenschutz und AI-Act-Konformität vertraglich abbilden müssen. Teuken-7B aus dem Projekt OpenGPT-X ist ein Forschungsmodell und für Produktivlasten zu klein dimensioniert. OpenEuroLLM baut an einer Modellfamilie für alle Amtssprachen der EU, arbeitet seit Februar 2025 in einem Konsortium aus 20 Partnern und liefert bisher keine produktiven Modelle.

Daraus ergibt sich eine Staffelung. Mistral eignet sich als primärer europäischer Dienst, PhariaAI als souveräne Variante mit deutschem Vertragsrahmen, die Forschungsprojekte als Option für die kommenden Jahre. Organisationen, die heute eine europäische Alternative brauchen, arbeiten mit den ersten beiden.

Selbst gehostete Open-Weight-Modelle bilden die letzte Ebene

Ein selbst betriebenes Modell hat eine Eigenschaft, die kein Cloud-Dienst bietet. Die Gewichte liegen auf der eigenen Hardware, ein Rückruf durch den Herausgeber spielt für den Betrieb zunächst keine Rolle. Genau darin liegt der Wert der untersten Stufe einer Fallback-Kette.

Der Abstand zur Spitze ist kleiner geworden. Offene Modelle erreichen bei Routineaufgaben ein Niveau, das für die Mehrzahl mittelständischer Prozesse ausreicht, und kosten pro Token einen Bruchteil der Frontier-Modelle. Offene Gewichte bedeuten allerdings keine Offenlegung der Trainingsdaten. Der Begriff Open Weight beschreibt die Verfügbarkeit der Parameterdatei, nicht die Nachvollziehbarkeit des Trainings.

Quantisierung macht den lokalen Betrieb bezahlbar. Eine Q4-Quantisierung reduziert die Genauigkeit jedes Parameters auf vier Bit und halbiert den Speicherbedarf gegenüber Q8. Ein Modell mit 56 GByte Parametergröße schrumpft in der Q4_K_M-Variante auf rund 17 GByte, der Qualitätsverlust bleibt für strukturierte Extraktionsaufgaben gering. Q2-Varianten fallen dagegen spürbar ab und taugen für Produktivlasten nicht.

Die Engine folgt dem Lastprofil

Für den Einstieg genügt Ollama, das für Linux, macOs und Windows verfügbar ist. Das Tool kapselt Modellverwaltung, API-Server und Inferenz hinter einer Docker-ähnlichen Bedienung, der Befehl ollama pull llama3:8b lädt ein Modell, der API-Server nimmt auf Port 11434 Anfragen im OpenAI-kompatiblen Format entgegen. Bestehender Code gegen die OpenAI-API arbeitet nach dem Austausch der Base-URL weiter. Der Nachteil zeigt sich unter Last. Ollama bearbeitet standardmäßig eine Anfrage parallel und bricht ab vier gleichzeitigen Nutzern in der Antwortzeit ein.

vLLM zielt auf den Serverbetrieb. Bei 64 gleichzeitigen Nutzern liefert die Engine ein Vielfaches des Durchsatzes von llama.cpp, das seinerseits auf CPU-Inferenz und GGUF-Dateien optimiert ist. Für eine Fallback-Ebene mit wenigen parallelen Anfragen reicht Ollama, für den produktiven Dauerbetrieb eines Agenten-Teams ist vLLM besser geeignet.

Ein Gateway verkettet Cloud und lokale Inferenz

Die eigentliche Ausfallsicherheit liefert die Zwischenschicht. LiteLLM stellt eine OpenAI-kompatible API bereit und verteilt Anfragen nach hinterlegten Regeln an mehrere Backends. Die Konfiguration beschreibt eine Kette in YAML, in der Parameter wie allowed_fails und cooldown_time festlegen, ab wann ein Backend als ausgefallen gilt und wie lange es aus der Rotation bleibt.

Der Aufbau folgt einer Kaskade. Der europäische Cloud-Dienst nimmt den Regelbetrieb, ein zweiter Anbieter fängt Kapazitätsprobleme ab, das lokale Open-Weight-Modell bildet die Endstufe. Health-Checks im Abstand von 30 Sekunden erkennen einen Ausfall, der Overhead je Anfrage liegt im niedrigen zweistelligen Millisekundenbereich und fällt gegenüber der Inferenzzeit nicht ins Gewicht.

Wichtig ist die Klassifikation der Fehler. Ein Timeout rechtfertigt einen Retry gegen dasselbe Backend, ein HTTP-403-Status (Zugriff verweigert) nach einer Sperrung nicht. Ein Circuit Breaker verhindert, dass der Agent gegen ein dauerhaft blockiertes Modell anläuft, und schaltet direkt auf die nächste Stufe. Genau dieses Muster hätte einen Agenten im Juni 2026 innerhalb einer Minute weiterarbeiten lassen.

Die Hardware bleibt überschaubar

Für eine Rückfallebene reicht ein kleiner Server. Ein System mit 16 CPU-Kernen und 32 GByte RAM verarbeitet Llama 3 8B in reiner CPU-Inferenz mit 15 bis 20 Tokens pro Sekunde, nach Angaben des Beratungshauses Pexon genug für bis zu 200 bis 400 Rechnungen pro Stunde. Eine NVIDIA RTX 4060 mit 8 GByte VRAM hebt den Durchsatz deutlich an und kostet einen dreistelligen Betrag.

Ab 20 bis 30 Tokens pro Sekunde wirkt eine Antwort im Dialog flüssig. Die Speicherbandbreite bestimmt diesen Wert stärker als die reine Rechenleistung, weshalb Systeme mit Unified Memory bei großen Modellen mithalten. Ein NVIDIA DGX Spark bietet nach Herstellerangabe 128 GByte Unified Memory zum Listenpreis von 4.679 US-Dollar (Stand Juni 2026) und führt Modelle bis rund 200 Milliarden Parameter in 4-Bit-Quantisierung aus. Der AMD Ryzen AI Max+ 395 deckt dieselbe Klasse ab.

Europäisches Hosting ersetzt den eigenen Server

Ein Fallback muss nicht im eigenen Rack stehen. STACKIT baut das Rechenzentrum Lübbenau nach eigenen Angaben bis Ende 2027 auf mehr als 100.000 GPUs aus und liefert Inferenz aus Deutschland. Der IONOS AI Model Hub stellt offene Modelle als API bereit, die Open Telekom Cloud deckt regulierte Lasten ab.

Interessant für die Fallback-Frage ist der Ansatz von neuland.ai gemeinsam mit STACKIT. Dasselbe Modell läuft wahlweise On-Premises, in der deutschen Cloud oder beim Hyperscaler, angesprochen über eine einzige API. Der Wechsel zwischen den Betriebsformen kostet damit keine Anpassung am Agenten.

Kuppinger warnt an dieser Stelle vor einer Verwechslung. „Souveränität ist ja kein Selbstzweck“, sagt der Analyst. Am Anfang stehe die Frage nach Sicherheit und Resilienz, die nötige Souveränität ergebe sich daraus. Sein zweiter Hinweis zielt auf den Lock-in. Jeder Dienst jenseits standardisierter Funktionen wie Kubernetes vertieft die Bindung an einen Anbieter, bis auch ein Wechsel zwischen Hyperscalern ausscheidet.

Die Buchhaltung zeigt den Zuschnitt im Regelbetrieb

Ein n8n-Workflow bindet die lokale Inferenz in einen Geschäftsprozess ein. Der Ablauf beginnt mit einem Trigger auf den Rechnungseingang, führt über eine OCR-Stufe zur Textextraktion, übergibt den Text an das lokale Modell, lässt Rechnungsnummer, Lieferant, Nettobetrag, Steuersatz und Leistungsbeschreibung als JSON ausgeben und schlägt eine SKR03- oder SKR04-Kontierung vor. Der Export geht per API an DATEV oder als CSV an den Steuerberater. In der n8n-Oberfläche ersetzt der Menüpunkt Ollama Chat Model den bisherigen OpenAI-Knoten, als Base-URL trägt der Administrator den Container-Namen statt localhost ein.

Die Trefferquote hängt von Modell und Prompt ab. Llama 3 8B erreicht bei Standardrechnungen aus den Bereichen Büromaterial, IT-Dienstleistungen und anderen Buchungen eine ausreichende Leistung. Durch eine RAG-Erweiterung mit den eigenen Kontierungsregeln in einer Vektordatenbank lässt sich die Quote natürlich erhöhen. Praktisch bedeutet das, dass für Beträge oberhalb einer definierten Schwelle ein Freigabeschritt in den Workflow integriert werden muss.

Souveränität und Sicherheit bleiben getrennte Größen

Offene Gewichte verschieben die Kontrolle über die Daten, nicht die Angriffsfläche. Ein lokal betriebenes Modell verarbeitet Prompt Injection genauso wie ein gehostetes und bringt zusätzlich die Verantwortung für Patch-Stand, Netzsegmentierung und Zugriffssteuerung ins eigene Haus. Der Betrieb kostet Personalzeit, die in der Cloud-Rechnung nicht auftaucht.

Auch die Qualität am oberen Ende bleibt eine offene Rechnung. Für Reasoning über komplexe Verträge oder mehrstufige Recherchen liegen die Frontier-Modelle weiter vorn. Ein sinnvoller Zuschnitt schickt Masse und sensible Daten an die lokale Ebene und lässt die harten Fälle in die Cloud eskalieren, gesteuert über dasselbe Gateway, das auch den Fallback bedient.