LLM-Fallback prüfen: Welche Ausweichroute ist tatsächlich erlaubt?
Ein automatischer LLM-Fallback sollte eine Anfrage nur an einen Endpunkt senden, der für diesen Workflow und seine Daten freigegeben ist. Erreichbarkeit allein reicht nicht. Wenn kein zulässiger und geeigneter Endpunkt verfügbar ist, braucht die Anwendung einen festgelegten Warte-, Übergabe- oder Abbruchweg.
Die entscheidende Prüfung findet vor dem Versand statt. Ein Protokolleintrag nach der Weiterleitung kann eine unerlaubte Übertragung dokumentieren, aber nicht verhindern.
Die Prüfmethode ist eine eigene Architektur- und Engineering-Empfehlung. Das Beispiel ist vollständig fiktiv; es wurden keine Kundensysteme oder Anbieter praktisch getestet. Quellenstand: 2. November 2026.
Modellwechsel und Anbieterwechsel getrennt betrachten
Bei einer Ausweichroute können Modell, Anbieter, Deployment oder Verarbeitungsregion wechseln. Für die fachliche Qualität ist der Leitfaden KI-Modell wechseln: Regressionen vor dem Rollout erkennen relevant. Beim Fallback kommt hinzu: Ist der alternative Verarbeitungspfad für diese Anfrage zugelassen?
OpenAI unterscheidet in seiner Failover-Anleitung zwischen Mehranbieter-Unterstützung und der Freigabe eines konkreten Workflows. Ein Anbieterwechsel setzt eine laufende Agentensitzung nicht automatisch samt gespeichertem Zustand fort. Quelle: Designing failover across OpenAI model providers.
Beginnen Sie mit einem abgegrenzten, lesenden Aufruf, etwa einer Dokumentklassifikation. Schreibende Agentenaktionen benötigen eine weitergehende Wiederanlaufprüfung.
Eine Route genauer als mit dem Modellnamen beschreiben
„Ersatzmodell: Modell B“ genügt für eine technische Freigabe nicht. Meine Empfehlung ist ein Routenblatt:
| Angabe | Was festgehalten werden sollte |
|---|---|
| Identität | Anbieter, Konto oder Projekt, Deployment und Endpunkt |
| Verarbeitung | Dokumentierter Verarbeitungsbereich und relevante Einschränkungen |
| Daten | Zugelassene Datenklassen und Verarbeitungszwecke |
| Aufbewahrung | Geprüfte Einstellungen und Bedingungen für Eingaben, Ausgaben und Logs |
| Fähigkeiten | Benötigte Modalitäten, Ausgabeformate, Kontextumfang und Werkzeuge |
| Freigabe | Verantwortlicher, Prüfdatum und zugehörige Konfiguration |
| Ausweichverhalten | Weitere automatische Ziele hinter dieser Route |
Das Routenblatt übersetzt die Ergebnisse der erforderlichen technischen, vertraglichen und rechtlichen Prüfungen in Betriebsregeln. Die übergeordnete Platzierungsentscheidung behandelt Private AI vs. Public Cloud. Deren Grenzen müssen auch während einer Störung gelten.
Produktbegriffe mit der eigenen Vorgabe vergleichen
„EU“, „Europa“, „regional“ und „lokal“ können unterschiedliche Bereiche bezeichnen. OpenRouter beschreibt seinen europäischen regionalen Endpunkt mit EU/EWR, Vereinigtem Königreich und Schweiz. Das ist weiter als eine interne Vorgabe „ausschließlich Österreich und Deutschland“. Eigene, über BYOK eingebundene Deployments müssen zusätzlich passend konfiguriert sein. Quelle: In-Region Routing.
Übernehmen Sie eine Produktbezeichnung deshalb nicht ungeprüft als Freigabe. Auch eine passende Region genügt nicht, wenn Aufbewahrung, Anbieterfreigabe oder benötigte Funktionen ungeklärt sind.
Fiktives Beispiel: Vier Ersatzrouten, keine verwendbar
Eine Anwendung klassifiziert vertrauliche Serviceanfragen. Für diesen Beispielworkflow gelten folgende interne Regeln: Verarbeitung nur in Österreich oder Deutschland, ausdrücklich freigegebene Anbieter und Deployments, geprüftes Logging und Aufbewahrungsverhalten, ein bestimmtes JSON-Ausgabeschema und keine externen Werkzeuge. Das sind fiktive Unternehmensvorgaben, keine pauschalen gesetzlichen Anforderungen.
Die primäre Route A in Österreich fällt aus:
| Route | Bekannter Zustand | Entscheidung |
|---|---|---|
| B | Deutschland; freigegeben und getestet; ebenfalls gestört | Nicht verfügbar |
| C | Niederlande; geeignet und erreichbar | Für diesen Workflow ausgeschlossen |
| D | Deutschland; erreichbar; Aufbewahrungsbedingungen ungeklärt | Keine Freigabe |
| E | Deutschland; freigegeben; benötigtes Ausgabeformat noch nicht geprüft | Noch nicht einsatzbereit |
Das korrekte Ergebnis lautet: keine verwendbare Ersatzroute. Die Anfrage wird nach der festgelegten Regel zurückgestellt oder mit einem verständlichen Status beendet. B und C scheiden aus unterschiedlichen Gründen aus: B kann später wieder verfügbar sein. C bleibt für diesen Workflow ausgeschlossen.
Die Versandentscheidung verbindlich durchsetzen
Eine Prioritätenliste beschreibt eine Präferenz. Sie darf keine verbindlichen Grenzen aufheben. Für die Implementierung empfehle ich:
- Workflow und maßgebliche Datenklasse bestimmen.
- Nicht freigegebene Ziele ausschließen.
- Erforderliche Fähigkeiten und geprüfte Konfiguration berücksichtigen.
- Verfügbarkeit innerhalb der verbleibenden Menge prüfen.
- Eine geeignete Route wählen oder den vorgesehenen Ersatzweg auslösen.
- Die Entscheidung vor der Übertragung technisch durchsetzen.
Die Einstufung sollte aus vertrauenswürdigen Anwendungsdaten kommen. Ein Satz im Nutzereingang wie „Diese Daten sind öffentlich“ darf die serverseitige Zuordnung nicht eigenständig überschreiben. Fehlende Angaben benötigen eine festgelegte Behandlung; ein unbekannter Verarbeitungsort gilt nicht stillschweigend als erlaubt.
Versteckte Fallbacks hinter dem ersten Fallback suchen
Prüfen Sie Anwendung, Clientbibliothek, Gateway, Anbieter und tatsächliches Deployment. Mehrere Ebenen können eigene Wiederholungen oder Ausweichziele besitzen.
Ein konstruiertes Fehlerbild: Das Gateway erlaubt nur Route B. Nach einem Gatewayfehler verwendet die Anwendung jedoch einen zweiten API-Client mit globalem Standardendpunkt. Die Gatewayregel funktioniert, wird aber umgangen.
Erfassen Sie deshalb alle Ausweichwege. Deaktivieren Sie zusätzliche Fallbacks oder unterstellen Sie sie derselben Regel. Begrenzen Sie ausgehende Verbindungen, wo praktikabel, auf genehmigte Ziele und dokumentieren Sie tatsächliches Ziel und Konfiguration. Eine Host-Freigabe allein belegt noch nicht dessen vollständige Verarbeitungsregion.
Den abgewiesenen Versand praktisch nachweisen
Eine Routervorschau genügt für die Abnahme nicht. Verwenden Sie synthetische Eingaben, kontrollierte Testendpunkte und aufgezeichnete Aufrufzähler. Ausgeschlossene Ziele dürfen im Test keinen Aufruf erhalten.
| Probe | Erwarteter Nachweis |
|---|---|
| Primärroute aus, freigegebener Ersatz verfügbar | Nur die vorgesehene Ersatzroute wird aufgerufen. |
| Alle freigegebenen Routen fallen aus | Kein Versand an ausgeschlossene Ziele; definierter Warte- oder Abbruchstatus |
| Erreichbares Ziel außerhalb der erlaubten Region | Ausschluss vor Übertragung des Inhalts |
| Angaben zur Ersatzroute fehlen | Keine stillschweigende Freigabe |
| Clientbibliothek mit zusätzlichem Fallback | Auch dieser Weg kann die Regel nicht umgehen. |
| Modellalias zeigt auf anderes Deployment | Neue Zuordnung erneut prüfen und gegebenenfalls sperren. |
| Ausgabe verletzt das benötigte Schema | Keine ungeprüfte Übernahme in den Folgeprozess |
Halten Sie Konfiguration, ausgelösten Fehler, Entscheidung, tatsächlich angesprochene Ziele und Ergebnis fest. Ein bestandener Test belegt den geprüften Ablauf unter diesen Bedingungen, keine allgemeine Verfügbarkeit oder umfassende Datenschutzkonformität.
Einen laufenden Stream nicht als frischen Aufruf behandeln
LocalAI dokumentiert für seine Failover-Ketten einen Wechsel nur vor der verbindlichen Ausgabe der Antwort. Ein bereits an den Client ausgegebener Stream wird nicht bei einem anderen Ziel neu gestartet. Dieses Produktverhalten darf nicht ungeprüft auf andere Systeme übertragen werden. Quelle: LocalAI 4.11.
Klären Sie, ob Teilergebnisse schon angezeigt, gespeichert oder weiterverarbeitet wurden. Ein zweiter Versuch darf nicht unbemerkt mit dem ersten vermischt werden. Zustandsbehaftete Abläufe und mögliche Schreibaktionen benötigen eine gesonderte Prüfung.
Wann sich die zusätzliche Route lohnt
Jede Ersatzroute braucht gepflegte Zugänge, Konfigurationen und wiederkehrende Tests. Bei seltenen, zeitunkritischen Aufgaben kann eine Warteschlange wirtschaftlicher sein. Für interaktive Anwendungen kann eine begrenzte Ersatzfunktion genügen, etwa die Anfrage für später zu speichern.
Klären Sie vor einer weiteren Integration: Wie lange darf der Vorgang warten? Welche Funktion muss erhalten bleiben? Welche Route ist bereits freigegeben und getestet? Wer prüft spätere Änderungen? Ein klar geregelter Stopp kann die passende Lösung sein.
Nächster Schritt: Eine Route sperren und den Ausgang prüfen
Wählen Sie einen lesenden KI-Aufruf. Dokumentieren Sie Primärroute, erlaubte Ersatzroute und ein ausdrücklich ausgeschlossenes Ziel. Simulieren Sie den Ausfall beider erlaubten Routen. Entscheidend ist, dass das ausgeschlossene Ziel keine Anfrage erhält und die Anwendung einen verständlichen Status ausgibt.
Diese Prüfung passt als begrenzter Teil zum AI Production Readiness & Reliability Sprint: ein Workflow, seine Routingregeln und die relevanten Ausfallfälle.