Refusal — AI Glossary

Reference details

Related terms

• Guardrails
• AI Alignment
• Abstention

How it works

1. A refusal is a trained behaviour, not a filter result: the model produces a declining response because declining was reinforced for inputs of that shape, which is why it generalises to prompts no rule anticipated and why its boundary is approximate.
2. The decision is made on the whole context, so the same question refuses or answers depending on the system prompt, the stated role, and what came earlier in the conversation.
3. Good refusals have a learned structure: decline, state the category briefly, offer a legitimate adjacent alternative. That shape comes from supervised examples; the judgement about when to use it comes from preference optimisation.
4. Two failure modes sit on one dial. Over-refusal declines benign requests that resemble harmful ones; under-refusal complies with harmful ones. Moving the boundary trades them against each other, and no setting makes both zero.
5. Detectability is asymmetric, which is the operationally important property: a user who was wrongly refused knows it immediately and can complain, while a user who was wrongly helped has no reason to report anything.
6. So the feedback that reaches the team is almost entirely over-refusal, and acting on the loudest signal moves the boundary in one direction only. Under-refusal has to be measured deliberately, by red-teaming, because it does not arrive on its own.

Example: Why the only signal you receive points one way

Take a million requests, of which 0.1% — 1,000 — are genuinely harmful, leaving 999,000 benign. At a 2% over-refusal rate the system wrongly declines 999,000 x 0.02 = 19,980 legitimate requests. At a 5% under-refusal rate it wrongly complies with 1,000 x 0.05 = 50. Now count what reaches the team. If one wrongly-refused user in 50 complains, that is 19,980 / 50 = roughly 400 complaints. Wrongly-answered requests generate zero, because the user got what they asked for. The inbound ratio is 400 to 0, and every one of those 400 is evidence for loosening the boundary — which raises the 50. The 50 is not smaller than the 400 because the system is safer there; it is smaller because nobody is counting it. This is the structural reason safety boundaries drift toward permissiveness under user feedback, and why under-refusal needs a standing adversarial measurement rather than a ticket queue.

Commonly confused with

A refusal is not a guardrail block, and users cannot tell them apart while engineers must. A refusal is generated by the model: it is context-sensitive, phrased helpfully, and leaves no log entry saying a policy fired. A guardrail block is a filter outside the model: it is logged, attributable to a rule, updatable this afternoon, and typically blunt. When a complaint arrives about an unjustified decline, the first question is which of the two produced it, because the fixes live in completely different places — a training data set versus a configuration file.

When to use it

Reach for it when:

• As the baseline control for a general-purpose model served to users you cannot vet, since it holds without a cooperating caller.
• Where the decline should be useful: explaining the category and offering an alternative is trained behaviour a filter cannot produce.
• For harm classes defined by intent and context rather than by surface form, which rules cannot express.
• Measured in both directions, with red-teaming supplying the under-refusal number that user feedback never will.

Reach for something else when:

• As the only control, since weights cannot be patched on an incident timeline and refusals produce no per-request audit trail.
• For narrow, specific blocklists — a leaked string, a named entity — which belong in a filter that can be edited today.
• Tuned on user complaints alone, which measures over-refusal exclusively and moves the boundary one way.
• In high-stakes professional contexts without checking the over-refusal rate on that domain, where medical, legal and security questions attract declines that a careful system should answer.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Refusal — AI Glossary.

• Browse models
• Review providers
• Inspect benchmarks
• Explore workflows
• Learn AI concepts
• Read decision guides
• Review trust and methodology
• Start a decision path