Generative AI explained for hoteliers: what it does with words

Generative AI is software that writes a likely continuation of the text it is given: it produces drafts, summaries and translations rather than looking facts up. In a hotel it is reliable for wording and summarizing, and it cannot know your availability, rates or guests unless it is connected to your own systems.

A reservations agent has an angry guest email on one screen and a chat window open on the other. The reply the tool produces is warm, fluent and wrong about the refund policy, and nothing on the screen says so. After reading this article you will have one mental model that explains what the tool did, why the error was invisible, and which hotel tasks you can safely hand to it today.

What is generative AI, in one paragraph?#

Generative AI is software that writes a likely continuation of whatever text it is given, one small piece at a time, instead of looking up a stored answer.

The model is built in advance from very large collections of text, and from that it holds a statistical sense of which word tends to follow which. The build step is what people call training; it happens before you ever type anything. When you give it a prompt, it produces the most plausible continuation, and plausible is not the same as true: nothing in that moment checks the sentence against reality.

It is not search. A search engine returns pages that already exist; a generative model produces new text that may or may not match anything real. It is not a database query either. A query returns the stored row; the model returns a sentence shaped like an answer. The same prompt can produce different wording on two runs, so treat every output as a draft rather than a fixed rule or a template.

The word "generative" covers text, images, audio and video. The hotel use case is almost entirely text, which is why this article stays with words. If you want the deeper mechanics, read why fluent is not the same as right in large language models.

Three things it is not#

First, it is not a fact checker: it has no internal step that verifies a claim before printing it. Second, it is not a memory of your business: your property's records were never part of its build. Third, it is not a template engine: a template produces identical output every time, while a generative model varies its wording, which is a strength in tone and a risk in facts.

What does generative AI do well in a hotel?#

It is strongest where a person can judge the result in seconds: drafting, summarizing, translating and rewording text the hotel already owns.

Drafting is the clearest win. A first version of a reply to a guest complaint, an email to a tour operator, a job posting, a paragraph for the website. The gain is that the blank page disappears, not that the final wording is finished. Summarizing works the same way: a long supplier contract, a set of terms, a pile of guest feedback reduced to themes. The summary is a map; for anything binding, the reader still opens the source document.

Translation and tone adjustment are dependable because a person can spot-check them. A fact sheet into German, or the same paragraph in a formal register for a corporate client and a warm one for a family booking. Rewording for a different reader follows the same logic: the same pool rule written once for staff, once for the guest app, once for the website.

Where it is weak is anything that needs a fact the hotel holds, a number, a commitment, or a legal statement. Ask it for a rate and you get a sentence that looks like a rate. A practical rule of thumb: if you can check the output in under a minute, it saves time. If checking takes longer than writing the text yourself, it does not save anything.

Where the time actually goes#

What can't generative AI know about your hotel?#

It cannot know tonight's availability, your rates, whether the pool is closed or who is in room 204, because none of that is in the text it was built from.

Those facts live in the property management system, the channel manager and the housekeeping list. The model has no door to them unless someone builds one. Asked anyway, it usually answers in the same confident tone. The sentence is shaped like a fact and is a guess, which is what people mean by hallucination.

The failure is quiet. There is no error message and no blank field, only plausible text that reads exactly like the correct answer would. The same applies to policy: it does not know your cancellation terms, your child policies or your check-in time unless they are placed in front of it in the same request.

Separate knowing the shape of an answer from knowing your answer. It knows what a cancellation policy usually contains; it does not know yours. The consequence for planning is simple: any guest-facing use needs the hotel's own records in the loop, not the model's impression of the industry. For how these invented facts arise and how to catch them, see why AI assistants invent hotel facts and how to catch them.

Answering versus acting: what changes when it is connected to hotel systems?#

Connecting the assistant to the hotel's own system turns a text generator into something that can look up a fact and, if you allow it, change a record, and that is a different kind of risk.

With read access, the assistant asks the hotel's system for availability or a bill and writes the result in plain language. The fact comes from the record; only the wording comes from the model. With write access, it can hold a room, move a charge or send a message. A wrong output is then an action rather than a paragraph, and actions reach guests and money.

Before granting write access, require four things: a defined list of operations it may perform, a limit per operation, a confirmation step for anything sensitive, and a record of what was done and on whose instruction. Confirmation can be tiered. Routine actions run directly, sensitive ones wait for a person, and the most sensitive wait for two. The tiers must be written down, not left to the tool.

Reversibility matters. A change to a record can usually be undone; a message already sent to a guest cannot, so sending deserves the strictest tier. And the assistant must be able to say it does not have the information. A system that always answers is not more capable, it is less trustworthy.

Read access and write access are not the same decision#

Read access is low-risk and high-value: it removes the guessing problem entirely, because the model stops inventing facts it can be given. Write access is a governance decision, not a technical one. Grant it operation by operation, starting with the ones that are reversible, and review the record of what was done at fixed intervals rather than when something goes wrong.

How should a hotel check a generative AI output?#

Check every output against the hotel's own records before it leaves the building, and treat that check as part of the job rather than an extra step.

Facts first: names, dates, times, prices, room types and what a rate includes. Open the system and compare; do not trust the paragraph because it is well written. Promises next: late checkout, a transfer, a refund, a free upgrade. Anything the hotel commits to must be something a manager can actually authorize.

Personal data deserves its own rule: do not paste guest names, identity details or payment information into a tool the hotel has not approved. Data protection duties follow whatever you type, wherever it goes. Register and language matter too: a translated reply can be accurate and still sound wrong to a German guest, so have a speaker of that language read it before it becomes a template.

When the text summarizes a document, keep the document open beside it and spot-check two or three claims. And keep a copy: for anything sent to a guest, retain the draft and the approved version, so a later question can be answered from the record. For what staff may and may not type into these tools, see what hotel staff may share with AI chat tools.

A five-minute check before anything is sent#

Who is responsible for what the AI writes to a guest?#

A named person at the hotel is responsible for every message that reaches a guest, whatever produced the first draft.

The tool carries no accountability. It cannot be asked why it promised a refund, and it will not remember the conversation the way a colleague would. Name an owner per channel: reservations replies, guest app messages, the booking-site inbox, social media. One name each, written down.

Separate drafting from sending. The person who presses send is the person who checked, and that should be the same person by rule, not by habit. Escalate by topic, not by length: complaints, refunds, safety questions and anything that sounds legal go to a manager, never straight from a draft.

Write the staff policy once: which tools are approved, what may be pasted into them, what never leaves the building. A rule nobody has read is not a rule. And start where a mistake is cheap: internal drafts and summaries first, guest-facing replies later, once the checking habit exists. The reasoning behind that order is set out in why a hotel should start with back-office AI before guest-facing AI.

What to do next#

Pick one internal task this week, a complaint reply or a contract summary, draft it with an approved tool, check it against your records and name the person who signs it off. The pieces fit in one line: the model writes likely words, so it is good at wording, blind to your records, risky once it can act, and always in need of a check and an owner.