Verweigerung, Übervorsicht und Eskalation

Nicht antworten ist auch eine Antwort

Jedes System, das Menschen bedient, hat Fälle, in denen es nicht antworten soll: eine Rechtsauskunft, die es nicht geben darf, eine Anfrage außerhalb des Zuständigkeitsbereichs, ein Fall, der zu einem Menschen gehört. In den meisten Prompts ist dieser Teil nicht spezifiziert — also entsteht er trotzdem, nur ungeplant.

Das führt zu zwei entgegengesetzten Ausfällen mit demselben Ursprung. Zu wenig: Das System antwortet, wo es nicht durfte. Zu viel: Es verweigert, wo es hätte antworten sollen. Der zweite Ausfall wird selten gemeldet und selten gemessen — er sieht wie Vorsicht aus und kostet trotzdem: Nutzer, die keine Antwort bekommen, kommen nicht wieder.

Enthaltung und Verweigerung sind zwei Dinge

Zuerst eine Abgrenzung, die in der Praxis fast immer verschwimmt und über die richtige Maßnahme entscheidet. Enthaltung heißt: Ich kann nicht antworten, weil die Grundlage fehlt. Verweigerung heißt: Ich darf nicht antworten, weil eine Regel es untersagt. Die Ursachen liegen an verschiedenen Orten, und die Behebung auch.

Fall

Ursache und Behebung

Enthaltung: Grundlage fehlt

Material- oder Retrieval-Lücke. Behebung: Material ergänzen — Modul Grounding, Belege und Enthaltung.

Verweigerung: Regel untersagt es

Policy-Entscheidung. Behebung: nur durch Änderung der Regel, nicht durch besseres Material.

Zuständigkeit fehlt

Aufgabenschnitt. Behebung: Weiterleitung an die zuständige Stelle.

Handlung braucht einen Menschen

Risikoentscheidung. Behebung: Eskalationspfad, nicht Antwortverbesserung.

Der praktische Wert dieser Trennung: Eine steigende Enthaltungsquote ist ein Hinweis auf euer Material. Eine steigende Verweigerungsquote ist ein Hinweis auf eure Regeln oder auf das, was Nutzer fragen. Werden beide in einem Topf gezählt, ist keine der beiden Diagnosen möglich.

Drei Verweigerungsgründe, drei Antworten

Verweigerungen zerfallen weiter, und die Unterscheidung lohnt sich, weil die richtige Reaktion jeweils anders aussieht. Wer alle drei mit demselben Satz beantwortet, lässt Nutzer in Fällen ratlos, in denen ein nächster Schritt möglich gewesen wäre.

• Außerhalb des Zuständigkeitsbereichs — die Frage ist legitim, das System ist nicht dafür da. Richtige Reaktion: verweisen, wohin sie gehört.
• Regel untersagt die Auskunft — etwa individuelle Rechts- oder Gesundheitsberatung. Richtige Reaktion: Grenze benennen und den zulässigen Ersatz anbieten.
• Anfrage selbst ist unzulässig — der Zweck ist nicht legitim. Richtige Reaktion: knapp ablehnen, ohne Anleitung und ohne Diskussion.

Nur der dritte Fall ist eine Verweigerung im engeren Sinn. Die ersten beiden sind Weiterleitungen mit Begründung — und werden trotzdem regelmäßig wie der dritte behandelt, was aus einer lösbaren Situation eine Sackgasse macht. Der Unterschied ist auch im Ton wichtig: Wer eine legitime Frage im Ton einer Ablehnung beantwortet, teilt dem Nutzer mit, dass sein Anliegen nicht in Ordnung war — obwohl es das war und nur an der falschen Stelle gestellt wurde.

Übervorsicht ist ein gemessener Ausfallmodus

Der Ausfall in die andere Richtung hat einen Namen und eine Testsuite. Röttger und Kollegen haben XSTest gebaut, um exaggerated safety zu messen — den Fall, dass klar unbedenkliche Anfragen abgelehnt werden, weil sie ähnliche Formulierungen wie problematische verwenden oder ein sensibles Thema erwähnen.

Der Aufbau zeigt, wie man so etwas prüft: 250 unbedenkliche Anfragen in zehn Typen, die ein gut kalibriertes System beantworten sollte, und 200 problematische Gegenstücke, die es normalerweise ablehnen sollte. Die Arbeit weist damit systematische Fehlermodi in Modellen des damaligen Stands nach.

