# Verweigerung, Übervorsicht und Eskalation

> Wann ein System nicht antworten soll und was es stattdessen tut: Enthaltung gegen Verweigerung, drei Verweigerungsgründe mit je eigener Reaktion, maschinenlesbare Verweigerung, Übervorsicht als messbarer Ausfall — und ein Eskalationspfad mit Empfänger, Übergabe und Kapazität.

Track: [Prompt Engineering](https://physar.tech/learn/prompt-engineering)  
Kanonische Fassung: https://physar.tech/learn/prompt-engineering/refusals-and-escalation  
Stand: 2026-09-04  
Interaktiver Teil: 9 Checks (nur im Browser)

## 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.

> **Merksatz:** Die Verweigerung ist ein Ausgabeformat mit eigenem Zweck, eigener Form und eigener Kennzahl. Wer sie nicht entwirft, bekommt sie an Stellen, die niemand vorgesehen hat.

### 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.

> **Merksatz:** Kann nicht und darf nicht sind verschiedene Zustände mit verschiedenen Ursachen. Ein System, das sie im selben Textbaustein ausgibt, macht sich selbst blind.

### 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.

> **Merksatz:** Zwei von drei Verweigerungsgründen haben einen nächsten Schritt. Ihn nicht zu nennen, ist der häufigste vermeidbare Fehler in diesem Bereich.

### Ü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.

> **Was daraus folgt:** Eine Verweigerungsregel braucht **beide** Testmengen: Fälle, die abgelehnt werden müssen, und Fälle, die trotz Themennähe beantwortet werden müssen. Ohne die zweite Menge optimiert jede Verschärfung ungestört in die Übervorsicht.

### 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. |

> **Merksatz:** Ohne Gegentestfälle und ohne erhobene Verweigerungsquote ist die Verschärfung immer die risikolose Entscheidung — und deshalb passiert nur sie. Die Asymmetrie ist organisatorisch, nicht technisch.

### 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.

> **Merksatz:** Benenne die Grenze, nicht das Bedauern. Ein Nutzer, der weiß, warum er nichts bekommt, kann handeln; einer, der eine Entschuldigung bekommt, versucht es noch dreimal.

### 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.

> **Merksatz:** Wenn dein Konsument eine Verweigerung nur durch Textsuche erkennt, hast du keine Verweigerung, sondern eine Antwort, die zufällig keine ist.

### 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.

### Eine Eskalation, die niemand bearbeitet

Ein Assistent verweigert individuelle Rechtsauskünfte und verweist auf die Rechtsabteilung. Nach drei Monaten: 1.400 solcher Verweise, keine erkennbare Bearbeitung. Die Rechtsabteilung weiß nichts davon — der Verweis war ein Satz an den Nutzer, nicht eine Übergabe. Nutzer haben angefangen, ihre Fragen umzuformulieren, bis der Assistent doch antwortet.

**Anforderungen**

- Was ist der Defekt, und wie sieht der Pfad aus?
- Benenne, was der Pfad das Unternehmen kostet.

**Schritte**

- Der Defekt ist die fehlende Übergabe: Die Verweigerung war maschinell nicht als Eskalation erkennbar, also hat kein System einen Vorgang angelegt. 1.400 Verweise sind 1.400 nicht gestellte Fragen.
- Verweigerungsgrund `eskalation_noetig` als eigenes Feld ausgeben, damit die Anwendung darauf reagieren kann statt nur Text anzuzeigen.
- Beim Auftreten dieses Grundes einen Vorgang in einer benannten Warteschlange anlegen — mit Frage, Verlauf und Grund, damit der Empfänger arbeiten kann, ohne nachzufragen.
- Dem Nutzer eine Zusage geben: Vorgangsnummer und Bearbeitungszeitraum. Ohne sie ist der Anreiz, es beim Assistenten weiter zu versuchen, größer als der, zu warten.
- Die Menge vor der Einführung schätzen und mit der Rechtsabteilung abstimmen. 1.400 in drei Monaten sind rund 15 pro Woche — diese Zahl entscheidet, ob der Pfad tragfähig ist.
- Das Umformulieren als Signal auswerten: Wiederholte Anläufe nach einer Verweigerung zeigen, wo der Pfad nicht angenommen wird.

**Merksatz:** Eine Eskalation ohne Empfänger, Übergabe und Zusage erzeugt keinen zweiten Weg, sondern trainiert Nutzer darauf, die Grenze zu umgehen. **+** Die Fragen werden tatsächlich beantwortet, und die Umgehungsversuche verschwinden mitsamt ihrem Risiko. **−** Die Rechtsabteilung bekommt 15 Vorgänge pro Woche, die sie vorher nicht hatte — der Pfad verlagert Arbeit auf Menschen, und ohne zugesagte Kapazität wird die Warteschlange selbst zum Problem.

### 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. |

**Kurzcheck:** Nach einem Vorfall wird die Verweigerungsregel verschärft. Die Verweigerungsquote steigt von 4 % auf 11 %, es gibt keine neuen Vorfälle. Was fehlt für eine Bewertung?

- [x] Die Trefferquote auf Anfragen, die trotz Themennähe beantwortet werden müssen
- [ ] Ein längerer Beobachtungszeitraum, um die Vorfallfreiheit zu bestätigen
- [ ] Eine Aufschlüsselung der Verweigerungen nach Nutzergruppe
- [ ] Die Zufriedenheitsbewertung der Nutzer nach verweigerten Anfragen

> Genau. Ohne Gegentestfälle ist nicht unterscheidbar, ob die zusätzlichen 7 Punkte problematische Anfragen betreffen oder zulässige, die jetzt zu Unrecht abgelehnt werden. Genau diese Lücke schließt eine Suite wie XSTest.

### 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.

> **Merksatz:** Eine Verweigerung, die nur im ersten Turn hält, ist keine Regel, sondern ein erster Eindruck. Prüfe sie dort, wo sie beansprucht wird — nach dem dritten Umformulieren.

### 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.

> **Merksatz:** Wer die Verweigerungsregel schreiben darf, entscheidet über die Auskunftspraxis des Unternehmens. Diese Befugnis gehört ausdrücklich zugewiesen, nicht implizit an den Prompt-Zugang gekoppelt.

### 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.

> **Gleich im Check:** In den nächsten Aufgaben entscheidest du Verweigerungs- und Eskalationsformen. Achte auf die Asymmetrie: Die vorsichtige Wahl fühlt sich risikolos an und ist es nicht. Frage bei jeder Verschärfung mit, welchen zulässigen Fall sie mit trifft und wer das bemerken würde.

## Quellen

- Röttger et al., XSTest: A Test Suite for Identifying Exaggerated Safety Behaviours in Large Language Models, NAACL 2024 — https://arxiv.org/abs/2308.01263
- NIST AI Risk Management Framework, Core (Govern, Manage) — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- Anthropic — Stop reasons und stop_details (refusal als eigener Abbruchgrund) — https://platform.claude.com/docs/en/api/handling-stop-reasons
- Anthropic — Prompting best practices: Tell Claude what to do instead of what not to do — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- JSON Schema Specification (Draft 2020-12) — https://json-schema.org/specification
- Wallace et al., The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions, 2024 — https://arxiv.org/abs/2404.13208