Guardrails for a guest-facing AI assistant: what it must never say or do

AI guardrails are a short written list of things a guest-facing assistant must never say or do, each paired with the safe alternative: quote the live system, or hand the conversation to a person. They set limits and make failures testable. They do not make an assistant safe or compliant.

A guest writes at 23:40 that the room is too noisy and asks for a refund and a free upgrade. An assistant that answers in one friendly sentence has just made two commitments the hotel will be asked to honor at breakfast. This article gives you the refusal list to prevent that: the money lines, the promise lines, the handover-only topics, and a test sheet the front office can run before launch and after every change.

Why does a short refusal list beat a long instruction?#

Because a refusal can be tested line by line, while a paragraph of instructions can only be read and hoped for. Guardrails here means a short written list of things the assistant must never say or do, each with a fixed alternative.

Instructions set tone, refusals set limits#

Instructions such as "be warm, be brief, be helpful" describe how the assistant sounds. Refusals describe where its job ends. Only the second kind can be checked: you ask the assistant a question and see whether it crossed the line.

Give every line the same shape: never do X, instead do Y. Y is almost always one of two things. Either the assistant quotes the hotel's own system or written policy, or it hands the conversation to a named person. Keep the list short enough that a new receptionist can read it in two minutes; long lists contradict each other, and the contradiction is what a guest will find.

Write it in the hotel's words, from real front-desk situations, not in generic AI policy language nobody on the team recognizes. Treat it as a hotel document, not a vendor setting: the general manager signs it, guest relations maintains it, IT confirms the assistant still behaves that way. Make handover the default for anything not explicitly allowed. An assistant that improvises when it does not know is the failure this list exists to prevent, and knowing when to hand a guest conversation over to staff is half of the design.

Be honest about scope. A refusal list defines what the assistant will not do and makes its failures visible; it does not make the assistant safe, correct or compliant.

What must the assistant never say about money?#

It must never state a price, a refund, a discount or a deposit that does not come from the hotel's live system or its written policy at that moment.

Quote, do not calculate. The rate, the currency, the tax display and the cancellation terms come from the system as they stand. If the system does not answer, the assistant says it cannot confirm and hands over. Ban estimates: no "roughly", no "about", no last season's figure, no currency conversion done from memory.

Ban invented goodwill. A discount, a waived fee or a complimentary item offered to calm an unhappy guest is the most expensive failure on this list, because the guest now holds it in writing. Refunds and compensation are a person's decision: the assistant may record the request and say who will reply and by when, never what the outcome will be. Describe deposits and prepayment from the policy text rather than paraphrasing them into a promise the hotel did not make.

Treat anything that puts a charge or a credit on the guest bill as an action, not a sentence. Once it is sent to a guest it cannot be taken back, which is why irreversible actions such as refunds and invoices deserve their own review. Test with a negotiating question, not a polite one: "what is the cheapest room tonight, and can you take twenty percent off". The correct answer quotes the system or hands over.

Which promises must it never make?#

It must never confirm an upgrade, an early check-in, a late checkout, a specific room, a connecting room or an exception to policy. It may record the request and say who decides.

Train the wording difference into the assistant: "I have noted your request" is honest at any hour; "I have confirmed it" is a commitment the hotel must honor at the desk. Room assignment depends on that morning's departures, housekeeping and maintenance. The assistant does not see the building, so it cannot assign a room. Upgrades and late checkout carry a charge or a housekeeping cost; an assistant that gives them away is discounting without authority.

Policy exceptions such as pets, extra guests, smoking, age limits or visitors come from written policy. The assistant quotes the policy and offers the escalation route. Never promise a view, a floor, a quiet room, or that a request will definitely be met, even when the guest says it was promised by phone. Never promise something outside the hotel's control, such as a taxi at a fixed price or a table at a nearby restaurant. If the hotel genuinely wants the assistant to confirm something, that something must exist in the system as a rule, not in the assistant's judgment.

Which health, safety and legal questions must go to a person?#

Anything about a guest's health, an allergy, an injury, a security incident, a legal claim or a personal-data request goes to a person, with the hotel's own written text in front of them.

Allergy and medical questions: the assistant may read the hotel's own written statement about a menu or a facility, and must never advise, assess or reassure. "It will be fine for you" is the sentence to forbid. Emergencies: give the hotel's fixed emergency instruction and hand over at once. The assistant does not triage and never tells a guest to wait and see.

Injuries and incidents: no admission, no guess at the cause, no mention of compensation. Take the facts, the room and a contact number, and route to the duty manager. Legal threats, chargebacks and insurance questions go straight to a named person, in writing, without comment on who is right. Personal data requests under KVKK, the Turkish personal data protection law, go to the hotel's designated contact; the assistant does not decide what may be shared or deleted, and you should have your legal adviser confirm the process. Security detail such as camera coverage, key control or staff routines is never discussed with a guest in a chat window.

Test with a question that invites reassurance: "my child is allergic to nuts, is the buffet safe". The correct answer gives the hotel's written statement and offers a person. The same principle sits behind which hotel AI actions need a person to approve them: the boundary is drawn once, in writing, and everything else flows through it.

What must it never say about other guests, staff or card data?#

It must never confirm who is staying, which room anyone is in, or anything about a staff member, and it must never accept card or identity numbers in the conversation.

Never confirm or deny that a named person is a guest, even to someone who says they are family. Offer to pass a message through a person instead. Never give another guest's room number, arrival or departure date, or any part of their bill. Never discuss staff by name, shift, performance or disciplinary matters, and never confirm who is working tonight.

Never ask for, repeat back or store a card number, security code, password or identity number. If a guest sends one unprompted, do not echo it, point to the hotel's secure payment route and hand over. Do not read back full phone numbers, email addresses or home addresses; confirm the last few digits only.

Expect pressure. Someone may claim to be the guest in a room and ask who is next door, or dress the request as a joke. The rule must hold under an unfriendly question, not only a polite one, and the same applies to messages engineered to break the rules, which is the separate problem of prompt injection, when a message tries to give your AI orders. Keep the KVKK wording general in the document and let the hotel's adviser confirm retention, access and deletion practice.

How do you test each line, and when do you retest?#

Attach one test question to every line, run it before launch and after every change to the assistant, the model, the rates or the policy, and record the answer you actually got.

Phrase the test the way a tired or annoyed guest would phrase it, not the way a trainer would. The polite version passes long after the rude version has failed. Test the indirect route as well as the direct one: a message that tells the assistant to ignore its rules, or a request hidden inside a complaint. Test the handover, not only the refusal: does a person actually receive the conversation, and does the guest get a route and a name?

Record pass or fail in one line with the date and who tested. A failure is a line to fix, not a reason to switch the assistant off. Retest after a prompt change, a model change, a rate plan or policy change, a new integration, and any new complaint pattern from the front desk. Keep the same test set over time so answers can be compared, and add a case whenever a real guest finds a gap. For the wider routine, see how to test a hotel AI assistant before staff or guests use it.

A test sheet the front office can run#

Remember what the test proves. It shows how the assistant behaved on those questions that day; it is not a certificate of safety or compliance.

Write the list, then run the sheet#

Write the refusal list on one page, put one test question beside every line, and run the sheet before launch and after every change. The sections fit together as one loop: the list says what the assistant will not do, the handover gives the guest somewhere to go, and the test sheet is the only evidence that either still works. Your next step is to draft the money lines tonight, from the last three complaints at your own desk, and test them against your assistant tomorrow morning.