Der erste Fehlerfall

Wenn ein klassisches Softwaresystem versagt, meldet es sich lautstark: Server werfen Fehlercodes, Monitoring-Dashboards schlagen rot an, Schnittstellen antworten nicht mehr. Innerhalb weniger Minuten weiß die IT-Abteilung Bescheid, und das Incident-Management beginnt mit der Entstörung.

Ein KI-Workflow, der falsche Entscheidungen trifft, meldet sich nicht. Er arbeitet scheinbar reibungslos weiter. Die Antworten erscheinen in Sekundenbruchteilen, die Formatierung ist makellos und der Tonfall gewohnt souverän. Nur sind die Ergebnisse inhaltlich falsch. Für die technische Überwachung existiert kein Problem – die API-Aufrufe waren erfolgreich, die Latenzen lagen im Soll.

Deshalb ist der erste gravierende Fehlerfall bei generativer KI selten ein plötzlicher Knall. Er ist eine schleichende Entdeckung – meist Wochen nach dem eigentlichen Entstehen und fast immer durch reinen Zufall.

Die Latenzfalle: Wie KI-Fehler im Alltag ans Licht kommen

In der betrieblichen Praxis beginnt ein KI-Vorfall fast immer mit einem diffusen Stirnrunzeln: Einer Sachbearbeiterin fällt auf, dass Tickets gehäuft in der falschen Warteschlange landen. Ein Kunde beschwert sich über eine verbindliche Zusicherung, die niemand freigegeben hat. Oder die Buchhaltung wundert sich über abweichende Summen in automatisiert verarbeiteten Belegen.

Was in genau diesem Moment geschieht, entscheidet über die Höhe des wirtschaftlichen Schadens:

Der teuerste Teil eines KI-Vorfalls sind selten die fehlerhaften Ausgaben an sich. Es sind die Wochen des Zögerns zwischen dem ersten Stirnrunzeln und der ersten offiziellen Meldung.

Diese Verzögerung entsteht nicht aus Nachlässigkeit. Sie entsteht, weil Mitarbeiter nicht sicher sind, ob es sich um ein echtes Systemproblem oder einen harmlosen Einzelfall handelt, weil kein klarer Meldeweg existiert oder weil sie befürchten, mit einer Fehlermeldung nur zusätzlichen bürokratischen Aufwand zu erzeugen. Wer keine barrierefreien Meldewege schafft und eine offene Fehlerkultur vorlebt, erfährt von Problemen erst dann, wenn der Schaden bereits eskaliert ist.

Fünf Fragen, die vor dem Go-Live beantwortet sein müssen

Ein praxistauglicher Notfallplan für einen KI-Workflow muss keinen Aktenordner füllen. Er passt auf eine einzige Seite, muss aber so formuliert sein, dass jede Fachkraft ihn an einem Freitagnachmittag um 16 Uhr verstehen und sofort anwenden kann.

1. Wer meldet Auffälligkeiten, und über welchen Kanal? Ein klar benannter, täglich besetzter Kommunikationskanal. Keine anonyme Sammel-E-Mail-Adresse, in der Hinweise versanden. Und die unmissverständliche Botschaft an alle Teams: Ein begründeter Fehlalarm ist ausdrücklich erwünscht und wird niemals sanktioniert.

2. Wer entscheidet über den Stopp? Der fachliche Owner samt namentlich benannter Stellvertretung. Die Entscheidung zum Anhalten des Systems darf keinem vorherigen Gremienvorbehalt unterliegen. Wer im Ernstfall erst die Freigabe eines Lenkungskreises einholen muss, verliert genau die Stunden, auf die es ankommt.

3. Wie wird das System technisch angehalten? Der konkrete technische Handgriff muss dokumentiert sein: Welcher Schalter im Dashboard, welches Skript, welche Zugangsdaten? Ein Notfallplan ist wertlos, wenn der einzige Entwickler mit Administrationsrechten gerade im Urlaub ist.

4. Wie lassen sich betroffene Altfälle rückwirkend identifizieren? Dies ist die operativ aufwendigste Disziplin des Incident Managements – die sogenannte Rückwärtssuche.

5. Wer informiert wen? Eine präzise Eskalationsmatrix: Welche internen Abteilungen müssen gewarnt werden, die auf Basis der falschen KI-Ausgaben weitergearbeitet haben? Ab welcher Schadensschwelle werden Geschäftsführung, Rechtsabteilung, Datenschutzbeauftragte oder betroffene Kunden informiert?

Die Rückwärtssuche entscheidet über die Kosten

Nehmen wir ein realistisches Szenario: Ein Prompt driftet durch eine unangekündigte Modelländerung des Anbieters am 10. Juni ab. Der Fehler wird jedoch erst am 1. Juli bemerkt. In diesen drei Wochen hat der Workflow 600 Vorgänge verarbeitet.

Die Frage lautet nun nicht, ob diese 600 Vorgänge überprüft werden müssen – das müssen sie zwingend. Die Frage lautet: Wie schnell und präzise lassen sich die tatsächlich fehlerhaften Fälle isolieren?

Die Antwort darauf entscheidet sich lange vor dem Go-Live – nämlich bei der Konzeption des Audit-Loggings. Ein betriebsreifer Workflow muss für jeden Vorgang fünf Metadaten revisionssicher speichern:

