How We Decide What an AI Assistant Should Refuse to Answer

Every assistant gets some answers wrong; that alone isn't the design failure. The failure is a wrong answer delivered with the same tone and certainty as a correct one, because the person asking has no signal to tell the difference. A visibly uncertain wrong answer gets fact-checked by a skeptical reader. A confidently wrong one usually doesn't.

This reframes the goal. We're not trying to build an assistant that never makes a mistake — that's not achievable. We're building one whose confidence level actually tracks how well-supported an answer is, so uncertainty is visible exactly when it should be.

Before training on a single answer, we map categories of questions the assistant should decline outright, regardless of whether the knowledge base happens to contain relevant-looking text: legal advice, financial guidance, medical questions, anything requiring a judgment call a human should own. This list is specific to the business, not generic — a support assistant for a SaaS product has a different danger list than one for a healthcare platform.

Getting this list wrong in either direction causes real problems. Too narrow, and the assistant confidently wanders into territory it shouldn't. Too broad, and it refuses ordinary questions users actually need answered, which trains people to stop trusting it entirely.

Outright forbidden topics are the easy case. The harder one is a question that's legitimate, in-scope, and simply not well covered by the knowledge base — where the assistant has just enough related content to generate a plausible-sounding answer that isn't actually grounded in anything reliable.

This is where most of the design work happens: teaching the assistant to distinguish "I have a direct, sourced answer to this" from "I can generate something that sounds right." The second case should trigger a different response — visible uncertainty, a request for clarification, or an escalation — not a fluent answer produced with borrowed confidence from adjacent content.

When a question crosses a boundary, what happens next matters as much as the refusal itself. A dead-end "I can't help with that" is nearly as frustrating as a wrong answer — it solves the safety problem and creates a new usability one. We design specific escalation routes for specific boundary types: sensitive topics route to a named contact method, out-of-scope questions get redirected to where an actual answer lives, ambiguous questions get a clarifying follow-up instead of a guess.

This turns the boundary from a wall into a handoff. The person asking still gets somewhere useful; they just don't get an unreliable answer along the way.

Launch is not the last word on where the boundaries sit. We treat the first weeks of real usage as the primary input for adjusting them — questions the assistant declined that it probably should have handled, and cases where it answered something it should have flagged. Both directions matter equally; a boundary that's only ever tightened after launch usually started too loose, and one that's never loosened is probably frustrating real users unnecessarily.

Boundary rules are kept configurable specifically so this adjustment is a settings change, not a retraining project — the rules need to keep pace with what real usage actually reveals, not stay frozen at whatever looked reasonable before launch.