Writing Your Hotel's AI Policy: Governance, Approval, and Acceptable Use

Your staff were using AI long before your board put it on an agenda. So a policy written now doesn't introduce anything. It writes down what's already happening, and for most properties that'll be the first honest inventory they've ever taken.

The Policy You Already Have Was Written By Your Staff

A front desk agent takes a two-paragraph complaint from a departing guest, pastes it into a chat window on her phone, and asks for a warmer apology than the one she would write at the end of a double shift. A revenue manager uploads a competitive set extract to summarise for the owner's call. A sales coordinator drops a corporate client's brief into a tool to generate a proposal outline. An HR coordinator, buried in applications for a housekeeping opening, asks an assistant to rank them.

Nobody here is being reckless. Each of them is doing the obvious thing with an obvious tool, usually faster and better than they'd manage without it. Between them they've also written your property's AI policy, one decision at a time, and nobody has read it.

The numbers are hard to argue with. In a June 2026 survey of 1,250 office professionals at large companies, two-thirds said they had used AI tools at work while believing their company's policy didn't permit it. Software AG's study of six thousand knowledge workers put shadow AI use at half of all employees, and UpGuard's 2024 surveys found executives had the highest levels of regular use. So it isn't a junior-staff problem. Against that, only 38% of organisations have a formal, comprehensive AI policy, according to ISACA's 2026 AI Pulse Poll. That's up from 28% in 2025, and it's still a minority governing a majority behaviour.

Hotels have three structural reasons to worry more than most, and none of them is a lack of diligence. The workforce is spread across a building, not a floor of desks, so there's no natural chokepoint where IT can see what software people use. Turnover in guest-facing roles is high enough that the policy has to survive onboarding, not institutional memory. And the data in front of the people most likely to reach for an assistant is exactly the data that must never go into a prompt: names, home addresses, passport and ID numbers, payment credentials, loyalty history, arrival patterns, and the accessibility and dietary notes that carry health information with them.

Meanwhile, 82% of hotel technology buyers in a Canary Technologies survey of more than 400 hotel, management company and brand respondents expect AI use to increase across their organisation within the next year. The gap won't close by itself.

A hotel without an AI policy does not have less AI. It has exactly the same amount of AI, distributed across personal accounts, invisible to the property, and governed by whatever each individual employee happened to assume was acceptable.

Four Exposure Classes, Not One

Policies fail when they treat AI risk as one thing. The controls for one class don't touch another. A tool register does nothing about employment discrimination, and a human-review rule does nothing about where a vendor stores data. Separate them first, because the drafting decisions follow from that.

Data exposure is the one everyone thinks of first: guest or employee information going into a system with training rights, indefinite retention or an unknown processing location. It's also the easiest to control, because the control is a rule about information, not a piece of technology. When it fails, the cost is measurable. IBM's 2026 report puts the global average breach at $4.99 million, a record, and the US average at $11.5 million. The same research found that one in four malicious breaches was AI-enabled, and those averaged $6.04 million against $5.03 million for the ones that weren't.

Decision exposure is the class that new law is aimed at. When an AI system makes or materially informs a decision about a person - who gets hired, who gets scheduled, who is asked for a deposit, who is flagged at check-in - a set of disclosure, explanation, and human-review duties attaches that do not apply to a tool summarising a report. Hotels touch this more often than they realise, because applicant screening, shift optimisation, and fraud or chargeback scoring all live here.

Commitment exposure is peculiar to hospitality and badly under-governed. An AI-drafted or AI-delivered statement can bind the property: a rate quoted in a chat, a cancellation fee waived in an automated reply, an allergy assurance in a pre-arrival message. Plan on the guest holding you to it. Arguing about whether the system was authorised is not a conversation you win with a guest.

Vendor and intellectual property exposure is the quiet one. Who owns the output. Whether the vendor indemnifies an infringement claim arising from it. Which sub-processors are in the chain, and whether the property is told when they change. Whether third-party licensed data - benchmarking extracts, brand material, photography - may lawfully be uploaded at all.

Everything else in a hotel AI policy is machinery for managing these four. The first piece of that machinery is a classification of the property's own data, because until the information is tiered, no rule about tools can be written precisely.

The tier table is a drafting instrument, not a training instrument. Nobody at a front desk will consult a four-row matrix at eleven at night. What they will retain is the single sentence the matrix compresses into: nothing that identifies a guest, an employee, or a payment goes into a tool that is not on the register. Write the table for the auditor and the sentence for the staff, and make sure they say the same thing.

The Regulatory Floor as of September 2026

Until recently an AI policy was a prudence exercise. That has changed, so it's worth being precise about what is actually enforceable now and what is still only proposed.

