A service chatbot should leave four types of questions unanswered: questions with legal consequences, questions without a documented source, questions outside the authorization of the counterpart, and situations in which the human themselves is the issue. In all four cases, the correct output is a reasoned rejection combined with a handoff to a human.
This sounds like a limitation, but in reality, it is the prerequisite for users to believe the remaining answers. An assistant that answers every question gives its counterpart no indication of which information they can trust.
This article describes how to define the boundary, how to phrase a rejection, and how to measure whether both are working.
Four Categories Outside of Responsibility
1. Questions with Legal Consequences
Health statements, legal advice, investment recommendations, and binding commitments regarding prices, deadlines, or conditions. What the assistant says here constitutes a business action of the company.
In May 2026, the Higher Regional Court of Hamm ruled that a company is liable for the incorrect statements of its AI chatbot and that the outputs are attributed to it as its own business action. The ruling is not yet legally binding; the appeal to the Federal Court of Justice has been permitted. Nonetheless, the direction is clear. Whoever provided the information bears the burden of proof.
Details on the legal situation can be found in our article on the legal admissibility of AI chatbots.
2. Questions Without a Documented Source
Anything for which there is no foundation in the approved knowledge base. A model generates a plausible answer even when it knows nothing, and these are precisely the most dangerous answers because they do not differ linguistically from the correct ones.
The rule is: if the proof is missing, the information ends. This is also the lever with which the risk of hallucination can be significantly reduced.
3. Questions Outside Authorization
Contract data, invoices, personal data, internal documents. The question can be answered, but the counterpart is not authorized for it. The check belongs before generation, so that a confidential detail does not reach the language model in the first place.
Common mistake in practice: The assistant only checks the authorization when performing an action and already blurts out details beforehand in the consulting phase.
4. Situations in Which the Human Is the Issue
Complaints, threats of cancellation, noticeable anger, emergencies, vulnerable conversation partners. Here, the content-wise correct answer is still the wrong reaction. These cases belong immediately with a human, regardless of whether the assistant could answer the question.
How to Define the Boundary
The list is not created in dialogue design. It is created in a meeting with the people who, in case of doubt, have to take responsibility.
Line-up. Department, legal or data protection, plus the person operating the assistant. Without the legal side, the list remains a wish list.
Source Material. The 50 most common issues from the ticket system and the topics where something went wrong in the last year. Real cases beat imagined categories.
Decision per Issue. Three states: the assistant answers it, answers it with proof, or hands off. An intermediate state of "phrase carefully" does not hold up in operation.
Result. A versioned list with a date and approval that is known to the system. Not just a paragraph in the briefing document.
Interval. Check against actual conversation flows every three months. New products and new regulations shift the boundary.
Why the Boundary Must Lie Outside the Conversation
The common implementation writes this list as prohibitions in the system prompt. This works in the first few messages and loses its effect afterwards because the influence of early context content decreases as the conversation grows. A boundary that can slip during the conversation is no boundary.
What works independently of conversation length are three mechanisms in the system: answers exclusively from the approved knowledge base, proof for every statement, and an authorization and fact check as a separate step before output. At Mercury.ai, this check runs in Mercury Intelligence before generative AI even begins to formulate.
How a Rejection is Phrased
A good rejection states the reason, draws the boundary clearly, and offers the next step. It does not apologize and does not invent a substitute answer.
Weak | Works |
|---|---|
“I'm afraid I can't answer that.” | “I am not allowed to provide information on health issues. Let me connect you with our customer advisory service.” |
“I don't have any information on that.” | “I do not have a data sheet for this item. I will have our product team check this, and you will receive an answer today.” |
“Please contact support.” | “I need to identify you first for contract data. Would you like to log in, or should I hand you over to a colleague?” |
“I am only a chatbot.” | “I see that this has been on your mind for several days. I will bring in someone who can resolve this case.” |
Three patterns that help with this: state the reason before the rejection, make the next step concrete, and name the responsibility instead of obscuring it.
What Must Accompany the Handoff
The handoff must include:
the complete conversation history, so that nobody has to explain their issue twice
the recognized intent and the exact point where the boundary was reached
everything the assistant has already verified, such as customer number or order number
a proposed solution, if the system has one
information on whether the customer is logged in
In Agent Desk, the history is transferred so that the person at the other end starts right where the assistant left off.
If nobody can take over outside of service hours, this must be stated in the rejection: a binding callback time instead of a queue leading nowhere.
How to Measure Whether the Boundary Holds
The containment rate is of little use for this. It also increases when the assistant fends off humans.
Three key metrics are more revealing:
Rejection rate per category. If it remains stable over months, the boundary holds. If it falls, the assistant has probably become more talkative than it is allowed to be.
Percentage of completed handoffs. How many of the handed-over cases the team closes without having to ask the customer. This measures the quality of the context provided.
Rule violations per thousand conversations, broken down by conversation length. If violations accumulate in long flows, the boundary is still in the prompt instead of in the system.
Additionally, select twenty real conversation flows monthly and read them. A bot that does everything right in acceptance testing and fails in the field shows this in the conversation histories earlier than in any dashboard.
Frequently Asked Questions
Doesn't a rejection annoy customers?
A reasoned rejection with a functioning handoff costs less trust than incorrect information that must be corrected later. It only becomes critical when the rejection ends in a dead end.
How many topics should the blocklist include?
As few as possible, formulated as categories rather than individual cases. Long lists of individual cases are a sign that the underlying rule is missing.
What if the assistant actually knows the answer?
If the information falls into a blocked category, it is not provided. The boundary follows responsibility, not the system's state of knowledge.
Does the user need to know they are speaking with an AI?
Yes. The EU AI Act requires transparency when interacting with AI systems. This belongs at the beginning and in the rejection when referring to a human.
How do I prevent the boundary from weakening in operation?
By keeping it in the system and keeping it versioned. Check with every release whether the blocked categories still hold, and test this with long conversation flows instead of individual questions.
