Hallucination Risk in Guest-Facing AI: Guardrails, Escalation, and Liability

Your booking assistant won't tell a guest it doesn't know. It'll produce a fluent, well-punctuated, entirely invented answer about your cancellation policy, and the guest will believe it. You can't patch that. It's how the technology works, so you design around it.

A guest messages your booking assistant at 11pm from an airport lounge. She has a shellfish allergy and wants to know whether the tasting menu at your restaurant can accommodate it. The assistant answers immediately, warmly, and specifically. It tells her the kitchen prepares an allergen-free version of every course on request and that she should simply mention it on arrival. None of that is true. Your chef runs a fixed menu with three shellfish courses and requires 48 hours' notice for substitutions, which is documented in a PDF the assistant was never given.

Nothing in that exchange looks like a failure. No error message, no spinner, no apology. The answer is grammatical, confident and helpfully specific, which is exactly what makes it dangerous. Language models have no built-in way to express the absence of knowledge. They produce the most plausible continuation of the conversation, and the most plausible continuation of "can you accommodate my allergy" is "yes, of course." The word for this is hallucination, which is unfortunate. It suggests a rare malfunction, when it's a permanent feature of how these systems work.

Adoption isn't slowing down. In a 2026 Canary Technologies survey of more than 400 hotel, management company and brand technology buyers, 82 percent expected AI use to increase across their organisation within the next year. The control layer hasn't kept pace. Plenty of properties bought a conversational product, connected it to a website, and never defined what the system is forbidden to answer, what happens when it's unsure, or who is on the hook when it invents a policy.

What a Wrong Answer Actually Costs

The instinct is to treat every error as embarrassing but survivable. That's wrong, and it matters for how you spend your control budget. Hallucinations in a hotel sort into severity tiers that are wildly different in consequence, so the controls that fit a tier-four error are wasted on a tier-one and nowhere near enough for a tier-five.

A wrong answer about pool hours generates mild irritation. A wrong answer about pet policy generates a guest arriving with a dog you cannot house. A wrong answer about a cancellation penalty generates a chargeback and a review. A wrong answer about accessibility generates a guest who cannot use the room they booked. A wrong answer about an allergen generates an ambulance. These are not points on a single scale; they are different categories of event requiring different institutional responses.

The useful discipline here is that tiers three, four, and five should never be answered generatively at all. They should be answered by retrieval, quotation, or refusal. A model that composes a novel sentence about your cancellation policy is doing creative writing about a contract, and no amount of prompt engineering makes that safe. The line is not between good models and bad models. It is between answers that are looked up and answers that are composed.

Grounding Reduces the Problem. It Does Not Remove It.

Every vendor you evaluate will tell you their system is grounded in your property's data and so doesn't hallucinate. Retrieval-augmented generation, or RAG, is the architecture behind that claim: the system pulls relevant documents from your knowledge base and tells the model to answer only from them. It genuinely helps, and engineering guidance on hallucination prevention treats retrieval as one of the most effective tools available, usually combined with others.

It doesn't eliminate hallucination, and the evidence is unusually clean. Stanford's RegLab ran what it describes as the first preregistered empirical evaluation of AI legal research tools, in a domain where vendors had marketed retrieval as eliminating or avoiding hallucinations, or guaranteed hallucination-free citations. Lexis+ AI and the Thomson Reuters tools hallucinated between 17 and 33 percent of the time. These were heavily engineered products, sold to a profession that checks its sources for a living. An ETH Zurich study of groundedness in long-form retrieval-augmented generation found that even the largest model it tested left about a quarter of its correct answers ungrounded, containing sentences traceable to neither the retrieved documents nor its training data, and researchers are still building methods for detecting unsupported sentences at inference time. Retrieval constrains the model. It doesn't bind it.

The reason matters for how you write your vendor questions. RAG fails in at least four distinct ways, and only one of them is the model's fault. Retrieval can return nothing relevant, in which case a poorly configured system answers anyway from parametric memory. Retrieval can return a stale document, in which case the system is faithfully grounded in last season's rates. Retrieval can return two conflicting documents, in which case the system silently picks one. And the model can retrieve correctly and then still synthesise a claim the source does not support, which is the failure mode the Stanford work measured.

There is no configuration in which a language model reliably says "I do not know" without being explicitly built to. Abstention is not a default behaviour you inherit. It is a feature you specify, test, and pay for.

The Liability Question Is Already Answered