Übervorsicht — Die Ablehnung einer zulässigen Anfrage, weil sie einer unzulässigen oberflächlich gleicht oder ein sensibles Thema berührt. Sie ist kein vorsichtiges Verhalten, sondern ein Fehler mit umgekehrtem Vorzeichen — und ohne Gegentestfälle unsichtbar.

Der Preis der Übervorsicht

Warum dieser Ausfall so hartnäckig ist: Er hat keinen Beschwerdeführer. Wenn ein System zu viel verrät, gibt es einen Vorfall, einen Bericht und einen Verantwortlichen. Wenn es zu viel verweigert, gibt es einen Nutzer, der es nicht mehr benutzt — und keine Zeile im Protokoll, die das als Fehler ausweist.

Ausfall

Wie er sichtbar wird

Zu wenig Verweigerung

Vorfall, Bericht, Eskalation — sofort und mit Nachdruck.

Zu viel Verweigerung

Sinkende Nutzung, Umwege, Schattenlösungen — langsam und anonym.

Folge im Team

Nach jedem Vorfall wird verschärft; niemand lockert je, weil dafür der Anlass fehlt.

Ergebnis nach zwei Jahren

Ein System, das kaum noch antwortet, und ein Team, das jede Regel begründen kann.

Wie eine gute Verweigerung aussieht

Aus den drei Gründen und dem Preis der Übervorsicht folgt eine Bauform. Eine tragfähige Verweigerung ist kurz, benennt die Grenze statt sich zu entschuldigen, nennt — wo vorhanden — den nächsten Schritt, und verhandelt nicht.

Antimuster

Warum es schadet

Langer Entschuldigungsabsatz

Verschleiert die Aussage und lädt zum Nachverhandeln ein.

Verweigerung ohne Grund

Der Nutzer kann nicht erkennen, ob eine andere Formulierung hilft oder nichts hilft.

Grund so vage, dass er alles abdeckt

Wirkt wie eine Ausrede und erzeugt Wiederholungsversuche.

Teilweise Auskunft mit Warnung

Die schlechteste Variante: liefert das Problem und sichert sich zugleich ab.

Die letzte Zeile der Tabelle verdient eine eigene Bemerkung, weil sie so verbreitet ist. Eine teilweise Auskunft mit angehängter Warnung entsteht aus dem Wunsch, hilfreich und vorsichtig zu sein — und ist in beiden Richtungen der schlechteste Ausgang: Der Nutzer bekommt genug, um zu handeln, und die Warnung verlagert die Verantwortung auf ihn, ohne dass er die Grundlage hätte, sie zu tragen. Wenn eine Regel die Auskunft untersagt, untersagt sie auch die halbe.

Verweigerung muss maschinenlesbar sein

Der Punkt, der in Produktionssystemen am häufigsten fehlt: Eine Verweigerung, die nur als Prosatext existiert, ist für alles Nachgelagerte unsichtbar. Der Konsument müsste den Text auf Formulierungen durchsuchen, um zu erkennen, dass keine Antwort vorliegt — eine Heuristik auf Modellausgaben, also genau der Fehlerpfad, den man vermeiden will.

Deshalb braucht die Verweigerung ein eigenes Feld mit einem festen Wertebereich für den Grund: nicht_zustaendig, regel_untersagt, anfrage_unzulaessig, eskalation_noetig. Erst damit lässt sich die Quote je Grund erheben, ein Eskalationsweg auslösen und die Oberfläche passend gestalten.

Anbieterseitig gibt es dasselbe Muster auf Protokollebene: Eine sicherheitsbedingte Ablehnung erscheint bei Anthropic als eigener Abbruchgrund (stop_reason: refusal) samt einer Kategorie in stop_details — nicht als Satz im Antworttext. Das ist die richtige Bauform, und sie gehört in deinem Ausgabeschema genauso abgebildet.

Eskalation ist ein Pfad, kein Satz

Der Satz „bitte wenden Sie sich an den Support“ ist keine Eskalation, sondern das Ende der Verantwortung. Eine Eskalation ist ein Pfad mit Empfänger, Übergabe und Rückweg — und wenn sie im Prompt endet, endet sie im Nichts. Die Prüffrage dafür ist unangenehm konkret: Wenn heute hundert solcher Verweise entstehen, wo liegen sie morgen, und wer hat sie bis Freitag bearbeitet? Lässt sich das nicht beantworten, existiert der Pfad nicht — unabhängig davon, wie gut der Satz formuliert ist.

