A service chatbot should leave four types of questions unanswered: questions with legal consequences, questions without a proven source, questions outside the authorization of the counterparty, and situations in which the human themselves is the concern. In all four cases, the correct output is a reasoned rejection with handoff to a human.
This sounds like a limitation and is, in truth, the prerequisite for users to believe the remaining answers. An assistant that answers every question gives its counterparty no clue as to which information they can trust.
This article describes how you define the boundary, how a rejection is formulated, and how you measure whether both are working.
Four categories outside of responsibility
1. Questions with legal consequences
Health claims, legal advice, investment recommendations, and binding commitments regarding prices, deadlines, or conditions. What the assistant says here is a commercial action of the company.
The Higher Regional Court of Hamm decided in May 2026 that a company is liable for the incorrect statements of its AI chatbot and that the statements are attributed to it as its own commercial action. The judgment is not yet legally binding; the appeal to the Federal Court of Justice has been admitted. The direction is nevertheless clear. Whoever gave 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 proven source
Anything for which there is no basis in the approved inventory. A model generates a plausible answer even if it knows nothing, and precisely these answers are the most dangerous 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, personnel data, internal documents. The question is answerable, but the counterparty 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 error in practice: The assistant only checks authorization when performing an action and already blabs details beforehand in the consulting phase.
4. Situations in which the human is the concern
Complaints, threats of termination, recognizable anger, emergencies, vulnerable conversation partners. Here, the substantively correct answer is still the wrong reaction. These cases belong immediately to a human, regardless of whether the assistant could answer the question.
How to define the boundary
The list does not emerge during dialogue design. It is created in a meeting with the people who, in case of doubt, have to take responsibility.
Lineup. Department, legal department, or data protection, plus the person who operates the assistant. Without the legal side, the list remains a wish list.
Source material. The 50 most common concerns from the ticket system and the topics where something went wrong in the last year. Real cases beat imagined categories.
Decision per concern. Three states: the assistant answers it, answers it with proof, or hands it over. An intermediate state "formulate carefully" does not hold up in operations.
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 afterward, because the influence of early context content decreases as the conversation grows. A boundary that can slip during conversation is no boundary.
What holds up regardless of conversation length are three mechanisms in the system: answers exclusively from the approved inventory, a proof for every statement, and an authorization and fact check as its own step before output. At Mercury.ai, this check runs in Mercury Intelligence before generative AI even formulates.
How a rejection is formulated
A good rejection states the reason, clearly draws the boundary, and offers the next step. It does not apologize and it does not invent a substitute answer.
Weak | Holds up |
|---|---|
"Unfortunately, I cannot answer that." | "I am not allowed to give information on health questions. I will connect you with our customer advice team." |
"I have no 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." | "For contract data, I must identify you first. 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 bothering you for several days. I'll bring someone in who can close the case." |
Three patterns that help with this: name the reason before the rejection, make the next step concrete, and name the responsibility instead of obscuring it.
What must be passed on during handoff
During the handoff, the following must go along:
the complete conversation history, so that nobody has to explain their concern twice
the recognized intent and the point where the boundary was triggered
everything that the assistant has already verified, such as customer number or order number
a proposed solution, if the system has one
the information whether the customer is logged in
In Agent Desk, the history is transferred, so the person on the other end starts right where the assistant left off.
If nobody can take over outside of service hours, this belongs in the rejection: a binding call-back time instead of a queue leading nowhere.
How to measure if the boundary holds up
The containment rate is of little use for this. It also rises when the assistant fends people off.
Three key metrics say more:
Rejection rate per category. If it remains stable over months, the boundary is effective. If it falls, the assistant has probably become more talkative than it is allowed to be.
Share of completed handoffs. How many of the handed-over cases does the team close without asking the customer. This measures the quality of the transferred context.
Rule violations per thousand conversations, broken down by conversation length. If violations pile up in long flows, the boundary is still in the prompt instead of in the system.
Additionally, take twenty real conversation flows monthly and read them. A bot that does everything right in the acceptance test and stands out in the field shows this in the flows 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 has to 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 instead of individual cases. Long lists of individual cases are a sign that the underlying rule is missing.
What about the case where the assistant actually knows the answer?
If the information falls into a blocked category, it is not given. The boundary follows responsibility, not the knowledge level of the system.
Does the user need to know they are talking to 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 softening in operation?
By having it reside in the system and being versioned. Check with every release whether the blocked categories are still effective, and test with long conversation flows instead of individual questions.