• die vollständige Eingabe (Input)
• die generierte Ausgabe (Output)
• den exakten Zeitstempel
• die exakte Version von Prompt, Modell und Kontextdokumenten
• die Information, welcher Mensch das Ergebnis geprüft und freigegeben hat

Liegen diese Daten strukturiert vor, schrumpft die Rückwärtssuche auf eine gezielte Datenbankabfrage zusammen: Alle Vorgänge seit dem 10. August mit einem spezifischen Ausgabemuster lassen sich in Minuten filtern. Fehlen diese Protokolle, bleibt der Fachabteilung nur die manuelle Vollsichtung aller 600 Akten – was hunderte Arbeitsstunden bindet und im Alltag meist dazu führt, dass man nur stichprobenartig prüft und auf das Beste hofft.

Drei Stufen der Intervention: Abschalten ist nicht die einzige Option

Bei einem erkannten Fehler ist der vollständige Not-Aus oft der erste Impuls. Häufig ist er jedoch zu grob und legt unnötig funktionierende Geschäftsprozesse lahm.

Ein gestuftes Vorgehen, orientiert an den Fehlerklassen aus dem Abnahmekriterium, ist meist weitaus pragmatischer:

Stufe 1: Verschärfte Kontrolle (100%-Gegenzeichnung). Das System läuft weiter, aber jedes einzelne Ergebnis muss zwingend durch eine qualifizierte Fachkraft geprüft und gegengezeichnet werden. Das eignet sich für harmlose bis mittelschwere Fehler: Der Beschleunigungseffekt der KI bleibt als Entwurfshilfe teilweise erhalten, das Fehlerrisiko ist sofort eliminiert.

Stufe 2: Gezielter Teilstopp (Bypass). Nur die fehlerhafte Fallgruppe (beispielsweise Dokumente in einer bestimmten Fremdsprache oder Rechnungen über einem Schwellenwert) wird aus dem automatisierten Workflow herausgelöst und wieder rein manuell bearbeitet. Der Standardbetrieb läuft ungestört weiter.

Stufe 3: Vollständiger Not-Aus. Das System wird komplett deaktiviert. Dieser Schritt ist unverhandelbar, wenn nicht hinnehmbare Fehler auftreten, wenn Kunden oder externe Partner direkt betroffen sind oder wenn das tatsächliche Ausmaß der Störung noch vollkommen unklar ist. Unwissenheit über das Schadensausmaß ist ein zwingender Stoppgrund.

Für jede Interventionsstufe muss im Vorfeld ein glasklares Wiedereinschalt-Kriterium definiert sein. Wer ein System abschaltet, ohne festzulegen, welcher Qualitätsnachweis für den Neustart erforderlich ist, schaltet es faktisch nie wieder ein.

Jeder Fehlerfall wandert in die Testsuite

Ist der akute Vorfall ausgestanden, folgt der strategisch wichtigste Schritt, der in der Hektik des Alltags am häufigsten unter den Tisch fällt: das Lernen aus dem Vorfall.

Jeder aufgetretene Fehler aus dem Produktivbetrieb muss umgehend als neuer Testfall in das permanente Eval-Set aufgenommen werden – mit den realen Eingabedaten, dem fehlerhaften Output und der manuell erstellten Korrektur.

Das entfaltet zwei entscheidende Hebel:

1. Garantierter Regressionsschutz: Genau dieser spezifische Fehler kann bei künftigen Prompt-Anpassungen oder Modell-Updates niemals wieder unbemerkt durchrutschen.
2. Reale Qualitätsabbildung: Die Testsuite wächst mit jedem Vorfall und spiegelt nach wenigen Monaten die echten Tücken der eigenen Geschäftsprozesse wider, statt nur theoretische Annahmen abzubilden.

Begleitet werden sollte dieser Prozess durch ein sogenanntes Blameless Post-Mortem. Nicht, wer den Fehler gemacht hat, steht im Fokus, sondern warum das System ihn zugelassen hat und wie der Meldeweg beim nächsten Mal um Tage verkürzt werden kann.

Ein Unternehmen, in dem Fehler von KI-Systemen ohne Angst vor Konsequenzen gemeldet werden, entdeckt Probleme in Tagen. Ein Unternehmen mit restriktiver Fehlerkultur braucht dafür Quartale.

Was eine erfolgreiche Betriebsübergabe ausmacht

Am Ende der dreiteiligen Serie über die Betriebsübergabe steht ein klarer Dreiklang, der weit über Technologie hinausgeht:

1. Eine namentlich benannte Person, die den Workflow fachlich verantwortet, Zeit dafür hat und das System anhalten darf (Teil 1).
2. Ein objektives Abnahmekriterium, das an echten Fällen misst und vorab festlegt, wann ein Ergebnis gut genug ist (Teil 2).
3. Ein einseitiger Notfallplan, der im Ernstfall sofort greift und den Weg zurück sichert (Teil 3).

Wer diese drei Säulen etabliert hat, betreibt generative KI mit echter unternehmerischer Verantwortung. Wer sie ignoriert, betreibt keinen Workflow – sondern einen Piloten, den am Ende niemand mehr kontrollieren kann.