Support-Prozesse für KI-Features: Wer hilft, wenn die Antwort falsch ist

Ein Ticket kommt herein: Der KI-Assistent hat einem Kunden eine falsche Lieferzeit genannt. Der First-Level-Support prüft das System. Es läuft, es antwortet, im Log steht keine Fehlermeldung. Nach klassischer Lesart ist damit alles in Ordnung, das Ticket wird geschlossen. Der Kunde hat trotzdem eine falsche Auskunft bekommen, und der nächste Kunde bekommt sie auch.

Klassischer IT-Support kennt zwei Zustände: kaputt oder funktioniert. Ein KI-Feature fügt einen dritten hinzu: Es läuft und antwortet trotzdem falsch. Wer Support-Prozesse für KI-Features aufsetzt, muss diesen dritten Zustand zuerst als eigene Störungsklasse anerkennen. Sonst versickern genau die Meldungen im Ticketsystem, die für die Qualität des Systems am wertvollsten wären, denn jede gemeldete Falschantwort ist ein Prüffall, den das Team nicht selbst finden musste.

Meldekategorien für die Grauzone

Damit KI-Meldungen nicht in der Kategorie Sonstiges landen, braucht das Ticketsystem eigene Kategorien. Vier haben sich als tragfähig erwiesen:

• Faktisch falsch: Die Antwort behauptet etwas Unzutreffendes, etwa einen falschen Preis, eine falsche Frist, eine erfundene Quelle.
• Unvollständig oder irreführend: Die Antwort ist nicht falsch, lässt aber Wesentliches weg oder erzeugt einen falschen Eindruck.
• Außerhalb des Auftrags: Das System antwortet auf etwas, das es ablehnen sollte, oder verweigert etwas, das es beherrschen sollte.
• Ton und Form: Die Antwort ist inhaltlich brauchbar, aber im Ton unpassend oder im Format unbrauchbar.

Genauso wichtig wie die Kategorien ist ein Meldeweg, der die Situation einfriert: die exakte Eingabe, die vollständige Antwort, der Zeitpunkt, idealerweise ein Verweis auf die konkrete Sitzung. Eine KI-Meldung ohne die genaue Eingabe ist kaum reproduzierbar und damit fast wertlos. Ein Meldeknopf direkt an der Antwort, der diese Daten automatisch mitschickt, ist deshalb keine Komfortfunktion, sondern die Grundlage des gesamten Prozesses.

Triage: vom Symptom zur wahrscheinlichen Ursache

Der Second Level braucht ein Schema, das vom beobachteten Symptom zur wahrscheinlichen Ursache führt. Die erste Frage lautet immer: Was sagen die hinterlegten Quellen zu diesem Fall. Daraus ergibt sich eine grobe, aber im Alltag sehr wirksame Weiche:

Befund	Wahrscheinliche Ursache	Zuständig
Antwort widerspricht den hinterlegten Quellen	Prompt- oder Retrieval-Problem	Technik oder Dienstleister
Antwort deckt sich mit den Quellen, Quelle ist aber veraltet	Datenlücke, veralteter Inhalt	Fachbereich
Antwort liegt außerhalb des erlaubten Rahmens	Leitplanken unzureichend	Technik oder Dienstleister
Fall ist auch unter Fachleuten strittig	Erwartung nie sauber definiert	Fachbereich

Diese Triage entscheidet nicht abschließend, aber sie verhindert die zwei häufigsten Fehlwege: dass Datenpflegeprobleme als Technikfehler eskaliert werden und dass echte Systemfehler wochenlang beim Fachbereich liegen, der sie nicht beheben kann.

Eskalationswege zwischen Fachbereich, IT und Dienstleister

Damit die Triage greift, müssen die Anschlussstellen benannt sein, und zwar als Personen oder klar besetzte Rollen, nicht als Sammelpostfächer. Fachliche Fälle gehen an eine benannte Person im Fachbereich, die Inhalte korrigieren oder Erwartungen klären kann. Systemfälle gehen an die interne Technik oder an den Dienstleister, je nachdem, wie die Übergabe der Lösung geregelt wurde.

Zwei Festlegungen entscheiden darüber, ob die Wege in der Praxis funktionieren. Erstens: Wer entscheidet, wenn Fachbereich und Technik sich uneins sind, ob ein Verhalten ein Fehler oder eine vertretbare Antwort ist. Ohne benannten Entscheider pendeln solche Fälle monatelang. Zweitens: Ab welcher Schwere wird das Feature abgeschaltet, statt im Fehlerzustand weiterzulaufen. Diese Schwelle vorab zu definieren ist unangenehm, aber deutlich billiger, als sie im laufenden Vorfall auszudiskutieren.

Gemeldete Fälle sichtbar zu Verbesserungen machen

Ein Support-Prozess für KI-Features ist erst vollständig, wenn er den Kreis schließt. Jeder bestätigte Fall wandert als Prüffall in den Eval-Katalog des Systems, damit derselbe Fehler nach der nächsten Änderung nicht unbemerkt zurückkehrt. Und jeder Melder erhält eine Rückmeldung: was die Ursache war, was geändert wurde, oder warum das Verhalten so bleibt.

Dieser letzte Punkt wird regelmäßig unterschätzt. Wer meldet und nie etwas zurückhört, hört auf zu melden. Die Ticketzahlen sinken, die Statistik sieht gut aus, und das System wird leise schlechter, weil sein wichtigster Sensor ausgefallen ist: die Nutzer, die Fehler noch gemeldet haben. Eine kurze Sammelnotiz an den Fachbereich, welche Meldungen im letzten Monat zu welchen Verbesserungen geführt haben, hält diesen Sensor am Leben und kostet eine halbe Stunde.

Fazit

KI-Features brauchen Support-Prozesse, die den Zustand läuft, antwortet aber falsch als eigene Störungsklasse behandeln. Dazu gehören Meldekategorien, die über kaputt oder funktioniert hinausgehen, ein Meldeweg, der Eingabe und Antwort einfriert, eine Triage, die zwischen Prompt-Problem, Datenlücke und unklarer Erwartung unterscheidet, und Eskalationswege mit benannten Zuständigen und einer definierten Abschaltschwelle. Geschlossen wird der Kreis durch zwei Rückflüsse: bestätigte Fälle in den Prüffall-Katalog, Rückmeldungen an die Melder. Dann ist der Support nicht nur Störungsannahme, sondern der zuverlässigste Verbesserungsmotor, den ein KI-Feature haben kann.