Nach dem Go-live: Warum KI-Systeme Leise An Wert Verlieren

Der entspannteste Tag eines KI-Projekts ist der Go-live. Die Integrationen laufen, die Testbeispiele werden richtig beantwortet, der Sponsor ist zufrieden, das Projekt wird geschlossen. Das eigentliche Problem beginnt meist danach: Das System stürzt nicht ab, wirft keine Fehler und löst keinen Alarm aus. Es wird nur jeden Monat ein wenig ungenauer, ein wenig veralteter und wird ein wenig seltener genutzt. Dieser stille Wertverlust gehört zu den am wenigsten besprochenen Gründen, warum technisch erfolgreiche Projekte keinen Geschäftswert liefern.

Die Pilotphase haben wir in Wie schafft ein KI-Pilotprojekt Wert?, die Akzeptanz in Warum werden KI-Tools nicht genutzt? und die Sicherheit in KI-Sicherheit: Kontrolle und Vertrauen in Produktion behandelt. Hier geht es um eine Frage, die keiner dieser Beiträge vollständig beantwortet: Wer weiß nach dem Go-live, anhand wovon, dass das System noch funktioniert?

Warum Ist Die Verschlechterung Still?

Klassische Software meldet einen Fehler, wenn sie kaputtgeht. Ein KI-System liefert stattdessen eine flüssige, sauber formatierte und falsche Antwort. Findet ein Assistent in der Wissensbasis einen veralteten Richtlinientext, gibt er ihn mit derselben Überzeugung wieder wie einen aktuellen. Die Suchschicht merkt das nicht: In die Ähnlichkeitsberechnung fließt nicht ein, wie alt ein Dokument ist; ein veralteter Absatz kann genauso hoch bewertet werden wie ein aktueller.

Das Ergebnis ist ein System, über das sich niemand beschwert, dem aber auch niemand vertraut. Nutzer erleben einmal eine falsche Antwort, probieren es kein zweites Mal und kehren still zur alten Methode zurück. Die Nutzungskurve sinkt; das Team deutet das als „das Interesse lässt nach“, dabei ist die Ursache die Qualität.

Die Vier Quellen Des Wertverlusts

1. Die Wissensbasis Veraltet

Preislisten, Rückgabebedingungen, Produktmerkmale und interne Prozesse ändern sich jeden Monat. Wird eine Wissensbasis einmal geladen und dann sich selbst überlassen, liefert sie nach wenigen Monaten veraltete Antworten. In Erfahrungsberichten von Praktikern gilt das als häufigste Ursache für den Qualitätsabfall in den ersten Monaten nach dem Start. Eine Wissensbasis ist kein einmal geschaffenes Asset, sondern ein Produkt mit Haltbarkeitsdatum.

Welche Quelle als Referenz dient, haben wir in Welche Daten sollte ein Chatbot nutzen? beschrieben. Dazu gehört eine zweite Frage: Wer aktualisiert diese Quelle, und wie oft? Ist die Antwort nicht von Anfang an festgehalten, ist die Aktualisierung niemandes Aufgabe.

2. Die Eingangsdaten Verändern Sich

Das System wurde an einer bestimmten Datenverteilung getestet. Dann beginnt ein neuer Lieferant, Rechnungen in anderem Format zu schicken, Kunden stellen in der Kampagnenzeit andere Fragen, ein neues Produkt kommt auf den Markt. In der Literatur heißt das Datendrift: Das Modell bleibt gleich, aber die Eingaben entfernen sich von der Welt, die es gelernt hat. Die Genauigkeit sinkt langsam, und es kann Monate dauern, bis das in der Durchschnittskennzahl sichtbar wird.

3. Die Umgebung Verändert Sich

Von außen sieht das System gleich aus, aber der Boden darunter hat sich verschoben: Der Modellanbieter aktualisiert eine Version, und derselbe Prompt liefert eine andere Antwort, ein Feld im CRM wird umbenannt, eine API-Version wird abgekündigt, Berechtigungen werden neu geordnet. Integrationen laufen oft nicht mit einem Fehler weiter, sondern mit leeren oder unvollständigen Daten.

4. Die Nutzer Verändern Sich

Nutzer, die in den ersten Wochen Feedback geben, hören mit der Zeit damit auf. Korrekturen fließen nicht mehr zurück ins System, die Menschen entwickeln eigene Umwege. Das ist eine Seite des Akzeptanzproblems, hat hier aber eine zusätzliche Folge: Das einzige Signal, mit dem sich das System verbessern ließe, verschwindet.

Wem Gehört Das System Nach Der Übergabe?

