KI im Produktbetrieb: rechnen Sie mit dem Modellwechsel

Eine Funktion, die im März jeden Test bestanden hat, verhält sich im September anders. Niemand hat den Code geändert. Die Prompts sind dieselben, das Retrieval ist dasselbe, und die Testsuite, die im März grün war, ist es noch immer. Etwas weiter oben in der Kette hat sich bewegt, und das erste verlässliche Signal war eine Kundenbeschwerde.

Das ist der Normalzustand beim Betrieb von KI in einem Produkt, kein exotischer Fehlerfall. Nahezu jede Organisation, die auf einem Basismodell aufbaut, betreibt eine Abhängigkeit, die sie nicht kontrolliert, nicht dauerhaft einfrieren kann und nicht selbst spezifiziert hat. Das ist beherrschbar – aber nur bewusst.

Das Risiko, das schneller wächst als die Einführung

Nach Eurostat: Einsatz von künstlicher Intelligenz in Unternehmen nutzten 2025 rund 20 % der EU-Unternehmen ab zehn Beschäftigten KI-Technologien – gegenüber 13,5 % im Vorjahr. Bei großen Unternehmen waren es 55 %. Der Stanford HAI AI Index Report 2026 verzeichnete für 2025 zugleich 362 dokumentierte KI-Vorfälle, nach 233 im Jahr zuvor.

Die Einführung läuft der Betriebspraxis davon. Und der am wenigsten sichtbare Teil dieser Praxis ist der Umgang mit einer Abhängigkeit, die sich ohne Zutun verändert.

Der EU-Gesetzgeber behandelt genau diese Klasse von Abhängigkeit inzwischen ausdrücklich. Die Verordnung (EU) 2022/2554 (DORA) verlangt von Finanzunternehmen, IKT-Drittdienstleister zu erfassen, vertraglich zu binden und Ausstiegswege vorzuhalten. Auch außerhalb des Finanzsektors ist das eine brauchbare Prüfliste: Wer hängt woran, was passiert bei Wegfall, und ist das vertraglich abgesichert?

Sechs Praktiken, die eine Funktion verlässlich halten

1. Version festschreiben – und wissen, wie lange das trägt

Wer den Standard-Endpunkt eines Anbieters aufruft, akzeptiert, was an einem beliebigen Morgen dahintersteht. Eine benannte Modellversion macht aus einer unsichtbaren Änderung eine geplante. Das Festschreiben ist nicht die ganze Antwort, denn Versionen werden abgekündigt. Die entscheidende Zahl ist deshalb nicht nur, auf welcher Version Sie sind, sondern wie viel Vorlauf der Anbieter vor der Abkündigung gewährt – und wie lange Ihr Prüf- und Freigabezyklus dauert. Ist die zweite Zahl größer als die erste, ist genau diese Lücke das Risiko, und sie ist ein Einkaufs- und kein Entwicklungsthema.

2. Einen Prüfsatz führen, der Ihre Arbeit abbildet

Öffentliche Benchmarks beschreiben allgemeine Leistungsfähigkeit. Sie sagen nichts darüber, ob ein Modell noch mit Ihren Dokumentformaten, Ihren Produktnamen, Ihren Grenzfällen und Ihrer Regulierungssprache zurechtkommt. Ein brauchbarer Prüfsatz stammt aus echter Arbeit, ist von Menschen bewertet, die eine richtige Antwort erkennen, ist eingefroren, damit Ergebnisse über die Zeit vergleichbar bleiben, und ist auf die Fälle gewichtet, die wirklich wehtun: die mehrdeutigen, die mit fehlenden Angaben, und die, in denen die richtige Reaktion eine Ablehnung ist.

Hundert gut gewählte Fälle schlagen zehntausend zusammengesuchte. Der Aufwand steckt in der Bewertung, und er fällt einmal an.

3. Ein Modell-Upgrade wie ein Release behandeln, nicht wie eine Mitteilung

Eine neue Version ist kein Ereignis, das Ihnen zustößt, sondern eine Änderung, die Sie annehmen. Lassen Sie den Prüfsatz gegen den Kandidaten laufen, vergleichen Sie mit der festgeschriebenen Version, sehen Sie sich die Unterschiede Fall für Fall an und nicht nur den Gesamtwert – und entscheiden Sie dann. Gleichstand im Durchschnitt verdeckt regelmäßig eine Kategorie, die deutlich schlechter geworden ist; der Mittelwert hält, weil anderes besser wurde.

