Human approval for hotel AI: which actions need a person

Human in the loop AI hotel design means a named person can see, understand and refuse a software action before it takes effect. In a hotel, sort every action with three questions: how much money it moves, which guest it touches, and whether it can be undone. That sort decides direct execution, one confirmation, or two.

A refund request lands at 02:40. The software has already matched it to a reservation and calculated the amount. Someone has to decide whether it goes out, and that someone has been awake for sixteen hours. This article gives you a method for that moment: a way to sort every action your software could take, a standard for what an approval screen must show, and a rhythm for moving actions up or down as evidence accumulates.

What does human in the loop mean for a hotel?#

It means a named person can see what will change, understand it in plain words, and stop it, and the software actually obeys the stop. The phrase breaks into three parts, and each one needs a separate check. Visibility: the person sees the exact change before it happens. Comprehension: the change is written in plain language, with the amount and the guest. Authority: a refusal stops the action, not just records an objection.

Separate oversight from control. A daily report of what the software did is oversight. A screen that waits for a person before the action fires is control. The two are easy to confuse.

There is external guidance worth knowing. The Model Context Protocol, an open protocol that lets AI assistants reach outside systems such as a hotel's reservation system, states in its specification that users must explicitly consent to and understand all data access and operations, and that the application must obtain the user's explicit consent before invoking a tool; because the protocol cannot enforce this itself, implementers build consent and authorization flows into their own applications (Model Context Protocol project, specification 2026-07-28 (opens in a new tab)). The same specification's tools section goes further: there should always be a human in the loop with the ability to deny tool invocations, applications should show which tools are exposed to the model and signal clearly when one is used, and client applications should log tool usage for audit (Model Context Protocol project, tools, 2026-07-28 (opens in a new tab)).

Data protection regulators increasingly expect meaningful human involvement in automated decisions. In general terms, defining under which conditions and at which stages oversight comes in helps reduce the risk of unforeseen results, and potentially high-risk decisions are expected to receive extra human review at deployment. The exact duties, thresholds and dates differ by jurisdiction and by your own case, so confirm them with a legal adviser before you rely on them.

So the useful question is never whether a human is somewhere in the loop. It is: at which exact step, with what information on screen, and with what power to say no. For a broader map of where AI touches hotel work, see AI in hotels: a practical guide to uses, limits and safeguards.

Why does human approval turn into a rubber stamp?#

Because approval is cheap to give and expensive to think about, and a screen that asks the same thin question fifty times trains people to stop reading it. Volume is the first cause. Every confirmation costs attention. When the queue is long and the prompts look alike, the fast strategy is pattern matching, and the pattern is usually approve.

Thin prompts are the second. If the screen says approve refund without the amount, the guest, the reservation and the reason, the only rational move is to clear it and get back to the desk. No way back is the third. If an action cannot be undone, the approver has no safe way to learn from a mistake, so they either approve everything or block everything.

The risk literature names this failure. Security frameworks for generative AI warn that automation bias and over-reliance are significant risks, where users may accept confident but incorrect outputs without verification. A confident sentence on a screen is not evidence. Security guidelines for large language models recommend limiting the tools an agent can access and requiring human approval for high-impact actions to prevent excessive agency.

The design response is fewer and better confirmations, not more approvers. Move routine, reversible, internal actions to direct execution with a log, so the confirmations that remain are rare enough to be read.

Which three questions sort every action?#

Ask how much money the action moves, which guest it touches, and whether it can be undone. The three answers together place the action in a tier.

Money means the absolute amount, and its direction. A refund moves money out today. A rate change moves future revenue. A discount gives away margin. Set the threshold in your own currency and review it once a year with finance. Guest means whether the action reaches the guest or stays inside the hotel: a housekeeping assignment or an internal report stays inside, while a message, a charge on the bill or a room move reaches the guest. Reversibility means one click, effort, or never: a sent message, an issued fiscal document and a paid refund sit in the never column, and that column decides more tiers than the money does.

The answers combine rather than compete. A small refund to a guest that cannot be undone is not a small action. A large internal report change that can be reversed is not a large one. Write the rule down, so two managers sorting the same action reach the same tier. A rule that lives in one person's head is not a control.

One distinction helps in your own notes: an action is a software operation, while a refund or a charge is a money transaction with a fiscal trail behind it. Keep the two questions separate when you sort. For the actions at the far end of the spectrum, see Irreversible actions in hotel AI: messages, refunds, invoices.

What do the three tiers look like in practice?#

