Stopping your assistant saying something you have to answer for

Not with a classifier bolted on the end. The controls that hold are structural: narrow what the assistant is allowed to discuss, require answers to be grounded in a source you control, and design refusal as a real behaviour rather than a failure state. A filter on the output is the last line, not the plan.

JarvisBitz

The fear is specific and reasonable. A customer facing assistant says something that commits you: quotes a price you do not offer, promises a refund policy that does not exist, gives advice you are not qualified to give, or produces a sentence that reads badly in a screenshot.

The product usually sold against that fear is a classifier that inspects the answer before it goes out. It is the weakest control available, and it is the one that gets bought because it is the only one that can be added at the end without changing anything.

Why the filter at the end is the weakest option

An output classifier has to recognise a bad answer without knowing what a good one would have been. It has no access to the source material, the customer's entitlement, or your actual policy, so it is pattern matching against tone and topic.

That produces two failures at once, pulling against each other. Tuned loosely it misses the confident invention that reads perfectly well, which is the exact failure you bought it for. Tuned tightly it refuses ordinary requests, and over-refusal is not a safe failure: it drives customers to a phone line, and it is invisible in the metrics because nobody logs the answers that were unnecessarily withheld.

The three controls that actually reduce liability

Narrow what it is allowed to discuss. The cheapest and most effective control, and the one teams resist because it feels like admitting a limitation. An assistant scoped to order status and returns cannot give financial advice, because the topic is not in its scope, not because a filter caught it. Scope is enforced by what the system can retrieve and what tools it holds, and it is checkable rather than probabilistic.

Require grounding, and make it structural. Factual claims should come from a source you control, with the passage identified. This turns an unbounded generation problem into a bounded retrieval problem, and it gives you something to check the answer against, which the classifier never had. It also means an answer with no supporting source is detectable, which is the whole point.

Design refusal as a behaviour, not a failure. Systems refuse badly because refusal was never designed: it is what happens when everything else fails, so it sounds like an error. A designed refusal says what it could not confirm, offers what it does know, and routes onward. Customers accept that. They do not accept a confident wrong answer, and they do not accept a dead end.

Where scoring belongs

None of this means never check the output. It means checking it against something.

Score whether each claim in the answer is supported by the retrieved passages, which is checkable without knowing the right answer in advance, and route unsupported answers to refusal or a person. That is a meaningfully different operation from asking a model whether the text seems risky, and it is the same faithfulness measurement we describe in why RAG gives wrong answers, used here as a control rather than a diagnostic.

Keep a small classifier for the narrow categories where pattern matching genuinely works, which is mostly abuse and obvious category errors. Just do not let it be the plan.

The categories worth handling explicitly

• Commitments. Prices, dates, entitlements, anything a customer could reasonably rely on. These should come from a system of record rather than from generation, and where they cannot, they should be flagged as indicative in the answer itself.
• Regulated advice. If there is a category you are not permitted to advise on, scope it out rather than filter it. A refusal that comes from not having the capability is more robust than one that comes from catching the attempt.
• Comparisons and disparagement. Answers about competitors are a liability class of their own and are easy to scope out entirely.
• Anything the model reads from outside. Content arriving from a customer or a third party is untrusted input, and it can carry instructions aimed at the model, which we cover in prompt injection.

Why scope narrowing gets resisted

The most effective control is also the one that meets the most objection, and the objection is rarely technical. Narrowing scope reads as making the product worse, particularly to whoever presented an assistant that could answer anything.

The reframe that usually lands: an assistant that answers three things reliably is a feature, and one that answers everything unreliably is a risk with a chat interface. Customers do not experience breadth, they experience whether the answer they got was right. Nobody has ever complained that a support assistant declined to discuss tax.

It is also the only control that gets cheaper over time. Filters need retuning as models change; a scope boundary enforced by which tools exist keeps holding.

Measuring it without kidding yourself

Two rates, tracked separately, or you will optimise one into the other.

• Unsupported claims that reached a customer, sampled and read by a person who knows the domain. Counted as incidents rather than expressed as a percentage.
• Refusals that were unnecessary, which requires deliberately sampling refusals rather than assuming they were all correct. This is the number nobody collects, and it is where over-tuned guardrails hide.

Publish both internally. A team that reports only the first will keep tightening until the assistant is useless, and will call that success because the risk metric improved.

If you are heading into a review where somebody will ask what stops the assistant saying something costly, our free AI audit covers what is currently in scope and what is actually grounded, and how we build guardrails covers the structural version rather than the bolt on.

Related reading

A2A explained: when AI agents need to talk to each other

Most businesses do not need it yet. A2A standardises how agents built by different teams or vendors delegate work to each other, which only starts to matter once you have more than one agent and the other one is not yours to change.

Prompt injection: why filters fail and what actually works

Not with filters. A model cannot tell where an instruction came from, so any defence that tries to spot a malicious one will eventually be talked past. What holds is constraining what the agent is able to do after it reads untrusted content, which is an architecture decision rather than a prompt.

Where human approval actually belongs in an AI agent

In front of actions that cannot be undone, or that reach further than a blast radius you have deliberately chosen. Gating everything is close to gating nothing, because a control that fires constantly stops being read. The design work is deciding which actions qualify, then shrinking permissions so the list stays short.