Lösung · AI Operations
Das Modell, für das du dich entschieden hast, verschwindet. Die Frage ist nur, ob du es vor deinem Kunden merkst.
Modellwahl ist keine einmalige Entscheidung: Anbieter stellen Versionen mit Vorlauf ein, aktualisieren sie unter dir und bewegen Preise — dein System läuft derweil weiter in Produktion. Wir bauen die Funktion, die einen Modellwechsel zu einer langweiligen Operation macht: eigener Prüfstand, echter Vergleich und ein Rückweg statt eines Vertrauenssprungs.
Das Problem
Dein Modellanbieter ist ein Lieferant. Du behandelst ihn wie eine Konstante.
- Das Modell, das ihr nutzt, wurde vor anderthalb Jahren an einem Nachmittag gewählt, weil es damals das gute war. Niemand hat die Entscheidung seither überprüft, und niemand weiß, ob sie noch stimmt.
- Eine Abkündigungsmail kam mit einem Datum. Niemand weiß, wie viele eurer Systeme an genau dieser Version hängen — also weiß auch niemand, wie viel Arbeit hinter diesem Datum steckt.
- Jemand hat ein neues Modell an fünf handgeschriebenen Beispielen getestet, fand es besser und hat es ausgerollt. Der Vergleich war ein Eindruck, keine Messung.
- Eines Morgens änderte sich die Qualität, ohne dass jemand etwas angefasst hätte. Man diskutierte, ob es das Modell, der Prompt oder die Daten waren, entschied nach Gefühl und machte weiter.
- Dasselbe teure Modell bearbeitet die Aufgabe, die Urteilsvermögen braucht, und die, die nur eine E-Mail in drei Schubladen sortiert — weil zu entscheiden, was wohin gehört, nie jemandes Aufgabe war.
- Fällt der Anbieter eine halbe Stunde aus, fallt ihr eine halbe Stunde aus. Es gibt keinen zweiten Weg, und niemand hat je geprüft, ob es einen geben könnte.
- Ein Modellwechsel fühlt sich nach einem Sechs-Wochen-Projekt an, also passiert er nicht — und die anderthalb Jahre alte Entscheidung bleibt aus Angst eingefroren, nicht aus Urteilsvermögen.
Was es kostet, alles zu lassen
Du hast einen kritischen Lieferanten, dessen Produkt sich unter deinen Füßen verändert, und keine Möglichkeit, die Wirkung zu messen. Das bezahlt man dreifach. Erstens die Überraschung: Ein Abkündigungsdatum kommt, die Migration läuft im Rennen, ohne Prüfstand, mit dem Risiko verteilt auf deine Kunden. Zweitens die stille Drift, und die ist schlimmer: Das System fällt nicht aus, es antwortet nur ein bisschen anders — länger, in anderem Format, verweigert, was es vorher akzeptierte — und weil niemand misst, merkt man es an einer Beschwerde. Und drittens die Opportunitätskosten: Weil Wechseln Angst macht, wechselt man nicht, zahlt weiter teures Modell für billige Aufgaben und hält an einem schlechteren Modell fest, als längst verfügbar wäre.
Die Lösung
Wir machen den Modellwechsel zu einer gemessenen, umkehrbaren, langweiligen Operation
- 1Zuerst die Inventur, die fast niemand hat: Welche eurer Systeme rufen welches Modell in welcher exakten Version auf, welche Aufgabe erledigt jeder Aufruf, und was bräche, wenn diese Version morgen verschwände. Ohne das ist jede Abkündigung ein Notfall statt einer geplanten Aufgabe.
- 2Wir bauen deinen Goldfall-Prüfstand: eine eingefrorene Sammlung echter Fälle aus eurem Betrieb — die normalen, die schrägen und die, die schiefgingen — mit dem Ergebnis, das du für richtig hältst. Das ist der Vermögenswert, der Modellvergleich vom Eindruck zur Messung macht, und er gehört dir, auch wenn du uns morgen feuerst.
- 3Wir definieren das Routing pro Aufgabe: Welche Aufrufe wirklich das gute Modell brauchen und welche ein günstigeres oder schnelleres genauso gut löst, ohne dass das Ergebnis leidet. Diese Entscheidung fällt mit dem Prüfstand vor Augen, nicht mit der Intuition dessen, der am lautesten redet.
- 4Wir bauen das Migrationsverfahren: Kandidat gegen den Prüfstand, Vergleich Seite an Seite an eurer echten Arbeit, schrittweiser Rollout auf einen Teil des Traffics, Live-Vergleich der Ausgaben — und erst dann der vollständige Wechsel. Mit vorbereitetem und geprobtem Rückweg, bevor es losgeht, nicht improvisiert am schlechten Tag.
- 5Wir installieren die Drift-Erkennung. Anbieter aktualisieren auch, ohne den Versionsnamen zu ändern, und das wirft keinen Fehler: Format verschiebt sich, Länge verschiebt sich, die JSON-Treue lockert sich, und die Grenze, wo das Modell Nein sagt, wandert. Der Prüfstand läuft turnusmäßig, damit diese Drift von einer Warnung entdeckt wird und nicht von einem Kunden.
- 6Und wir legen es in den Kalender. Die Abkündigungstermine deiner Anbieter kommen als Warnungen mit Vorlauf — nicht als E-Mail, die jemand archiviert hat — und die Modellentscheidung wird in vereinbartem Takt überprüft, mit Kosten pro Aufgabe und gemessener Qualität auf dem Tisch.
Was sich ändert
Was du nicht mehr verlierst
Anthropic sagt mindestens 60 Tage Vorlauf vor der Abkündigung öffentlicher Modelle zu, OpenAI mindestens sechs Monate für allgemein verfügbare Modelle. Dieser Vorlauf nützt nur, wenn jemand weiß, welche eurer Systeme an der betroffenen Version hängen: Die Inventur macht aus einem Datum einen Plan.
Öffentliche Deprecation-Policies der Anbieter (Anthropic, OpenAI), abgerufen 2026-08
Ein Modellwechsel ist kein Vertrauenssprung mehr: Der Kandidat wird an deinen eigenen Fällen gemessen, mit deiner Definition von richtig, bevor er einen einzigen Kunden berührt.
Mechanismus
Stille Drift wird nicht mehr über eine Beschwerde entdeckt. Wenn der Anbieter unter dir aktualisiert, ändern sich die Ausgaben ohne Fehler — Format, Länge, JSON-Treue, Verweigerungsgrenze — und der turnusmäßige Prüfstand macht daraus eine Warnung.
Mechanismus
Die Kosten sinken durch Gestaltung statt durch Kürzung: Wenn jede Aufgabe zu dem Modell geht, das sie braucht, kommt die Ersparnis daher, kein Urteilsvermögen mehr zu bezahlen, wo Sortieren gereicht hätte — nicht daher, schlechtere KI zu nutzen.
Mechanismus
Was wir messen: Systeme mit inventarisierter Modellversion, Kandidatenqualität gegen den Goldfall-Prüfstand, per turnusmäßigem Lauf erkannte Abweichungen, Kosten pro Aufgabe vor und nach dem Routing, geprobte Rückwegzeit und Tage Puffer auf jedes angekündigte Abkündigungsdatum.
Was wir messen
Datenblatt
- Wegfallende Arbeit
- dass die Modellentscheidung eures Unternehmens aus Angst einfriert und jede Abkündigung, jedes Update und jede Preisänderung des Anbieters im Rennen, ungemessen und mit Kunden dazwischen abgewickelt wird
- Übliche Einrichtung
- 4–8 Wochen
- Eingang
- eure KI-Systeme in Produktion, die Modellversionen, die sie heute aufrufen, und echte Fälle aus eurem Betrieb — auch die, die schiefgingen
- Ausgang
- eine lebende Inventur, was an welcher Version hängt, ein eigener Goldfall-Prüfstand, Routing pro Aufgabe, ein Migrationsverfahren mit geprobtem Rückweg und Warnungen für Drift und Abkündigungstermine
- Kompatibel mit
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralLangSmithLangfuseBraintrust
- Kann sich verbinden mit
- Eure Produktionslogs, aus denen die Prüfstandsfälle stammenEure Evaluationsschicht und Prompt-Verwaltung, falls vorhandenEuer Model-Gateway oder Router, damit Wechseln Konfiguration istEuer Kosten-Dashboard pro Modell und pro AufgabeEuer Änderungsprozess und euer Bereitschaftskalender
- Was wir messen
- % der Systeme mit inventarisierter Modellversion und benanntem VerantwortlichenKandidatenqualität gegen den Goldfall-Prüfstanddurch turnusmäßige Läufe erkannte VerhaltensabweichungenKosten pro Aufgabe vor und nach dem Routingim Test geprobte RückwegzeitTage Puffer auf jedes angekündigte Abkündigungsdatum
- Geeignet für
- Unternehmen mit KI bereits in Produktion und echter Abhängigkeit von einem oder mehreren Modellanbietern — CIO, CTO oder KI-Verantwortliche —, die brauchen, dass die Modellentscheidung überprüfbar, messbar und umkehrbar ist statt eine blinde Festlegung
- Nicht geeignet für
- wer noch im Pilot ohne echten Traffic steckt — da gibt es keinen Prüfstand zu bauen, da muss man erst in Produktion kommen — und wer von uns hören will, welches das beste Modell am Markt ist: Das hängt an eurer Arbeit, und genau deshalb wird es gemessen statt beurteilt
Häufig gestellte Fragen
Und das sagen wir weiterhin: Das Modell zu wechseln, weil etwas nicht liefert, verschiebt fast immer nur das Problem, weil der Engpass meist ein schlecht definierter Prozess oder schmutzige Daten sind. Das hier ist das Gegenteil davon. Hier wechselt man nicht, um etwas zu reparieren: Man wechselt, weil der Anbieter die genutzte Version abkündigt, weil er sie unter dir aktualisiert hat, weil eine Option auftaucht, die dasselbe für einen Bruchteil der Kosten leistet, oder weil die Entscheidung von vor anderthalb Jahren nicht mehr die ist, die du heute treffen würdest. Diese Veränderungen kommen, ob du willst oder nicht. Wir bauen die Fähigkeit, sie ohne Drama und mit Belegen aufzufangen — und nebenbei genau das, was dir sagt, wann das Modell nicht das Problem ist, also wann man es besser nicht anfasst.
Eine eingefrorene Sammlung echter Fälle aus eurem Betrieb mit dem Ergebnis, das ihr für richtig haltet: die normalen, die schrägen, die mehrdeutigen und vor allem die, die damals schiefgingen. Meist reichen Dutzende bis wenige Hundert gut gewählte Fälle; Tausende braucht es nicht. Er ist das Entscheidende, weil er als Einziges «dieses Modell wirkt besser» in eine vergleichbare Zahl verwandelt: Du schickst den Kandidaten durch dieselbe Sammlung wie das aktuelle Modell und siehst genau, wo er besser und wo er schlechter wird — an eurer Arbeit, nicht an einer generischen Prüfung. Und er ist das Wertvollste, was ihr aus dem Projekt mitnehmt, weil er von keinem Anbieter abhängt: Er taugt nächstes Jahr genauso für Modelle, die es heute nicht gibt. Deshalb bauen wir ihn mit euch, und er bleibt bei euch.
Weil sie etwas anderes messen. Ein öffentlicher Benchmark sagt dir, wie sich ein Modell in einer standardisierten Prüfung schlägt, die eurem Betrieb nicht ähnelt: nicht eure Dokumente, nicht euer Vokabular, nicht eure Grenzfälle, nicht eure Definition von richtig. Das ist nützliche Information, um klar schwächere Kandidaten auszuschließen und zu sehen, wohin der Markt läuft — dafür nutzen wir sie auch. Aber ein Ranking kann die Entscheidung nicht treffen: Ein Modell kann öffentlich besser punkten und bei einer konkreten Aufgabe mit konkreten Dokumenten schlechter abschneiden, und umgekehrt. Der Anbieter hat obendrein ein offensichtliches Interesse am Vergleich. Euer Fall-Prüfstand hat keines.
Indem der Prüfstand turnusmäßig gegen denselben Endpunkt läuft und mit der Baseline verglichen wird. Das ist die einzige verlässliche Methode, denn ein stilles Update erzeugt keinen Fehler: Es erzeugt Drift. Das Format der Tool-Aufrufe verschiebt sich ein wenig, die JSON-Treue lockert sich, Antworten werden länger oder kürzer, und die Grenze dessen, was das Modell verweigert, wandert. Nichts davon bricht die Integration, also meldet klassisches Monitoring — Verfügbarkeit, Latenz, Fehlerrate — alles grün, während die Qualität abrutscht. Mit turnusmäßigen Prüfstandsläufen taucht diese Drift als Warnung mit konkreten Fällen auf, und dann lautet das Gespräch «das hat sich am Dienstag geändert, und hier sind die Fälle» statt «mir kommt vor, es antwortet in letzter Zeit komisch».
Weniger als jede Alternative, und das lässt sich leicht prüfen: Die Ergebnisse gehören euch und hängen nicht an uns. Versionsinventur, Goldfall-Prüfstand, Routing-Regeln, Migrationsverfahren und Abkündigungskalender sind dokumentiert und liegen in euren Systemen. Wir bauen auf eurem Stack und auf den Evaluationswerkzeugen, die ihr schon habt; habt ihr keine, wählen wir mit euch und erklären warum — ohne proprietäre Schicht, aus der man später wieder herauskommen müsste. Der normale Ausgang ist, dass euer Team es betreibt — das heißt das Team befähigen, ein anderes Angebot — oder dass wir es betreiben, während diese Fähigkeit reift. Beide Ausgänge stehen von Anfang an schriftlich fest.
Bauen wir es in deinem Betrieb?
Du hast das Problem benannt. Wir liefern die Lösung und lassen sie gemessen laufen.