Tier one runs and is logged, tier two waits for one named person, tier three waits for two people from different roles. The examples below are illustrative, not a standard.

Tier one covers internal, small, reversible actions. For example: assigning a housekeeping task, drafting a shift handover note, moving a reservation between rooms of the same category before arrival, flagging an unpaid balance for the desk. Tier two covers money or guest contact inside written limits: a refund up to a set amount, a rate change on a future date, an upgrade offer, a message to a guest, a no-show charge. Tier three covers large money, fiscal documents and irreversible guest contact: a refund above the limit, voiding a closed invoice, cancelling a group block, a compensation decision, sending a document that carries fiscal weight.

Every tier needs a default for silence. Tier two should expire and do nothing. Tier three should escalate to a named person rather than wait indefinitely or fire on the next click. The second confirmation in tier three must come from a different role, so that one person cannot complete the action alone, even at night.

Keep the list short enough to read. A registry where most actions need confirmation is a queue with extra steps, and queues get cleared without reading.

What must the approver see before confirming?#

Four things: the exact change, the amount, who is affected, and how to undo it. Anything less turns the decision into a guess.

The change should come in before and after form, not as a description of intent. For example: rate for 14 to 16 March, 4,200 to 3,900, rather than a proposal to adjust weekend pricing. The amount should carry its currency and direction, and its source: which reservation, which rule, which calculation. A number without its source cannot be checked. The screen should name who is affected, the guest name and reservation, or the words internal only, so the approver knows whether this reaches a person standing at the desk.

The undo should be stated plainly, including when there is none. If the action cannot be reversed, the screen should say so before the click, not after. Add one sentence on why the software proposed it, and what happens if the person refuses: a refusal that leaves the guest waiting with no next step is not a real option. Finally, put an expiry on the approval itself. A confirmation that sits for three days should not fire silently when someone clicks it by accident.

Who confirms, and what happens at 3 a.m.?#

A named deputy with a written money limit and a phone escalation path. Two-person actions should wait until morning rather than be auto-approved because the second person is asleep. Absence must never become a silent approval. What the approver confirms should also land in a record you can inspect later; see AI audit trails in hotels: what a good record should show.

When should an action move up or down a tier?#

Move an action up when it produces an undo, a complaint or a near miss. Move it down only after a defined period of sampled, reviewed results.

Set a review rhythm: once a quarter is enough for most properties, plus an immediate review after any incident, any change in regulations, or any change in what the software reads. Evidence for moving down is specific: the action ran at its current tier for a defined period, a person sampled the results, and no correction was needed. Without sampling, no complaints means nobody looked. Evidence for moving up is an undo, a guest complaint, a near miss, a new legal duty, or a change in the data the software uses to decide.

Align money thresholds with your own authorization limits, so staff and software follow one rulebook. If a receptionist may refund 2,000 without asking, the software should not need two signatures for the same amount. Record every tier change, who made it and why. The tier list is a policy document that a new manager should be able to read and audit. Watch for creep in both directions: teams lower tiers to shorten queues and raise them after one bad night. Both moves need the same evidence.

What does a three-tier registry look like in a real product?#

AI Otel's PMS assistant keeps a registry of every action it can take, sorted into three safety tiers, and the shape of that registry is the useful part. The registry snapshot of June 2026 holds 207 actions: 107 run directly, 90 need one confirmation, 10 need two (registry snapshot, June 2026).

Read the shape, not the number. Most actions are routine, a large minority touch money or guests, and a small set is irreversible. A registry where the small set is large would be unusable, because the queue would never be read. The PMS assistant is built: it answers questions about a hotel's own property in plain language, carries out routine actions, and a person confirms anything sensitive. Behind it, the decision record is built and runs in a demo environment: small changes apply automatically and are logged, larger ones wait for a person, and every change can be undone except a message already sent to a guest. The reasoning behind building this layer before choosing a model is described in Why AI Otel built the safety layer before choosing a model.

What a general manager should copy is the registry idea, not the counts. Write your own list, sort it with the three questions, and keep it where the front desk can read it. What not to assume: a vendor's tiers are the vendor's judgement about risk. The hotel still sets its own money limits and decides who holds the second confirmation.

What to do next#

This month, write your own registry. List the ten actions software could take on your property, sort each one with the three questions, name the person who confirms it and the person who covers at night. Then ask a receptionist on the late shift to explain out loud what one confirmation screen will do before they click it. If they cannot, the screen needs work before the software does. If you want to see how one vendor sorted this problem, you can request a briefing at https://ai-otel.com/contact.