Im Juni war ein Modell drei Wochen lang nicht verfügbar. Nicht wegen eines Ausfalls, sondern wegen einer Exportkontroll-Anordnung. Wer seine Automatisierung fest an dieses eine Modell gebunden hatte, stand still.
Das ist kein hypothetisches Risiko mehr. Und es ist nicht mal das teuerste. Das teuerste ist, dass du Preissenkungen nicht mitnehmen kannst, weil dein Code an einem Anbieter klebt.
Wie die Abhängigkeit entsteht
Fast niemand entscheidet sich bewusst für einen Lock-in. Er entsteht schleichend, in vier Schritten, die jeder für sich vernünftig aussehen.
Zuerst nimmst du das SDK des Anbieters, weil es gut dokumentiert ist. Dann nutzt du eine Funktion, die nur dieser Anbieter hat, etwa ein bestimmtes Werkzeug-Format. Danach schreibst du deine Prompts so, dass sie mit genau diesem Modell gut funktionieren. Und zum Schluss hängen zwanzig Automatisierungen daran.
Jeder einzelne Schritt ist richtig. Das Ergebnis ist trotzdem eine Wand.
Die eine Schicht, die alles ändert
Die Lösung ist unspektakulär: eine dünne eigene Funktion zwischen deinem Code und dem Anbieter. Alles, was mit KI spricht, spricht mit dieser Funktion, nicht direkt mit der API.
In der Praxis reicht dafür erstaunlich wenig. Die Funktion nimmt einen Prompt, einen Kontext und einen Aufgabentyp entgegen und gibt Text zurück. Welches Modell dahinter arbeitet, entscheidet eine Konfiguration, nicht der aufrufende Code.
Der Aufwand dafür liegt bei einem halben Tag, wenn man es früh macht. Er liegt bei zwei Wochen, wenn man es nachträglich macht. Das ist die ganze Botschaft dieses Artikels.
Wer mit Make oder n8n arbeitet statt mit eigenem Code, hat das gleiche Problem in anderer Form: Wenn in jedem Szenario der KI-Knoten direkt konfiguriert ist, änderst du bei einem Wechsel dreißig Szenarien. Ein zentrales Sub-Szenario, das alle anderen aufrufen, löst das genauso.
Warum nicht ein Modell für alles
Es gibt einen zweiten Grund für diese Schicht, und der ist wirtschaftlich interessanter als das Ausfallrisiko: Nicht jede Aufgabe braucht das teuerste Modell.
In einem typischen Automatisierungs-Stack laufen drei sehr verschiedene Arten von Anfragen:
- Sortieren und Klassifizieren. Ist das eine Rechnung oder eine Anfrage? Massenhaft, simpel, unkritisch. Hier reicht das billigste verfügbare Modell.
- Zusammenfassen und Umformulieren. Mittleres Niveau, mittlerer Preis. Fehler sind ärgerlich, aber sichtbar.
- Entscheiden und mehrstufig Arbeiten. Agenten, die Werkzeuge aufrufen und über viele Schritte den Faden halten müssen. Hier lohnt das teure Modell wirklich.
Wer alles über das Spitzenmodell laufen lässt, zahlt für das Sortieren von Mails den Preis für Reasoning. Der Unterschied zwischen dem günstigsten und dem teuersten Modell liegt aktuell beim Faktor 25 oder mehr. Bei zehntausend Anfragen im Monat ist das kein Rundungsfehler.
Was dabei nicht funktioniert
Ein Punkt, an dem ich selbst auf die Nase gefallen bin: Prompts sind nicht portabel. Man kann die Modelle austauschen, aber nicht die Anweisungen eins zu eins mitnehmen.
Anthropic hat das beim letzten Modellwechsel sogar ausdrücklich dazugeschrieben: Das neue Modell verhält sich anders, kommentiert seinen Fortschritt häufiger und neigt dazu, zu viel zu prüfen, wenn man alte Anweisungen weiterverwendet.
Deshalb gehört zu einer Multi-Modell-Architektur ein zweiter Baustein: eine Handvoll gespeicherter Testfälle mit erwarteter Ausgabe. Zehn reichen für den Anfang. Damit siehst du in fünf Minuten, ob ein Modellwechsel deine Abläufe kaputt macht, statt es drei Tage später beim Kunden zu merken.
Und die Datenschutz-Seite
Die Modellvielfalt hat einen Nebeneffekt, der im DACH-Raum wichtiger ist als anderswo. Nicht jede Anfrage darf zum selben Anbieter.
Wenn in einem Vorgang personenbezogene Daten stecken, ist die Frage nach Auftragsverarbeitungsvertrag und Serverstandort keine Formalie. Mit einer zentralen Schicht kannst du diese Regel an einer Stelle durchsetzen: Aufgaben mit sensiblen Daten gehen an einen europäisch gehosteten Anbieter, der Rest an das günstigste Modell. Ohne diese Schicht steht die Entscheidung an dreißig Stellen im Code, und irgendeine davon ist falsch.
Wie sich solche Abläufe ohne Programmierung aufbauen lassen, haben wir in unserer Übersicht zur KI-Automatisierung zusammengestellt.
Fazit
Die Modelle werden sich weiter im Monatstakt überholen. Das ist kein Grund, ständig zu wechseln, aber ein sehr guter Grund, wechseln zu können.
Konkret: eine Funktion zwischen dir und der API, eine Konfigurationsdatei für die Modellwahl pro Aufgabentyp, zehn Testfälle. Das ist der komplette Aufwand, und er zahlt sich beim ersten Preissturz oder beim ersten Ausfall aus.
Josef vom KI Club
