Mein Agent lief weiter, als das Modell abgeschaltet wurde. Nicht, weil ich Glück hatte, sondern wegen einer einzigen Entscheidung, die ich Monate vorher getroffen hatte: Vor allen Modellen sitzt bei mir eine Schicht, die Anfragen verteilt. Fiel ein Modell aus, übernahm ein anderes.
In den ersten drei Teilen dieser Reihe ging es um das Problem. Jetzt geht es um die Lösung.
Der teure Denkfehler: das richtige Modell
Die häufigste Reaktion auf einen Modell-Ausfall ist die Suche nach dem besseren Modell. Das ist verständlich und führt in die Irre.
Modellwahl ist nicht Resilienz. Anbieterwahl ist nicht Resilienz. Cloudwahl ist nicht Resilienz. Wer das beste Modell wählt, hat immer noch genau ein Modell, an dem alles hängt. Er hat seinen Single Point of Failure nur umbenannt.
Resilienz entsteht nicht aus der Wahl, sondern aus der Struktur. Genau das meine ich mit Architektur-Souveränität.
Was Architektur-Souveränität konkret bedeutet
Eine Abstraktionsschicht vor den Modellen. Ihre Anwendungen sprechen nicht direkt mit der API eines Anbieters, sondern mit einer Zwischenschicht, einem Gateway, das entscheidet, welches Modell eine Anfrage bekommt. Das Modell wird austauschbar, ohne dass Sie Ihren Code anfassen.
Mehr als ein Anbieter. Mindestens zwei Modelle unterschiedlicher Herkunft, die dieselbe Aufgabe übernehmen können. Genau das hat meinen Agenten am Leben gehalten.
Automatische Fallbacks. Fällt das primäre Modell aus oder verweigert es, übernimmt ein anderes, nach festen Regeln, nicht im Panikmodus.
Open-Weight als belegte Option. Nicht für jede Aufgabe, aber für wachsend viele eine echte Alternative, die Sie selbst hosten und die niemand von außen abschalten kann.
Diese Richtung ist kein Sonderweg. Auch McKinsey empfiehlt in „Rewired", die KI-Plattform so zu bauen, dass sich Modelle leicht austauschen lassen und Lock-in vermieden wird. (Quelle: McKinsey, „Rewired".)
Der 4-Fragen-Audit
Sie müssen dafür kein Projekt starten. Vier Fragen zeigen in wenigen Minuten, wie ersetzbar Ihre wichtigsten KI-Prozesse sind:
- Können Sie das Modell wechseln? Gibt es eine Schicht dazwischen, oder hängt der Code direkt an einer Anbieter-API?
- Wie lange dauert es? Stunden, Tage oder Wochen, bis ein anderer Anbieter den Prozess trägt?
- Was bricht dabei? Prompts, Werkzeuge, Ausgabeformate, Governance, Compliance, was müsste nachgezogen werden?
- Haben Sie es getestet? Echter Failover schon einmal durchgespielt, oder nur auf der Folie möglich?
Jedes Nein ist ein offenes Risiko. Die vierte Frage ist die wichtigste: Ein Plan B, der nie getestet wurde, ist kein Plan B, sondern eine Hoffnung.
Vom Modell zur Architektur
Wenn die Architektur trägt, verliert der einzelne Anbieter seine Macht über Sie. Modelle werden zu Bauteilen, die Sie tauschen, vergleichen und verhandeln können. Ihre Prozesse, Ihre Governance und Ihre Compliance bleiben bestehen, egal welches Modell gerade darunter läuft.
Architektur-Souveränität endet nicht beim Modell. Je kritischer ein Prozess wird, desto wichtiger wird die Frage, ob auch der Workflow selbst Ausfälle überlebt. Moderne Workflow-Systeme können den Zustand eines Prozesses dauerhaft festhalten. Fällt ein Worker, ein Server oder sogar ein Modell während eines mehrstündigen Ablaufs aus, wird nicht der gesamte Vorgang verloren. Der betroffene Schritt wird wiederholt oder auf einen anderen Pfad gelenkt, während der restliche Prozess erhalten bleibt.
Das ist der praktische Kern dieser Reihe. Teil 5 ordnet ihn ein: was der Vorfall für Europa und für die Regulierung bedeutet.
Kernaussagen dieses Beitrags
- Das beste Modell zu wählen ersetzt keine Resilienz, es benennt den Single Point of Failure nur um.
- Resilienz entsteht aus der Architektur: Abstraktionsschicht, mehrere Anbieter, Fallbacks, Open-Weight als Option.
- Der 4-Fragen-Audit macht Modell-Abhängigkeit in Minuten sichtbar.
- Ein ungetesteter Failover ist kein Failover.
- Resilienz endet nicht beim Modell. Auch langlaufende Prozesse müssen Ausfälle überstehen können.
Beantworten Sie die vier Fragen für Ihren wichtigsten KI-Prozess. Bei welcher zögern Sie?
Move fast and secure things.