Hotel Guest Data Privacy and AI: A One Page Policy Template

A guest data and AI policy for an independent hotel fits on one page and answers seven questions: what we collect and why, what the AI can see and do, who can see what, how long we keep it, what vendors may do, what we tell guests, and what happens when something goes wrong. Below is the template, with a plain English line for each section and the rule behind it. The platforms in our guide to the best hotel AI concierge platforms will each hand you a data processing agreement; this is the policy you need before you can read one intelligently.

The stakes first, then the template. And one line that applies to the whole post: this is general information, not legal advice. The General Data Protection Regulation (GDPR) is summarized, not quoted in full; United States state laws such as California's differ; have counsel review the finished policy before it goes in the staff handbook.

Does a hotel need an AI policy?

Yes, the day an AI tool can read a guest's name, stay or message, which is the day you turn on AI chat. Most organizations have not caught up. IBM's 2025 Cost of a Data Breach report, produced with the Ponemon Institute, found that nearly two thirds of organizations lacked AI governance policies and that 13% had suffered a breach involving an AI model or application ^[3]. It put the global average breach cost at USD 4.44 million, down 9%, and the US average at a record USD 10.22 million, up 9%, with hospitality among the sectors where costs rose ^[3]. That is vendor research, but the direction is hard to argue with.

Regulators have also changed what they ask for. The Federal Trade Commission's December 2024 order against Marriott and Starwood, following three breaches that affected more than 344 million customers worldwide, requires a comprehensive information security program, a policy to retain personal information only as long as reasonably necessary, a link for US customers to request deletion, and a prohibition on misrepresenting data practices ^[4]. Read that list again. Retention limits and deletion on request are now what a regulator expects from a hotel company, not just encryption. A small property will never face an order like that, but the shape of the expectation is the same at any size.

What should the policy cover?

Seven sections, each with a heading a front desk agent could read aloud, a line on what to write, the rule it rests on, and an example. The table is the template. The sections that follow explain each row.

One page guest data and AI policy template for independent hotels, 2026. Example lines are starting points, not legal text. General information, not legal advice.

Section 1: what guest data do we collect and why?

List the data by type, and put a purpose next to every type. If a line has no purpose you can write in one sentence, do not collect it. That is GDPR Article 5 in plain words: personal data shall be collected for specified, explicit and legitimate purposes, and be adequate, relevant and limited to what is necessary ^[1]. Article 13 then requires that guests be told what you collect and why, at the point of collection ^[1].

For a hotel the list is shorter than it feels: name, contact details, stay dates and room, party size, booking channel, stated preferences, requests and problems and how they were resolved, and consent records. Two things stay off the list however convenient they seem. Children's details beyond what a booking requires (no names, birthdays or photos gathered through chat), and special categories such as health, religion or politics, except where a guest states a service need such as a dietary requirement, and then only for that purpose. The line between a preference a guest gave you and a trait you inferred is the whole subject of personalization without the creep factor, and it belongs in this section as a rule: we store what guests tell us, not what we guess.

Section 2: what can the AI see and do?

Write down exactly what the assistant reads and exactly what it never does, in a form a guest could be shown. At most properties today the honest list is three items: the property knowledge base (policies, menus, hours, local information), stay facts entered or imported (dates, room, party), and the conversation itself. It does not see payment card numbers, it does not read the property management system (PMS) directly where connectors are planned rather than live, and it does not decide anything with consequences for the guest without a person.

The UK Information Commissioner's Office updated its guidance on AI and data protection in March 2023 with chapters on accountability, transparency, lawfulness, fairness and automated decision-making, and it reads as a plain structure for this section even outside the UK ^[2]. Its transparency point is the useful one: a guest should be able to learn what the system does with their information without a law degree. The companion decision, what the assistant should refuse to answer and when it must hand off to a person, is covered in guardrails an AI concierge should have, and the two lists should be written together.

Section 3: who can see what?

Roles, least privilege, and a leaving date. GDPR Article 32 requires technical and organizational measures appropriate to the risk, and names confidentiality, integrity and the ability to restore access among them ^[1]. For a small hotel that translates into three questions: who needs to see a current guest's conversation (the desk and the duty manager), who needs history (managers), and who needs the admin screens (one or two named people). Everyone else sees nothing.

The part that gets forgotten is offboarding. Seasonal turnover is a fact of resort life, and a shared login that outlives the person who used it is the most common access failure I have heard described. Write the rule: individual accounts only, access removed on the last day, and a quarterly check of who still has what. If a vendor platform offers role-based access, the policy should say which role each job title gets.

Section 4: how long do we keep it?

A retention period per data type, written down, applied automatically where the system allows. The principle is Article 5(1)(e): personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which it is processed ^[1]. The regulatory mood is in the Marriott order, which requires retaining personal information only as long as reasonably necessary ^[4].