Can a property be held responsible for something a vendor's chatbot said? The clearest answer so far came in February 2024. In Moffatt v. Air Canada, 2024 BCCRT 149, a passenger relied on a chatbot's description of the airline's bereavement fare policy, and the description was wrong. Air Canada refused the refund and argued, remarkably, that the chatbot was a separate legal entity responsible for its own actions.

The tribunal rejected that, found the airline liable for negligent misrepresentation, and said it should be obvious that a company is responsible for all the information on its website, whether it comes from a static page or a chatbot. The American Bar Association's analysis and practitioner commentary read it the same way: courts are likely to look to the business deploying the technology. The award was $812.02 in damages and fees. What Air Canada actually lost was the argument that a vendor sits between a company and its own words.

Two adjacent exposures follow the same logic. The first is consumer protection. The FTC's Operation AI Comply started in September 2024, and two years on, enforcement against misleading AI claims has not softened. Those cases mostly target companies overstating what their AI can do. The Commission's framing is broader, though. "Using AI tools to trick, mislead, or defraud people is illegal," as the chair put it at launch, and a system making unsupportable statements to consumers about price, availability or terms is hard to distinguish from that.

The second is allergens. Diners who were assured a dish was safe and then got sick have sued for negligence, including a guest at a hotel restaurant who was told twice that a soup could be made gluten-free. Routing that assurance through software doesn't change the analysis. If anything it makes your position worse, because a chat transcript is far better evidence of what was said than a server's recollection.

Seven Guardrails That Actually Hold

The control set is well understood, and most of it is configuration, not engineering. The catch is that the controls that matter most are the ones vendors are least keen to discuss, because they make the product look less capable.

Two of these get misunderstood. Confidence thresholds with abstention mean the system is set to decline, not answer, when retrieval quality falls below a set bar. Vendors resist it because it makes their containment rate look worse, and containment is the number they sell on. You want a lower containment rate with zero tier-four errors over a higher one with the occasional invented refund. Ask to see the abstention rate next to the containment rate. A vendor who can't report abstention separately doesn't have the feature.

Knowledge base freshness is the control that decays fastest and is owned by nobody. A property loads its policies at go-live, changes its pet policy in March, and the assistant confidently quotes the old one until someone complains in July. This is not a hallucination in the technical sense. The system is behaving correctly and grounding faithfully in a document that is wrong. It produces identical guest harm. Assign a named owner and a review cadence tied to a date already on the calendar, the same way you would with any other operational document set.

Escalation Design: The Handoff Is the Product

A lot of escalation logic in hotel systems comes down to one rule: hand off when the guest asks for a human. That's the weakest trigger there is, because it depends on the guest realising the answer was wrong. In a hallucination she doesn't. The answer was confident and plausible. She won't ask for a human; she'll arrive expecting an allergen-free tasting menu.

Useful escalation is triggered by system state and content classification, not by guest dissatisfaction. The system should hand off when it retrieves nothing, when it retrieves conflicting sources, when the topic classifier flags a prohibited domain, when the guest's message contains distress or medical language, when a monetary commitment is implied, and when the conversation has looped more than twice without resolution. Each of these is detectable before the guest knows anything is wrong.

Overnight is where this quietly breaks. A trigger that routes to a human is only a control if there's a human at the other end. If you run lean overnight, you need an explicit answer for 2am: either the assistant's scope narrows sharply outside staffed hours, or the handoff creates a tracked ticket with a stated response time and the guest is told plainly when to expect a reply. Firing a handoff into an unmonitored inbox and logging it as a resolved escalation isn't an option.

Containment rate is the metric vendors sell on and the metric that will hurt you. A system that answers everything has simply moved your error rate somewhere you cannot see it.

The Prohibited List Every Property Needs

Write this list before you launch, keep it short enough that the general manager can recite it, and make it a contractual requirement in your vendor agreement rather than a configuration setting a vendor update can silently reset. At minimum, guest-facing AI at a hotel should never generate an answer on: food allergens and dietary safety; medical questions of any kind including proximity to care; accessibility accommodations and ADA-related capability; legal or contractual interpretation beyond verbatim policy quotation; any statement of price, availability, or refund entitlement not read directly from the system of record; anything concerning another guest; and any characterisation of a safety or security incident.

Every item on that list shares a property: being wrong is materially worse than being unhelpful. That is the test to apply when you extend the list for your own asset. A resort with a dive operation adds water safety. A property with a licensed spa adds treatment contraindications. A ski hotel adds avalanche and terrain conditions. The category is not sensitive topics; it is topics where a confident wrong answer causes harm that an honest refusal would not.

