A service chatbot should leave four types of questions unanswered: questions with legal consequences, questions without a verified source, questions outside the user's authorization, and situations where the human themselves is the core concern. In all four cases, the correct output is a reasoned refusal combined with a handoff to a human.

This sounds like a limitation, but in reality, it is the prerequisite for users to trust the remaining answers. An assistant that answers every question gives users no indication of which information they can rely on.

This article describes how to define the boundary, how to phrase a refusal, and how to measure whether both are working effectively.

Four Categories Outside the Scope of Responsibility

1. Questions with Legal Consequences

Health statements, legal advice, investment recommendations, and binding commitments regarding prices, deadlines, or terms and conditions. Whatever the assistant states here constitutes a commercial action by the company.

In May 2026, the Higher Regional Court of Hamm ruled that a company is liable for false statements made by its AI chatbot and that these statements are attributable to it as its own commercial action. The judgment is not yet final, as an appeal to the Federal Court of Justice has been admitted. Nonetheless, the direction is clear: whoever provided the information bears the burden of proof.

Details on the legal framework can be found in our article on the legal admissibility of AI chatbots.

2. Questions Without a Verified Source

Anything for which there is no basis in the approved knowledge base. A model generates a plausible answer even when it knows nothing—and these answers are precisely the most dangerous because linguistically, they are indistinguishable from correct ones.

The rule is simple: If there is no evidence, the response ends. This is also the primary lever to significantly reduce the risk of hallucination.

3. Questions Outside Authorization

Contract data, invoices, HR records, internal documents. The question can be answered, but the user is not authorized to access it. The check must take place before generation so that confidential details never reach the language model in the first place.

A common mistake in practice: The assistant checks permissions only when executing an action, having already disclosed details earlier during the conversational phase.

4. Situations Where the Human Is the Concern

Complaints, threats of cancellation, noticeable frustration, emergencies, vulnerable conversation partners. Here, a factually correct answer is still the wrong response. These cases belong with a human immediately—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 stakeholders who ultimately carry the responsibility.

1. Participants. Line of business, legal or data privacy, along with the person operating the assistant. Without the legal side, the list remains a wishlist.

2. Source material. The 50 most common inquiries from the ticketing system and the issues where things went wrong over the past year. Real cases trump theoretical categories.

3. Decision per inquiry. Three states: the assistant answers it, answers it with a source, or hands it off. An intermediate state like "phrase carefully" does not hold up in production.

4. Outcome. A version-controlled list with dates and approvals that is known to the system. Not just a paragraph in a briefing document.

5. Cadence. Review every three months against actual conversation logs. New products and new regulations shift the boundary.

Why the Boundary Must Exist Outside the Conversation

Common practice writes this list as negative constraints directly into the system prompt. This holds up for the first few messages, but loses effectiveness over time because the influence of early context diminishes as the conversation grows. A boundary that can drift during the conversation is not a boundary.

What holds up regardless of conversation length are three system mechanisms: answers drawn exclusively from approved content, evidence for every statement, and an authorization and fact-checking step executed separately prior to generation. At Mercury.ai, this verification takes place in Mercury Intelligence before generative AI formulates anything at all.

How to Phrase a Refusal

A good refusal states the reason, draws a clear boundary, and offers the next step. It does not apologize, and it does not invent substitute information.

Three patterns that help: state the reason before the refusal, make the next step concrete, and clearly define responsibility rather than obscuring it.

What Must Be Transferred During Handoff

A handoff must include:

• The complete conversation history, ensuring no customer has to explain their issue twice

• The recognized intent and the exact point where the boundary was triggered

• Everything the assistant has already verified, such as customer number or order ID

• A proposed solution, if the system has identified one

• Information on whether the customer is authenticated

In Agent Desk, the full history travels with the handoff, enabling the agent on the other end to pick up right where the assistant left off.

If no one is available to take over outside of service hours, this must be stated in the refusal: offer a binding callback time instead of routing into an empty queue.

How to Measure If the Boundary Holds

The containment rate is of little use here. It also rises when the assistant simply deflects users.

Three metrics are far more informative:

• Refusal rate per category. If it remains stable over months, the boundary is effective. If it drops, the assistant is likely becoming more talkative than it is allowed to be.

• Resolution rate of handoffs. How many handed-off cases the team resolves without having to ask the customer for clarification. This measures the quality of the transferred context.

• Policy violations per thousand conversations, segmented by conversation length. If violations cluster in longer sessions, the boundary still relies on the prompt rather than the system architecture.

Additionally, review twenty real conversation transcripts every month. A bot that passes every acceptance test but causes issues in production reveals this in the transcripts long before it shows up in any dashboard.

Frequently Asked Questions

Doesn't a refusal frustrate customers?

A well-reasoned refusal with a seamless handoff costs far less trust than incorrect information that has to be corrected later. It only becomes critical when the refusal leads to a dead end.

How many topics should the blocklist cover?

As few as possible, formulated as broad categories rather than individual edge cases. Long lists of individual cases are a sign that an underlying systematic rule is missing.

What happens if the assistant actually knows the answer?

If the information falls into a restricted category, it is not provided. The boundary is governed by authorization and scope of responsibility, not by the system's level of knowledge.

Must the user be informed that they are speaking with an AI?

Yes. The EU AI Act mandates transparency when interacting with AI systems. This belongs at the very beginning of the interaction and within the refusal when referring to a human agent.

How do I prevent the boundary from eroding over time in production?

By anchoring it directly within the system architecture and versioning it. With every release, verify that restricted categories are still enforced, testing against long conversation threads rather than isolated single questions.