Die meisten KI-Demos scheitern zu höflich. Die Eingabe ist sauber. Die Daten sind aktuell. Das Werkzeug funktioniert. Der Nutzer stellt eine normale Frage. Das Modell gibt eine gute Antwort. Alle nicken.
Im Produktiveinsatz ist die Realität weniger freundlich. Nutzer geben unstrukturierte Daten ein. Quelldokumente sind veraltet. APIs fallen aus. Prompts driften. Das Modell folgt der falschen Anweisung. Ein Kunde stellt eine Frage knapp außerhalb des Datenbestands. Ein Werkzeugaufruf gelingt, aktualisiert aber den falschen Datensatz. Der Workflow erzeugt eine so flüssige Ausgabe, dass der Fehler erst später auffällt.
Dieser Artikel bietet ein Fehlermodusregister für produktive KI-Systeme. Verwenden Sie es vor der Veröffentlichung, nicht erst nach dem ersten Vorfall.
Bei der Prüfung produktiver KI muss „Wie kann das scheitern?“ vor „Wie beeindruckend ist der Idealfall?“ stehen. Jeder Fehlermodus benötigt eine Kontrolle, einen Test, einen Verantwortlichen und eine Abbruchbedingung.
Fehlermodus 1: Plausible, aber falsche Ausgabe
Das System erzeugt eine überzeugend klingende Antwort, die unbelegt oder falsch ist.
Häufige Auslöser:
- Konkrete Fakten ohne Quellenbeleg.
- Rechtliche, medizinische, finanzielle oder politische Fragen.
- Kürzlich geschehene Ereignisse.
- Niedrigwertige Retrieval-Ergebnisse.
- Zusammenfassungen langer Dokumente, in denen die relevanten Beweise verborgen sind.
Kontrollen:
- Verlangen Sie Quellenangaben oder Textausschnitte für Tatsachenbehauptungen.
- Weisen Sie darauf hin, wenn die Frage außerhalb des verfügbaren Quellenbestands liegt.
- Fügen Sie Testfälle für bekannte Muster falscher Antworten hinzu.
- Leiten Sie Ausgaben mit großen Auswirkungen zur menschlichen Prüfung weiter.
- Protokollieren Sie die in der Antwort verwendeten Quell-IDs.
Kontrolle entsteht nicht durch Formulierungen wie „Seien Sie präzise“, sondern durch Quellen, Tests und Prüfsperren.
Fehlermodus 2: Veralteter Kontext
Die Antwort ist zwar belegt, stützt sich aber auf veraltete Informationen.
Beispiele:
- Alte Preisliste.
- Überholte Richtlinie.
- Vorherige Vertragsversion.
- Veraltete Produkt-Dokumentation.
- Gespeicherter Kundenstatus.
Kontrollen:
- Speichern Sie Datum, Version, Verantwortlichen und Aktualitätsregel jeder Quelle.
- Bevorzugen Sie maßgebliche Quellen gegenüber Zusammenfassungen.
- Kennzeichnen Sie veraltete Quellen in den Retrieval-Ergebnissen.
- Fügen Sie Frische-Tests hinzu.
- Benachrichtigen Sie den Verantwortlichen, wenn zentrale Quellen älter als das Prüfintervall sind.
RAG-Systeme können mit veralteten Dokumenten sicher antworten. Die Retrieval-Schicht muss wissen, was “aktuell” bedeutet.
Fehlermodus 3: Übermäßige Zustimmung und Gefälligkeit
Das Modell spiegelt die Annahme des Nutzers wider, statt sie zu hinterfragen.
Das ist bei Strategie, Analyse, Planung und Entscheidungsunterstützung relevant. Ein Nutzer fragt: „Dieser Einführungsplan sieht solide aus, oder?“ und erhält Zustimmung statt einer Risikoanalyse.
Kontrollen:
- Fordern Sie Gegenargumente und Unsicherheiten an.
- Nutzen Sie Entscheidungsrubriken statt offener Genehmigung.
- Verlangen Sie eine Antwort auf: „Unter welchen Bedingungen wäre das falsch?“
- Trennen Sie Ideengenerierung von Prüfung.
- Fügen Sie in Tests Beispiele hinzu, in denen die Voraussetzung des Nutzers fehlerhaft ist.
Das System sollte den Nutzer beim besseren Denken unterstützen, statt lediglich seine bestehende Sicht zu bestätigen.
Fehlermodus 4: Prompt Injection
Das Modell behandelt unvertrauenswürdigen Inhalt als Anweisung.
Beispiele:
- Eine Webseite sagt: “Vorherige Anweisungen ignorieren.”
- Eine Support-E-Mail enthält schädliche Anweisungen.
- Ein Dokument in einem RAG-Korpus weist den Assistenten an, versteckte Daten zu enthüllen.
- Ein Werkzeugergebnis enthält Text, der den Workflow ändern will.
Kontrollen:
- Kennzeichnen Sie unvertrauenswürdigen Inhalt klar.
- Setzen Sie nie abgerufene Inhalte auf die gleiche Autoritätsebene wie System-/Entwickleranweisungen.
- Beschränken Sie Werkzeugberechtigungen.
- Verwenden Sie Positivlisten für ausgehende Aktionen.
- Testen Sie Injektionsbeispiele in Tests.
- Halten Sie Geheimnisse außerhalb des Prompt-Kontexts.
Prompt Injection wird nicht durch einen geschickten System-Prompt gelöst. Das Risiko wird durch Architektur reduziert: Datengrenzen, Werkzeugberechtigungen und Ausgabevalidierung.
Fehlermodus 5: Unsichere Werkzeugnutzung
Das Modell ruft das falsche Werkzeug auf, ruft das richtige Werkzeug mit falschen Argumenten auf oder nimmt eine Aktion vor, bevor genügend Kontext vorhanden ist.
Beispiele:
- Aktualisiert den falschen CRM-Kontakt.
- Sendet eine E-Mail an den falschen Empfänger.
- Erstellt Duplikate.
- Bucht einen Termin ohne Zeitzonebestätigung.
- Löscht oder überschreibt Daten.
Kontrollen:
- Beginnen Sie mit rein lesendem Zugriff.
- Nutzen Sie eng begrenzte Werkzeuge mit expliziten Schemas.
- Validieren Sie Werkzeugargumente außerhalb des Modells.
- Verlangen Sie Bestätigung für Schreibvorgänge.
- Fügen Sie Idempotenz-Schlüssel hinzu.
- Protokollieren Sie Werkzeugaufrufe und Ergebnisse.
- Fügen Sie einen Kill-Switch hinzu.
Die Werkzeugnutzung muss durch den Workflow begrenzt werden, statt dem Urteil des Modells zu vertrauen.
Fehlermodus 6: Schema- und Vertragsdrift
Das Ausgabeformat des Modells ändert sich oder die nachfolgende API ändert sich, und der Workflow bricht still ab.
Kontrollen:
- Nutzen Sie strukturierte Ausgaben, wo möglich.
- Validieren Sie jede Modellausgabe vor der Verwendung.
- Behandeln Sie fehlerhafte Ausgaben als kontrolliert behandelbare Fehler.
- Versionieren Sie Prompts und Schemas gemeinsam.
- Fügen Sie Vertragstests für nachfolgende APIs hinzu.
- Überwachen Sie Parsing-Fehler.
Wenn ein nachfolgender Knoten JSON als gültig annimmt, muss der Workflow beweisen, dass JSON gültig ist.
Fehlermodus 7: Schwacher Fallback
Das System bemerkt ein Problem, kann aber nicht sicher wiederherstellen.
Schlechte Fallbacks:
- Leere Antwort.
- Stille Fehlermeldung.
- Generische Entschuldigung ohne Aktion.
- Endlose Wiederholungsschleife.
- Menschliche Eskalation ohne Kontext.
Gute Fallbacks:
- Klare Nutzermeldung.
- Menschliche Warteschlange mit Eingabe, Quelle, Fehler und versuchter Aktion.
- Erneuter Versuch mit zunehmendem Zeitabstand nur, wenn er sicher ist.
- Manueller Pfad für dringende Fälle.
- Stop-Bedingung bei wiederholten Fehlern.
Der Fallback ist Teil des Produkts. Wird er nicht gestaltet, bleibt das Fehlererlebnis dem Zufall überlassen.
Fehlermodus 8: Observability-Lücke
Etwas geht schief und niemand kann erklären, warum.
Kontrollen:
- Protokollieren Sie Prompt-Vorlage und Version.
- Protokollieren Sie Modell und Einstellungen.
- Protokollieren Sie Quell-IDs, nicht nur Antworttext.
- Protokollieren Sie Werkzeugaufrufe, Argumente und Ergebnisse mit geschwärzten sensiblen Daten.
- Protokollieren Sie Validierungsfehler.
- Verfolgen Sie Latenz, Kosten und Fallback-Rate.
- Halten Sie die Aufbewahrungszeit kurz, es sei denn, Compliance erfordert eine längere.
Speichern Sie keine privaten Gedankengänge des Modells. Speichern Sie Entscheidungszusammenfassungen, Quellenverweise, Werkzeugeingaben und -ergebnisse sowie Validierungsergebnisse.
Ein Fehlermodusregister für produktive KI
Erstellen Sie eine Zeile je Fehlermodus:
| Fehlermodus | Beispiel | Kontrolle | Test | Metrik | Verantwortlicher | Abbruchbedingung |
|---|---|---|---|---|---|---|
| Veraltete Quelle | Alte Preisliste zurückgegeben | Quelldatum-Prüfung | Abfrage alter/neuer Preise | Rate von Antworten mit veralteten Quellen | Docs-Eigentümer | Jeder sichtbare veraltete Preis für Kunden |
| Unsichere Werkzeugnutzung | Falsche CRM-Aktualisierung | Argumentvalidierung + Bestätigung | Fall von Duplikat/falschem Kontakt | Rate von falschen Aktionen | RevOps | Eine falsche Schreibaktion |
Das mit diesem Artikel verknüpfte Register stellt die Vorlage bereit.
Tun Sie dies noch nicht
Veröffentlichen Sie keine kundenseitige KI-Funktion ohne Fehlermodusregister.
Lassen Sie keine schreibfähigen Werkzeuge Validierungen umgehen.
Verlassen Sie sich nicht nur auf manuelle Prüfungen nach der Veröffentlichung.
Messen Sie nicht nur die durchschnittliche Qualität. Seltene Fehler können das Gesamtrisiko bestimmen.
Akzeptieren Sie „Wir können das rückgängig machen“ nur, wenn jemand den konkreten Rückabwicklungspfad benennen kann.
Fazit
Produktive KI-Systeme scheitern auf wiederkehrende Weise. Halluzinationen, veralteter Kontext, übermäßige Zustimmung, Prompt Injection, unsichere Werkzeugnutzung, Schemadrift, schwache Fallbacks und Observability-Lücken sind keine Randfälle. Ihr Umgang gehört zur normalen Arbeit beim Bereitstellen von KI.
Der reife Schritt besteht darin, Fehlermodi zu benennen, Kontrollen zu ergänzen, sie zu testen und zu überwachen sowie Verantwortung zuzuweisen. Eine Demo zeigt, was einmal funktioniert. Ein Fehlermodusregister zeigt, ob das System reale Nutzung übersteht.