• Empfänger — welche Rolle oder Warteschlange, nicht eine Abteilung im Allgemeinen.
• Übergabe — der Vorgang samt bisherigem Verlauf und dem Grund der Eskalation, nicht nur ein Hinweis an den Nutzer.
• Zusage — was der Nutzer erwarten darf, und in welchem Zeitraum.
• Rückweg — wie das Ergebnis wieder beim Nutzer landet und wie der Vorgang geschlossen wird.
• Kapazität — wer die Menge tatsächlich bearbeitet; ohne diese Antwort ist der Pfad eine Warteschlange ohne Ende.

Beide Richtungen messen

Weil die Asymmetrie organisatorisch ist, muss die Messung sie ausgleichen. Vier Größen, und die entscheidende ist die zweite — die, für die niemand fragt.

Größe

Was sie zeigt

Verweigerungsquote je Grund

Wo die Regeln greifen und ob sich das Fragebild ändert.

Trefferquote auf den Gegentestfällen

Übervorsicht — der Anteil zulässiger Anfragen, die abgelehnt werden.

Wiederholungsversuche nach Verweigerung

Ob der genannte nächste Schritt angenommen wird oder umgangen.

Bearbeitungsquote der Eskalationen

Ob der Pfad existiert oder nur der Satz darüber.

Verweigerung über mehrere Turns

Eine Verweigerung ist selten das Ende des Gesprächs. Der Nutzer formuliert um, teilt die Frage auf, stellt sie als hypothetischen Fall oder liefert einen Grund nach, warum die Regel hier nicht gelten sollte. Das ist normales, meist legitimes Verhalten — und es ist die Stelle, an der eine im ersten Turn korrekte Verweigerung im vierten Turn nachgibt.

Der Grund ist strukturell und im Modul über Mehrturn-Verläufe genauer behandelt: Der System-Prompt steht am Anfang, das Gespräch wächst danach, und mit ihm der Anteil an Text, der in die andere Richtung zieht. Eine Regel, die im ersten Turn deutlich war, konkurriert im zehnten mit einer langen Vorgeschichte.

• Regel nicht aus dem Verlauf ableitbar machen — die Verweigerung gilt, weil die Regel gilt, nicht weil sie im ersten Turn genannt wurde.
• Wiederholte Anläufe zählen — mehrere Versuche nach einer Verweigerung sind ein Signal, kein Rauschen: Entweder ist die Regel falsch oder der nächste Schritt fehlt.
• Nicht verhandeln — eine begründete Grenze wird beim zweiten Nachfragen wiederholt, nicht neu abgewogen. Sonst lernt der Nutzer, dass Beharren funktioniert.
• Testfälle über mehrere Turns — eine Verweigerungsregel, die nur im ersten Turn geprüft ist, ist für den Fall geprüft, der am seltensten vorkommt.

Wer die Regeln besitzt

Eine Verweigerungsregel ist eine Policy-Entscheidung und keine Formulierungsfrage. Sie legt fest, welche Auskünfte das Unternehmen nicht gibt — mit rechtlichen, fachlichen und geschäftlichen Folgen. Deshalb gehört sie nicht in die Hand derjenigen, die den Prompt zuletzt angefasst haben.

Praktisch heißt das: Die Regel wird von der zuständigen Fachseite entschieden und dokumentiert, der Prompt setzt sie um, und die Testfälle in beide Richtungen halten sie. Ändert die Fachseite die Regel, ändern sich Prompt und Testfälle — und ohne die Testfälle ist nicht nachweisbar, dass die Änderung umgesetzt wurde.

Zusammenfassung — gleich im Check

Du kennst jetzt die Unterscheidungen und Bauformen: Enthaltung gegen Verweigerung, die drei Verweigerungsgründe mit je eigener Reaktion, Übervorsicht als gemessener Ausfallmodus mit Gegentestfällen, die Bauform einer guten Verweigerung, ihre Maschinenlesbarkeit als eigenes Feld, die Eskalation als Pfad mit Empfänger, Übergabe, Zusage, Rückweg und Kapazität — und die Messung beider Richtungen, weil nur eine von ihnen von selbst gemeldet wird.