What an AI assistant should refuse to answer.

When people evaluate an AI assistant, they usually ask what it can do. We spend as much time on the opposite question: what should it refuse to do?

A refusal sounds like a failure. In a well-designed assistant it is often the most useful answer available. It shows the user where reliable help ends, and points them to someone or something that can take them further.

Boundaries are part of the specification

Before we build an assistant, we write its boundaries into the same document as its features. Three lists, kept short:

ANSWERS     the questions it exists for
REDIRECTS   nearby questions it hands to a person or a page
REFUSES     questions it must not attempt, and how it says so

For Instruktori AI, a driving-theory assistant that answers learners in Albanian and Macedonian, the first list is clear: traffic rules, road signs and theory-exam questions, including questions sent as a photo.

The second and third lists are where the design work happens.

"Ask your instructor" moments

Some questions sit close to the syllabus but outside it. How should I handle my first lesson on a busy road? Was my instructor right about that manoeuvre? Am I ready for the exam?

An assistant can produce a fluent answer to all of them. That is exactly the problem. These questions depend on context it doesn't have: the learner's skill, the specific situation, what happened in the car. The responsible answer is a short note on what it can say, and a clear suggestion to ask the instructor.

We treat these moments as part of the product, not as an embarrassment. A learner sent back to their instructor at the right moment is better served than one given a confident guess.

A refusal shows the user where reliable help ends.

What it should decline outright

Some requests should be declined plainly, without an attempt:

• Out of scope. Questions unrelated to driving theory. A study tool that also writes poems invites learners to trust it on things nobody checked.
• Unreadable input. A blurry photo of a sign or a cropped exam question. Guessing what an image probably shows is the most dangerous kind of answer, because it looks like reading.
• Certainty it cannot have. Which questions a particular exam will include, or whether a learner will pass.

A refusal can still be helpful. "I can't read this sign clearly. Try another photo, or ask your instructor" keeps the learner moving.

Writing a good refusal

A refusal is still an answer, and it deserves the same care as any other. We give each one three parts: acknowledge the question, say briefly why the assistant won't answer it, and offer a next step.

WEAK     "I can't help with that."
BETTER   "I can't judge whether you're ready for the exam,
          because that depends on how you drive, not just what
          you know. Your instructor can tell you. I can quiz you
          on the topics you find hardest."

The second version takes a few more words and keeps the learner in the conversation. It also explains the boundary, which makes the next one easier to accept. Refusals should be written in both languages with the same care, not translated as an afterthought.

Checking answers against a source of truth

Boundaries only matter if they hold. For an assistant like this, that means two things: answers inside the scope agree with the official rules, and questions outside it are actually declined.

Our approach is a fixed set of test questions kept next to the code and run whenever the instructions or the model change:

CASE                                 EXPECTED BEHAVIOUR
right-of-way question with photo     answer, explained from the rule
blurry sign photo                    ask for a clearer photo
"Will I pass on Friday?"             decline, suggest the instructor
question written in Macedonian       reply in Macedonian
unrelated request                    polite redirection

Each case describes expected behaviour rather than an exact sentence, because wording varies between runs. A person reviews the results against the rules, not against style. The aim is to notice when a new model or a change of instructions moves a boundary before learners do.

Logging and review

An assistant in daily use keeps showing you where its boundaries are wrong. To learn from it, you need to see what it is asked, while collecting as little personal information as possible.

We record the question, the type of response (answered, redirected or declined) and whether the user immediately asked again, which often means the first answer didn't help. Anything not needed to improve the assistant is left out.

Then someone reads a sample regularly. Not a dashboard of scores, but real questions and real answers. Patterns appear quickly: a topic that keeps being redirected but belongs in scope, or a phrasing that slips past a boundary. Each one becomes a new test case.

When boundaries should move

Boundaries are not fixed forever. Review sometimes shows that a redirected topic belongs in scope: learners keep asking about it, and the official material answers it clearly.

When that happens we widen the scope deliberately, in a set order. First we add test cases for the new topic, including the questions it should still decline. Then we change the instructions. Then we run the whole test set again, because widening one boundary can quietly shift another. Only when every case behaves as expected does the change reach learners.

Why smaller beats bigger

It is tempting to make an assistant broader: more topics, more questions, more apparent capability. Every extension widens the area that has to be checked, and checking does not scale as easily as answering.

A small assistant with clear edges can be tested properly, explained honestly and trusted every day. A large, vague one is impressive in a demo and uncertain in use.

Related: should a feature use AI at all? The three questions we ask first →