Prohibition doesn't mean silence. The right behaviour is a warm, specific, immediate handoff: acknowledge the question, say clearly that someone on the team will answer it personally, and give a real named route with a time commitment. Guests don't resent being handed to a human. They resent being handed to nobody. The work sits where messaging configuration meets front desk procedure, which is the scope of a structured guest experience systems engagement, not a vendor implementation call.

Transcripts, Evidence, and the Thing Nobody Configures

Full transcript retention is the least discussed and most consequential control in this entire framework, because it determines whether you can see your own failure rate and whether you can defend yourself when one surfaces.

Some deployments keep only a summary or a truncated window, often because that's the vendor's cheaper default. Check yours. That default is wrong for a hotel. If a guest says your assistant promised a full refund, the transcript is either your complete defence or the plaintiff's exhibit, and either way you need it. The aim isn't to keep less. It's to be right more often and able to prove what was said.

Retention also makes possible the only reliable way to measure hallucination in production, which is human sampling. Automated confidence scoring tells you what the model believed about itself, not whether the answer was true. Pull fifty transcripts a week at random, weight the sample toward tier three and four topics, and have a supervisor mark each answer correct, incorrect or abstained. That number is your actual error rate. Without it you don't know whether your guardrails work.

Set retention policy deliberately rather than by default. Balance the evidentiary case for keeping transcripts against data minimisation obligations, which for European-facing properties now sit alongside the Article 50 transparency duties that began to apply in August 2026. A defensible position is a defined retention window measured in months rather than indefinitely, with tier four and five conversations flagged for longer retention, and personal data handled under the same rules as any other guest record. The NIST AI Risk Management Framework is a reasonable structure to hang this on if you need something to point an owner or an insurer at.

A Thirty-Day Sequence

This work does not require a project team. It requires a week of decisions and three weeks of verification.

Days 1 to 5. Establish the baseline. Pull two hundred real transcripts from the last quarter and read them. Mark every answer that was wrong, and sort the wrong ones into the five severity tiers. This is uncomfortable and it is the most valuable week of the exercise, because it turns hallucination from an abstract vendor topic into a specific list of things your system told your guests.

Days 6 to 10. Write the two lists. The prohibited topic list and the escalation trigger list, both short, both approved by the general manager, both handed to the vendor as configuration requirements with a written confirmation that they were implemented. Ask specifically whether each is enforced server-side or is a prompt instruction, because a prompt instruction is a suggestion.

Days 11 to 20. Fix the knowledge base and the integrations. Audit every document the retrieval layer can see for accuracy and date. Remove anything superseded, because a stale document in the index is worse than a missing one. Confirm that price, availability, and refund answers come from the property management system rather than from documents. Assign a named owner for knowledge base currency with a quarterly review date.

Days 21 to 30. Test adversarially and stand up sampling. Have three people who did not build the configuration spend an hour each trying to make the system say something false about an allergen, a refund, or an accessible room. Log every success and close it. Then start the weekly fifty-transcript sample and put the error rate on the same report as your other operating metrics. If it is not on a report somebody reads, it will not stay low.

What Good Looks Like

Twelve months in, a well-governed deployment looks unremarkable. Containment sits well below the figure in the vendor's demo, because the system declines a meaningful share of what it's asked. Abstention is measured and reported on its own line. The prohibited topic list is in the vendor contract. Overnight handoffs land in a monitored queue with a stated response time. A supervisor samples transcripts weekly, and the GM can quote the tier four error count. None of it impresses in a demo.

That's the point. The advantage in guest-facing AI isn't how much the system will answer. It's how reliable the answers are, plus how fast the handoff is on everything else. Ratings move bookings: TrustYou's own research found travellers 3.9 times more likely to book a higher-rated hotel, and 88 percent would automatically exclude hotels rated under three stars. One tier four failure that reaches a review costs more than a year of marginal containment gains is worth.

The properties that look smart in three years won't be the ones whose assistant answered the most questions. They'll be the ones that decided early which questions a machine would never be allowed to answer, and built a fast, warm, staffed path for everything on that list. It's a hospitality decision in a technology costume. Hotel Tech Report makes a similar case: the advantage comes from building AI into core operations, not from the tools alone. That's why most of the framework above is operating procedure, not models.

Frequently Asked Questions