Example retention schedule for hotel guest data. The periods are examples for the exercise, 2026, not recommendations; set yours with counsel and your tax adviser.

The periods above are deliberately labeled examples. The point of the table is that every row has a number and a reason, and that someone has agreed to both.

Section 5: what may vendors do?

This section is the data processing agreement (DPA), translated. GDPR Article 28(3) requires that processing by a processor be governed by a contract that binds the processor to: process only on the controller's documented instructions; ensure persons authorized to process the data have committed to confidentiality; take the security measures required by Article 32; respect the conditions for engaging another processor; assist the controller in responding to data subject requests; assist with the obligations in Articles 32 to 36, including breach notification and impact assessments; delete or return all personal data at the end of the services; and make available all information necessary to demonstrate compliance and allow audits ^[1].

Then add the ninth item the article does not spell out, in writing: is our guest data used to train your models? Ask it in those words and insist on an answer in the contract, not in a sales call. General information, not legal advice, but this is the question I would never leave to a verbal assurance. A vendor's published terms are the place to start reading; our data processing agreement is the ResortConcierge AI version, and you should read your other vendors' with the same list in hand.

The sub-processor condition deserves its own line in your policy, because an AI platform almost always relies on other providers (hosting, a language model, messaging carriers). The contract should require the vendor to list them and notify you of changes, and our sub-processor list is an example of what that disclosure looks like when it is published.

Section 6: what do we tell guests?

Three things: the privacy notice, the AI disclosure line, and how to ask. Article 13 sets what the notice must say at collection, and Article 15 gives guests the right to access what you hold ^[1]. Your section should name the response target (five working days is a reasonable internal standard; the legal deadline where you operate may be longer or shorter) and the person who handles requests.

Guests reward clarity. Cisco's 2024 consumer privacy survey of 2,600 people in 12 countries found 59% more comfortable sharing information in AI applications where strong privacy laws exist, and 78% holding businesses responsible for using AI ethically ^[5]. Pew's 2023 survey of 5,101 US adults found 73% feeling little or no control over what companies do with their data ^[6]. A one paragraph notice a guest can actually read, and a staff member who can show them their profile on request, address both numbers directly. The AI disclosure line itself, where the law requires it and what the wording should be, is covered in whether guests should be told they are talking to AI; for this section, the rule is simply that the line exists and the property approved it.

Keep the notice where guests are: the booking confirmation, the first chat message, the room directory. A policy that lives only in our privacy policy style page nobody opens has told no one anything.

Section 7: what happens when something goes wrong?

Steps, a clock and a call list. GDPR Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of a personal data breach, unless the breach is unlikely to result in a risk to people's rights, and requires the processor to notify the controller without undue delay after becoming aware ^[1]. Other jurisdictions set other clocks. Your policy should name yours.

Incident call list template. Fill in names and numbers and keep a printed copy, 2026. General information, not legal advice.

Steps one and two matter most, because the 72 hours start when you become aware, and a hotel that does not know who to call loses the first day working it out.

Who owns the policy at a small hotel?

The general manager signs it, one named person maintains it, and it is reviewed twice a year or whenever a vendor changes. There is no compliance department to hand this to, and pretending otherwise is how it ends up unowned.

The maintainer does not need to be technical. They need to know where the policy lives, which vendors are on the list, when the last review happened, and how to pull a guest's profile when someone asks. At most properties that is the front office manager or the GM's second. A data protection impact assessment under Article 35 is required only where processing is likely to result in high risk to people's rights, so most independent hotels will not need one for a guest chat assistant, but the maintainer should know the question exists and ask counsel once ^[1].

I spent years in a field where a signed policy on a shelf and a policy people actually followed were two different documents. The difference was always the same: the second one was short, it was read aloud at a staff meeting, and someone's name was on it.

Where ResortConcierge helps

The general practice is a short policy the property controls and a vendor contract that matches it. For section 2, ResortConcierge answers only from the knowledge base the concierge answers from, stay facts and the conversation, so "what the AI can see" is a list the property writes and can show a guest.

For section 3, role-based access and security controls support the who-sees-what rules above, and the published data processing agreement and sub-processor list linked earlier give section 5 a starting point to compare against.

For sections 4 and 6, guest profiles hold stated preferences with their source and can be deleted on request by a staff member. Two honest notes: what any vendor does or does not do with training data is a contract question, and you should read the DPA rather than take a blog post's word for it; and PMS connectors are planned, not shipped, so today the assistant does not read the PMS directly.

Fill in the seven rows this week, in your own words, and have the GM sign the bottom. Then send section 5 to every vendor who touches guest data and ask them to confirm each line in writing. The ones who answer quickly and plainly are the ones you want to keep.