Das NIST AI Risk Management Framework beschreibt das als fortlaufende Tätigkeit über den Lebenszyklus statt als einmalige Qualifizierung. Praktisch heißt das: ein Freigabepunkt, den jemand verantwortet und verweigern kann.

4. Das Ergebnis instrumentieren, nicht nur die Verfügbarkeit

Übliche Überwachung meldet, dass der Dienst geantwortet hat. Sie meldet nicht, dass die Antworten weniger brauchbar wurden. Ergänzen Sie Signale zur Substanz: Ablehnungs- und Rückfallquoten, Verteilung der Antwortlängen, Anteil der Antworten mit Quellenangabe, wo eine verlangt ist, Übersteuerungsquote durch Menschen und Abbruchquote im Ablauf. Keines davon ist für sich ein Qualitätsmaß, aber zusammen bewegen sie sich, bevor Beschwerden eintreffen. Eine veränderte Verteilung ist auch dann prüfenswert, wenn jede einzelne Antwort vernünftig aussieht.

5. Einen Rückfallweg vorhalten, der nicht dasselbe Modell ist

Belastbarkeit heißt, dass die Funktion sich verschlechtert statt zu verschwinden. Je nach Last kann das ein zweiter Anbieter sein, ein kleineres selbst betriebenes Modell, ein deterministischer Regelpfad, eine zwischengespeicherte Antwort oder eine ehrliche Meldung, die zu einem Menschen führt. Entscheidend ist, dass der Rückfallweg planmäßig geprobt wird. Ein ungeprobter Rückfallweg ist eine Annahme, keine Kontrolle – und er versagt meist an dem Tag, an dem er erstmals wirklich gebraucht wird.

6. Prüfrechte in den Vertrag schreiben

Vieles davon steht nicht zur Verfügung, wenn es nicht eingekauft wurde. Ankündigungsfristen vor der Abkündigung einer Version, das Recht, einen Kandidaten vor der Umstellung zu prüfen, Offenlegung wesentlicher Verhaltensänderungen, Datenverarbeitung und Aufbewahrung, Fortführung des Dienstes und Unterstützung beim Ausstieg gehören in die Vereinbarung. Ein günstiger Pilotpreis ist schlechter Wert, wenn die Organisation den Dienst später weder prüfen noch betreiben noch ersetzen kann.

Wer das verantwortet

Diese Praktiken scheitern leise, wenn niemand für sie zuständig ist, denn keine davon ist an einem bestimmten Tag dringend. ISO/IEC 42001, die Managementsystemnorm für KI, bietet einen Rahmen, den man übernehmen kann, ohne sich zertifizieren zu lassen: festgelegte Verantwortlichkeiten, dokumentierte Ziele, gesteuerte Änderung und Überprüfung über die Zeit.

Auf ein Produktteam übertragen sind das vier benannte Zuständigkeiten. Jemand verantwortet den Prüfsatz und hält ihn aktuell. Jemand verantwortet die Upgrade-Entscheidung und darf nein sagen. Jemand verantwortet die Live-Signale und sieht sie in festem Takt an. Jemand verantwortet Anbieterbeziehung und Vertrag. Das können vier Hüte auf zwei Köpfen sein. Niemand darf es nicht sein.

Womit anfangen

Wenn davon noch nichts existiert, ist die erste Woche keine Architekturübung. Schreiben Sie auf, welche Modelle das Produkt aufruft, in welchen Versionen, über welche Konten. Ziehen Sie fünfzig echte Fälle aus dem letzten Monat und lassen Sie die richtige Ausgabe bewerten. Lassen Sie sie gegen den heutigen Stand laufen und bewahren Sie das Ergebnis auf. Das ist eine Ausgangsmessung, und sie dauert eine Woche.

Alles Weitere wird damit leichter, weil jede spätere Frage – hat dieses Upgrade geholfen, hat jene Prompt-Änderung gewirkt, wird die Funktion schlechter – zu einem Vergleich wird statt zu einer Meinungsfrage.

Wenn Sie eine KI-Funktion in ein Produkt bringen und die Betriebspraxis gleich mitentwerfen lassen möchten: Das ist Produkt- und Plattformarbeit und wird üblicherweise als Umsetzungssprint zugeschnitten.

Dieser Beitrag ist eine Adaption des englischen Originals. Im Zweifel gilt die englische Fassung.