For hotels the biggest change is Article 50 of the EU AI Act, whose transparency obligations apply from 2 August 2026, with the European Commission publishing guidance on how to apply them. The rule is modest. A system that talks to people has to tell them they are dealing with AI from the first interaction, unless that would be obvious to a reasonably observant person. Formally the duty sits with the provider, which for most hotels means the vendor, but it's the hotel's name on the conversation. And the Act reaches providers and deployers outside the EU when a system's output is used in the Union, so a Colorado hotel whose booking assistant answers a traveller in Dublin should assume it is in scope. Fines run up to fifteen million euro or three percent of worldwide annual turnover, whichever is higher.

Closer to home, Colorado has been through a full cycle. The original Colorado AI Act was repealed and replaced by SB 26-189, signed on 14 May 2026, which moved the effective date from 30 June 2026 to 1 January 2027 and narrowed the statute to notice, adverse-outcome disclosure and human review around consequential automated decisions. The Attorney General released proposed rules on 11 August 2026 covering both the ADMT Act and a companion Chatbot Safety Act, both effective 1 January 2027, with a public hearing scheduled for 26 October. Lawyers reviewing them say the rules create considerably more operational work than the statutes suggest. California's privacy regulator, meanwhile, finalised its own automated decision-making technology regulations in September 2025.

On top of that sits the White House executive order of 2 June 2026, "Promoting Advanced Artificial Intelligence Innovation and Security," which one Hospitality Net columnist has translated into hospitality priorities around vendor strategy and data sovereignty. Then there's the NIST AI Risk Management Framework, which is voluntary but gives auditors, insurers and owners a shared vocabulary. Its four functions - govern, map, measure, manage - line up with the five-part policy below, and citing them costs nothing.

Two things about that calendar. Nothing on it asks a hotel to do anything exotic; every line comes down to a disclosure, a log or a human-review route. And the 1 January 2027 cluster means a policy drafted today and never revisited will be out of date within weeks. Put the review cadence in the document itself.

The Five-Part Policy

A workable hotel AI policy is five parts and about six pages. Length isn't a sign of seriousness here. It's a sign the document will go unread, which is the failure that matters most.

Part 1: Scope and definitions

One page. Define what counts as an AI tool in terms broad enough to capture what is coming, and be explicit that the definition includes features embedded in systems the property already owns. This matters more than it sounds. A property that carefully governs standalone chat assistants while its PMS quietly ships a summarise-this-guest button, its messaging platform adds suggested replies, and its review platform starts auto-drafting responses has governed the small half of its exposure. Scope should reach employees, contractors, agencies acting on the property's behalf, and any vendor processing property data with AI.

Part 2: The data rule

One page: the tier table, plus the one-sentence version, plus a short list of worked examples drawn from the property's own inventory. Examples do more work than definitions. "A guest complaint email contains the guest's name, so it is Tier 3 and does not go into a general tool; the same complaint, with identifying detail removed, is Tier 1" teaches the rule in a way that a definition of personal data does not.

Part 3: The approved tool register

Not an appendix. A living document, with an owner and a review date. Five columns are enough: tool name, business owner, highest data tier permitted, DPA and no-training status, next review date. The register is what makes the rest of the policy auditable, and it's the first thing a regulator, an insurer or a serious acquirer will want to see. Without a current register the policy is an assertion. With one, it's a control.

Part 4: Human review requirements

One page specifying where a named human must review before output leaves the property or affects a person. Four categories cover most properties: any guest-facing written communication above a defined threshold of consequence, anything affecting employment, anything affecting a guest's money, and anything published under the property's name. Name the reviewing roles. An instruction to exercise judgement is not a control and will not read as one to anybody assessing the property.

Part 5: The incident path

Define what an AI incident is - restricted data entering an unapproved tool, an AI-generated commitment the property cannot honour, an output that reached a guest and was materially wrong, a vendor disclosure - then route it into the incident process the property already runs rather than inventing a parallel one. Attach the same notification clock the property uses for any other data event.

Then add the clause that determines whether any of this functions: an employee who self-reports an AI incident is not disciplined for the incident. Without it, the property's only detection mechanism for the largest share of its exposure - personal devices, personal accounts, off-network - is a channel nobody will use. A property reporting zero AI incidents twelve months after publishing a policy has not achieved compliance. It has achieved silence.

The most valuable clause in a hotel AI policy is the one promising that an employee who reports pasting guest data into the wrong tool will not be disciplined for reporting it. Every other clause is enforceable only to the extent that one is believed.

The Approval Workflow, and Why It Has to Be Fast