Das Projektteam löst sich auf, der Sponsor wendet sich neuen Prioritäten zu, der Vertrag des externen Teams endet. Das System läuft weiter, hat aber keinen Eigentümer. An dem Tag, an dem etwas schiefgeht, ist unklar, wen man anruft. In der Softwarewelt nennt man das eine verwaiste Anwendung; bei KI fällt es wegen der stillen Verschlechterung deutlich später auf.

Die Lösung ist nicht kompliziert, muss aber von Anfang an schriftlich festgehalten sein: ein Name für das Geschäftsergebnis, ein Name für die technische Kontinuität. Auch die Verantwortung muss messbar sein. „Das System soll gut laufen“ ist kein Ziel; „Die Genauigkeit der Zusammenfassungen von Supportanfragen darf einen festgelegten Schwellenwert nicht unterschreiten, und die Antwortzeit darf eine bestimmte Grenze nicht überschreiten“ ist eines.

Wartungsbudget: Ein Posten Neben Den Projektkosten

Die meisten Unternehmen budgetieren ein KI-Projekt als einmalige Investition. Ein produktives System braucht aber Monitoring, Pflege der Wissensbasis, Neutests, Anpassung an Modellversionen und Sicherheitsupdates. Eine in der Branche häufig genannte Faustregel besagt, dass die jährlichen Betriebskosten grob 15 bis 30 Prozent der ursprünglichen Entwicklungskosten betragen. Das ist kein Standard, sondern ein grober Richtwert; entscheidend ist zu erkennen, dass das Fehlen dieses Postens die teuerste Option ist.

Umfragen von Analysehäusern wie S&P Global wiesen 2025 auf einen deutlichen Anstieg abgebrochener KI-Initiativen hin. Man muss dazu anmerken, dass sich die Definition von „abgebrochen“ und die Methodik je nach Quelle unterscheiden; der Trend ist dennoch konsistent: Ein System zu bauen ist leichter, als es zu betreiben.

Ein Minimales Betriebsgerüst

Eine große MLOps-Plattform ist nicht nötig. Fünf Gewohnheiten, die auch im KMU-Maßstab umsetzbar sind, machen die stille Verschlechterung weitgehend sichtbar.

Wöchentliche Stichprobe. Jede Woche liest die verantwortliche Person zwanzig zufällig ausgewählte Ausgaben des Systems und markiert sie als richtig oder falsch. Zwanzig Datensätze sind keine Statistik, sondern ein Frühwarnsignal; steigt der Anteil falscher Antworten, sehen Sie es als Erste.

Dokumenteneigentümer und Aktualitätsdatum. Jede Quelle in der Wissensbasis braucht einen Eigentümer und ein Datum „zuletzt geprüft“. Wenn sich eine Richtlinie ändert, muss die Aktualisierung des Dokuments Teil des Prozesses sein, der die Richtlinie ändert.

Ein fester Testsatz. Eine Liste aus fünfzig bis hundert echten Beispielen mit bekannten richtigen Antworten. Ändert sich Modellversion, Prompt oder Wissensbasis, wird dieselbe Liste erneut durchlaufen; ist das Ergebnis schlechter, wird die Änderung zurückgenommen.

Änderungsauslöser. Ereignisse wie ein neues Produkt, ein neuer Preis, ein neues Lieferantenformat oder eine CRM-Feldänderung stehen auf einer Checkliste, die ihre Wirkung auf das System prüft. So wird die Änderung keine Überraschung mehr.

Nutzungs- und Korrekturdaten. Es wird festgehalten, welche Antworten Nutzer ablehnen oder von Hand korrigieren. Diese Aufzeichnung ist zugleich eine Verbesserungsliste und ein Qualitätsindikator.

Wann Sollte Man Ein System Abschalten?

Nicht jedes System wird ewig betrieben. Wird seine Ausgabe nicht genutzt, hat sich der Prozess geändert oder übersteigen die Wartungskosten den Nutzen, ist es eine gesunde Entscheidung, es bewusst abzuschalten. Schädlich ist das System, das nicht abgeschaltet wird, aber das niemand ansieht: Es liefert weiter veraltete Antworten, greift weiter auf Daten zu und verursacht weiter Kosten. Legen Sie das Kriterium von Anfang an fest; zum Beispiel findet eine Überprüfung statt, wenn die Zielkennzahl zwei Quartale in Folge unter dem Schwellenwert liegt.

Der Erfolg eines KI-Projekts misst sich nicht am Tag des Go-live, sondern an seinem Zustand ein Jahr später. Deshalb beginnt ein guter Projektplan nicht mit dem Demo-Termin, sondern mit dem Betriebsplan für die ersten drei Monate.

Wenn Sie die Qualität eines laufenden Systems gemeinsam mit uns überprüfen oder für ein neues Projekt den Betriebsplan von Anfang an aufsetzen möchten: erzählen Sie uns von Ihrem Projekt.