Approval is where good policies go to die. A review queue measured in months is a prohibition with extra paperwork, and staff treat it exactly like one: they route around it. The goal is proportionality. Give the large volume of low-risk requests a fast path that really is fast, so the slow path keeps its credibility for the few that deserve it.

Route on two variables only: the highest data tier the tool will touch, and whether it makes or informs decisions about people. Everything else is noise at the intake stage.

Fast lane - 48 hours, decided by the GM or a designated technology lead. Tier 0 and Tier 1 data only, no personal information of any kind, no autonomous guest-facing output, below a defined spend threshold. Most requests should land here and clear in two days. Approval means addition to the register, not an exemption from it.

Standard review - 10 business days, GM plus owner representative or corporate IT. Tier 2 data, or guest-facing but non-binding output. Requires a completed vendor review gate and a named business owner willing to be accountable for the tool.

Full review - 30 days, adding privacy counsel and brand where a franchise agreement is implicated. Tier 3 data, any decision about people, any autonomous guest-facing action, or any tool that will hold a persistent copy of guest data. This is where the disclosure and human-review obligations arriving on 1 January 2027 get designed in rather than retrofitted.

Publish the service levels alongside the tiers. A workflow whose response time is unknown is treated as infinite, and the fast lane only does its job of preventing shadow adoption if people believe it is actually fast.

Implementation: Thirty, Sixty, Ninety

Days 1-30 - inventory under amnesty. Ask; do not audit. A single question to every department head: what are you and your team already using, and what for? The answers only arrive if it is credible that nobody will be punished for them, which means the amnesty has to be stated in writing before the question is asked and honoured without exception afterwards. Publish the resulting list internally without commentary. For most properties this document is the single most useful artefact of the entire exercise, because it turns an abstract governance problem into a short, specific list of tools. In parallel, draft the tier table against the property's real data, and name one accountable owner - at property level this is usually the GM or director of finance, not a corporate IT function three time zones away.

Days 31-60 - publish and provision. Issue version one of the policy: five parts, six pages, one memorable sentence. Stand up the register with the tools from the inventory that pass the vendor gate, and replace the ones that do not - replace, not merely prohibit, because a prohibition without a substitute reproduces the original problem. Run thirty-minute department briefings using real examples from the inventory rather than generic scenarios. Add the AI clause to vendor onboarding so the next contract arrives pre-screened.

Days 61-90 - instrument and schedule. Turn on AI disclosure in every guest-facing conversational surface and confirm the human escalation path works from the guest's side. Enable and retain logging wherever the vendor supports it. Fold AI incidents into the existing incident process. Then set the quarterly register review and anchor it to a date that already exists on the property's calendar - the PCI attestation is a good host, because it is one nobody skips.

If you want an outside read before the 1 January 2027 obligations land, it helps to assess the governance layer alongside the rest of the technology estate, not on its own. Our AI & Technology Scorecard and reporting service is built for that kind of standing review. The document isn't the point. Being able to answer, in one meeting, which tools touch guest data, who approved them and what happens when one is wrong: that's the point.

One further note for owners rather than operators. Where a brand or management company mandates AI tooling, the owning entity is generally still the controller of guest data, and controller status is where notification duties and regulatory liability attach. That is a negotiation to have at renewal, in the technology clauses of the management agreement, not in the aftermath of an incident.

The Five Ways This Goes Wrong

The blanket ban. Prohibition without provision doesn't reduce AI use. It moves it to personal accounts on personal devices, where the property has no visibility, no logs and no way to scope an exposure. Remember who the two-thirds in the PagerDuty survey were: people who believed their company's policy already didn't allow it.

The unread policy. Forty pages of definitions satisfies a risk committee and changes nothing on the floor. The operative test is whether a new hire in week two, holding a guest complaint with an open chat window, can state the rule. If not, the length actively hurt.

The approval bottleneck. A ninety-day queue for a thirty-dollar tool teaches the organisation that the process is not for them. Publish service levels and meet them, or accept that the register will drift away from reality.

The unmaintained register. A policy whose tool list was last touched eight months ago cannot answer the only questions that matter in an incident: what did we approve, for what data, and who owns it.

Treating it as a project, not a cadence. Article 50 arrived in August 2026. Both Colorado statutes land on 1 January 2027, and their implementing rules weren't final when the October hearing was scheduled. A document written once and filed is already ageing, which is why the review date belongs in the policy, not in somebody's intentions.

The properties that handle the next two years well won't be the ones with the most sophisticated AI. They'll be the ones that can produce a current tool register, a data rule staff can recite, and a log showing that when something went wrong, somebody said so. It's a modest bar.

Frequently Asked Questions