Technical consolidation and final framework text; AI-specific security, regulatory references, NIST mapping, vendor questions, agent data safeguards and practical examples, and the cited agentic-AI preprint.
Hospitality AI Governance Framework
A common, practical reference for hospitality organisations developing their own AI governance frameworks.
Includes free, reusable tools for each repeatable part of the workflow.
SegmentEnterprise · SMB/Independent · Vendor
AudienceOwners, executives, operators, technology leaders, legal, risk, HR, procurement, security and privacy teams
Operating levelCorporate
Framework at a glance
Overview
PURPOSE & VISIONEnable trusted AI innovation in hospitalityCLICK TO EXPLORE →DEFINITIONSDefining AI governance in hospitalityCLICK TO EXPLORE →GOVERNANCE PRINCIPLESThe foundation for how AI is governed.CLICK TO EXPLORE →GOVERNANCE FUNCTIONSWhat governance must do to function effectively.CLICK TO EXPLORE →AI GOVERNANCE LITERACYBuilding the knowledge to govern AI responsibly.CLICK TO EXPLORE →
AI GOVERNANCE FRAMEWORKStart with the five entry points, explore the pillars and open the capabilities, then apply the framework proportionately to your organisation’s size, risk and context. Within each pillar, capabilities define what the organisation needs to be able to do and the outcomes effective governance should achieve.
The framework is for enterprise and SMB/independent hospitality organisations at corporate level. Corporate teams establish policy, approval requirements, accountable ownership and operating expectations. Smaller organisations can keep the records and processes simpler; enterprise groups apply greater formality and coordination.
Purpose & vision
Hospitality organisations are rapidly embedding AI within their operations, leveraging AI systems and data-driven capabilities for strategic advantage. The competitive pressure to adopt AI is real, but adoption is moving faster than the industry’s ability to govern it consistently.
AIHA’s vision is for a hospitality industry that can adopt AI with confidence, innovate at pace and maintain human accountability, guest trust and the safe, fair and transparent use of AI.
This framework provides a common, practical reference for hospitality organisations developing their own AI governance frameworks. It is informed by widely recognised AI governance standards, frameworks and principles.1
HOW TO USE IT A starting path
|
HOW IT HELPS What each seat at the table gets
|
Definitions
2.1 AI governance in hospitality
AI governance is the system of roles, decision rights, processes, controls and evidence through which a hospitality organisation determines which AI systems may act in its name, for what purpose and under whose authority; keeps those systems within their approved limits throughout their lifecycle; provides appropriate transparency to people affected by them; ensures that any guest or employee affected by them can reach a human able to review and correct the outcome; and can demonstrate how they are governed to those who need to understand, oversee or challenge their use.
This definition includes agentic AI: systems that can plan, make decisions and take actions toward a goal with limited human intervention, such as agents that adjust pricing, respond to guests or complete bookings.2 Where an AI system can act rather than only recommend, governance should additionally define the scope of its delegated authority, the identity under which it acts, and the conditions under which its autonomy is expanded or reduced.
2.2 AI governance framework for hospitality
An AI Governance Framework in hospitality is a structured reference that sets out the governance capabilities a hospitality organisation should establish to direct, control and oversee the responsible use of artificial intelligence across its operations.
For each capability, the framework defines the outcomes that effective governance should achieve, including appropriate decision rights, accountability, processes, controls, oversight and evidence. It does not prescribe the organisational structures, policies, technologies or methods an organisation must use to achieve those outcomes.
The framework is designed to be applied proportionately, taking into account an organisation's size, ownership structure, operations, use of AI and the jurisdictions in which it operates. It does not replace an organisation's responsibility for its own implementation or for meeting the legal, regulatory and other mandatory requirements applicable to it.
An AI governance framework is therefore concerned with how an organisation governs AI, rather than simply with the technology itself or with whether a particular legal or regulatory requirement has been met. It is not itself a compliance framework, a risk management framework or an operational management framework, although it may establish governance expectations that support and oversee each of these areas.
2.3 The difference between compliance & governance
Compliance is the process by which an organisation identifies and meets the legal, regulatory and other mandatory requirements applicable to it.
Governance is the system through which an organisation directs, controls and oversees its use of AI, including how decisions are made, who is accountable, what controls are applied, how risks are escalated, and how oversight is demonstrated.
Effective AI governance therefore supports compliance but is broader than compliance. An organisation may meet a particular legal requirement while still having weak AI governance if it lacks clear accountability, decision rights, oversight or consistent processes for managing AI across the organisation.
2.4 The AIHA hospitality governance framework
The AIHA Hospitality AI Governance Framework is a voluntary industry reference that translates these governance expectations into a set of capabilities and outcomes relevant to hospitality. It provides a common language and reference point for organisations seeking to establish or strengthen AI governance, while leaving each organisation to determine the structures, policies, processes, technologies and methods appropriate to its circumstances and jurisdiction.
Governance principles and functions
Governance functions describe what governance does. Governance principles are what good governance must stand for while doing it.
3.1 Governance principles
Governance principles provide the foundational expectations that guide how an organisation governs AI. They establish the values and standards that should inform governance decisions, responsibilities, processes and controls, helping ensure that AI is governed consistently, responsibly and proportionately across any organisation, regardless of size, structure or operating model.
PRINCIPLE | DESCRIPTION |
|---|---|
ACCOUNTABILITY | Every AI system has a named accountable owner; accountability remains with the organisation whether AI is built, bought or embedded in a vendor system. |
PROPORTIONALITY | Governance effort matches the potential consequence and risk of the AI use. |
PURPOSE LIMITATION | AI is used only for its approved purpose; a material change in purpose is a new governance decision. |
TRANSPARENCY | People are given appropriate information when AI materially shapes what happens to them. |
CONTESTABILITY | A person materially affected by AI can reach a human who has the authority to review and correct the outcome. |
HUMAN OVERSIGHT | Human oversight is meaningful only where the person has the authority, information and time to intervene. |
CONTINUITY | Governance continues throughout the lifecycle as systems, vendors, data, law and operating circumstances change. |
DEMONSTRABILITY | Governance decisions, controls and actions are recorded so the organisation can demonstrate how an AI system is governed throughout its lifecycle. |
3.2 Governance functions
Governance functions are the fundamental activities through which an organisation directs, controls and oversees its use of AI. They translate the governance principles into action by establishing what must be identified, decided, assigned, operated, protected and evidenced across the AI lifecycle. Together, these functions provide the practical means through which the principles are applied consistently and proportionately across AI systems, regardless of the organisation’s size, structure or operating model.
FUNCTION | WHAT IT MUST ACHIEVE |
|---|---|
IDENTIFY | Know what AI the organisation has or uses, where it came from and what it does |
DECIDE | Determine which AI may be used, for what purpose and on what terms |
ASSIGN | Establish who has authority and who is accountable |
OPERATE | Ensure AI operates within its approved purpose and is monitored throughout its lifecycle |
PROTECT | Protect guests, employees, data and brand trust; ensure people affected can reach a human for correction or redress |
EVIDENCE | Demonstrate what was decided, who was responsible and how the system was governed |
AI governance literacy for hospitality
AI governance literacy is the knowledge and understanding people need to recognise, question, use, oversee and escalate AI appropriately. It is not about teaching people how AI models work technically. It is about enabling people to understand where AI is being used, what it is authorised to do, what data it uses, who is accountable, when human intervention is required, what must be reported, and how context changes risk.
4.1 Domains
The following eight domains define the core governance knowledge expected of people who approve, operate, use or oversee AI in a hospitality organisation.
DOMAIN OF KNOWLEDGE | WHAT PEOPLE NEED TO UNDERSTAND | WHAT THIS ENTAILS | HOSPITALITY EXAMPLES |
|---|---|---|---|
1. WHERE AI IS ALREADY PRESENT | AI is not limited to LLMs or generative AI. AI may enter the organisation without a deliberate decision to “buy AI”. The concept of shadow AI | Recognise AI embedded in existing software, introduced through vendors, brought in by employees, added through software updates, or contained in everyday consumer tools. Understand that shadow AI creates governance risk and why visibility is the starting point for governance. | ChatGPT used by staff to respond to emails; AI features added to Microsoft 365; dynamic pricing in revenue management; AI in CRM or PMS platforms; a marketing agency using AI to process guest information. |
2. WHAT AN AI SYSTEM IS INTENDED AND NOT INTENDED TO DO | Every AI system should have an approved purpose and defined operating boundaries. | Understand the system's intended purpose, approved users, permitted data, decisions it may influence and activities it is prohibited from performing. Recognise when use has expanded beyond the approved purpose. Understand that an AI system may have limitations, uncertainty or reliability constraints that affect whether it is suitable for a particular purpose or context. | A guest chatbot may answer questions about check-in times and restaurant hours, but should not approve refunds, waive cancellation fees or change reservation records. A marketing AI may draft content but not publish unreviewed legal or privacy claims. |
3. WHAT DATA IT USES AND WHO CAN ACCESS IT | AI governance requires visibility of what data enters a system, where it comes from, where it goes and who is responsible for it. | Understand data sources, data ownership, data lineage, access, vendor processing and traceability. Recognise the roles of the data steward, AI system owner, technical owner and vendor/procurement owner. | Guest reservation data moves from the PMS to the CRM, then to an AI personalisation tool. Employees should understand what information is used, who owns it, who can access it and whether a vendor can process it. |
4. THE DIFFERENCE BETWEEN AI OUTPUT AND AUTHORITATIVE SYSTEM STATE | AI-generated information is not automatically the organisation's authoritative system state or official business record. | Understand the distinction between model output - generated, predicted, inferred or recommended information - and the authoritative system state maintained by the organisation's designated system of record. Know when AI output must be verified. Understand that AI outputs may be inaccurate, incomplete, misleading or generated with unwarranted confidence, and should be interpreted in the context in which the system is being used. | A chatbot says a guest has a reservation, but the PMS shows none. The PMS prevails. An AI pricing system recommends a 15% rate increase, but the approved rate in the PMS/revenue system is the authoritative state. |
5. WHO IS ACCOUNTABLE FOR APPROVAL, OPERATION AND INCIDENTS | Accountability remains with people and the organisation; it cannot be transferred to the AI or vendor. | Understand accountability across the lifecycle: approval, operation, oversight, escalation and incident response. Recognise the different roles of the executive sponsor, AI system owner, business owner, technical owner and data steward. | An executive approves deployment of a guest chatbot; the AI system owner oversees it; Guest Experience owns operational outcomes; IT manages integrations; the data steward governs guest data; an identified owner coordinates an incident. |
6. WHEN A HUMAN MUST INTERVENE OR TAKE OWNERSHIP | AI may assist, recommend, predict or generate, but it cannot accept accountability or organisational authority. | Recognise when human review, approval, intervention or escalation is required. Understand human-in-the-loop, human-on-the-loop and human-out-of-the-loop oversight. Recognise situations where AI exceeds its purpose, uses unauthorised data, produces harmful or unexpected outcomes, or conflicts with authoritative records. Understand that human oversight should also consider fairness, bias, transparency and the potential impact of AI-assisted decisions on people. | A chatbot recommends a refund but a human approves it. AI may screen CVs, but humans make employment decisions. A revenue AI recommends pricing, but management decides. A chatbot conflicts with the PMS and staff verify the authoritative record. A recruitment AI consistently ranks candidates from one demographic group disproportionately lower than candidates from other groups. A human must not simply accept the recommendation; the outcome should be questioned, investigated and escalated where appropriate. |
7. HOW TO REPORT SHADOW AI, ERRORS, HARMFUL OUTCOMES OR SUSPECTED MISUSE | Governance depends on people surfacing concerns. If AI use or problems are not reported, they cannot be governed. | Recognise shadow AI, incorrect outputs, harmful outcomes, data concerns, suspected misuse and vendor changes. Know what to report, where to report it and what information will support investigation and remediation. | An employee uses a personal ChatGPT account for guest communications; a chatbot gives incorrect booking information; an employee uploads guest information to an unapproved tool; a vendor introduces a new AI feature without notification. |
8. HOW GUEST, EMPLOYEE, VENDOR AND JURISDICTIONAL CONTEXT CHANGES RISK | AI risk is determined not only by the technology but by how, where and on whom it is used. | Understand how guest impact, employee impact, data sensitivity, vendor involvement, jurisdiction, property characteristics and deployment scale affect the level of governance, oversight and accountability required. Understand that risk can change after deployment when the system, data, vendor, users, purpose, scale or operating environment changes, and that governance may therefore require reassessment. | A chatbot answering restaurant hours at one boutique hotel may present relatively limited risk. The same technology handling reservations and loyalty information for a global hotel group across multiple jurisdictions creates significantly greater governance requirements. |
4.2 The governance literacy test
A governance-literate person does not need to be able to explain how an AI model works technically. They should be able to answer the governance questions that matter:
The objective is not technical expertise. It is the ability to recognise AI, understand its governance boundaries, make informed decisions, identify concerns and escalate appropriately.
THE HEART OF THE FRAMEWORK The questions to ask about any AI in your business
Ask them of any system, any vendor, any property, at any level of the organisation. A hotel that can answer them all, and show the evidence, is governed. That is the whole test. |
4.3 Core competency outcome
A governance-literate hospitality organisation is one in which people can recognise AI wherever it appears, understand its approved purpose and boundaries, understand the data and accountability involved, distinguish AI output from authoritative business records, know when human oversight is required, report concerns and understand how context affects AI risk.
Governance framework pillars
Within each pillar, capabilities define what the organization needs to be able to do and the outcome effective governance should achieve.
PILLAR 1: AI SYSTEMS, RISK & ACCOUNTABILITY
PILLAR 2: PEOPLE, GUESTS & WORKFORCE
PILLAR 3: DATA, SECURITY & ASSURANCE
PILLAR 4: VENDORS, TECH STACK, PROCUREMENT & AI LIFECYCLE
PILLAR 5: AI AGENTS AND HOSPITALITY ECOSYSTEM
Risk & accountability
Pillar 1: AI systems, risk & accountability
An organisation cannot govern AI effectively without knowing what AI systems it has, understanding the risks associated with their use, keeping those risks under review, and assigning clear accountability and decision rights. This pillar establishes the foundations for identifying, assessing and overseeing AI systems and ensuring that appropriate authority and accountability are assigned throughout their lifecycle.
1.1 Know what you have
The organisation should maintain a current register of AI systems and uses across the organisation. The register should cover AI deliberately purchased, embedded in existing platforms, introduced through updates or vendors, and used by staff, including shadow AI.
REGISTER AREA | DETAILS |
|---|---|
Identity & purpose | System, vendor/model chain, business purpose, environment, approved and prohibited uses. |
Ownership & people | Business owner, accountable system owner, technical owner, affected guests/employees. |
Data & location | Sources, sensitivity, retention, processing/hosting jurisdictions, downstream recipients. |
Risk & approval | Risk tier and rationale; approval, conditions, review date. |
Control & exit | Monitoring, intervention/shutdown path, version history, material-change triggers, exit plan. |
Shadow AI is governed through visibility and a practical reporting/remediation route, not prohibition alone. A staff member who discloses an unapproved tool should trigger assessment, not automatic blame.
1.2 Assess & classify risk
Risk is a property of the use, not the tool. Classify each AI use case against evidence and record the rationale. Six factors drive the tier: autonomy, impact, data sensitivity, reversibility, realistic human oversight, and scale/reach.3
The organisation should consider whether AI is appropriate and necessary for the intended purpose, taking account of the expected benefits, risks, alternatives and ability to govern the use effectively.
TIER | USE PROFILE | MINIMUM GOVERNANCE | HOSPITALITY EXAMPLES |
|---|---|---|---|
0 - Assistive | Internal drafting or analysis; approved data; no external action; meaningful human review; low consequence. | Register; named owner; acceptable-use and data controls; incident reporting. | • Marketing staff using ChatGPT to draft social media post ideas before review • A manager using AI to summarise internal meeting notes • Housekeeping using AI to draft an internal shift-handover summary |
1 - Controlled | Low-to-moderate consequence; bounded guest/staff assistance; reversible outcomes; reliable supervision. | Documented assessment; testing; monitoring; role-based oversight; vendor review; escalation. | • A guest-service chatbot answering routine questions like check-in times or spa hours • AI drafting first-pass responses to guest reviews, reviewed before posting |
2 - Material impact | Material guest/employee, financial, access, eligibility, pricing or service impact; or significant personal data. | Formal approval by the designated accountable authority; cross-functional challenge; stronger testing/logging; human intervention; transparency/contestability; periodic review. | • AI-generated dynamic pricing recommendations feeding into room rates • AI-assisted interview scheduling in HR • AI staff rostering and scheduling • AI influencing loyalty status changes or guest eligibility decisions |
3 - High consequence | High potential consequence, significant autonomy, difficult-to-reverse outcomes, significant safety, security, privacy, biometric or highly sensitive data or other material impact. | Default: do not deploy until necessity, appropriate legal/ethical review, robust controls, executive approval, continuous monitoring, suspension capability and independent assurance are demonstrated, with effective suspension capability. | • Facial recognition used for guest or staff identification and access • Emotional recognition (visual and voice) • An autonomous agent authorised to issue refunds or compensation without human sign-off • AI-driven access control tied to safety and security systems across a portfolio • An AI tool screening and ranking job candidates |
The tiers are not static, and the same product can move between tiers when its purpose, permissions, data, integration or context changes.
For AI systems capable of autonomous action, the assigned tier should set the ceiling for autonomy while the autonomy actually granted is earned progressively. A newly deployed system should operate under appropriately heightened human supervision during initial deployment, with operating latitude expanded only as it demonstrates reliable behaviour in production. Autonomy is reduced or withdrawn when incidents, material changes, or degraded performance occur, in either direction or at any time.
1.3 Risk reclassification review triggers
An AI system’s risk classification should be reviewed whenever circumstances arise that may materially affect its risk profile, and the system should be reclassified where the review determines that its existing classification is no longer appropriate.
- Vendor model or version change
- Material change in scope, data, autonomy, or affected population
- Regulatory change affecting the system or jurisdiction
- Incident, near-miss, or complaint pattern
- Scheduled periodic review appropriate to the system's risk and use.
- Changed permissions, expanded autonomy or delegated authority
- Expanded purpose or new use case for existing system
- New jurisdiction or changed affected population
- Material change in system performance, behaviour, accuracy or reliability
1.4 Assign accountability & decision rights
A hotel can buy or outsource its AI technology, but it remains accountable for how that AI is used and for its impact on guests, employees and the business. Every AI system must therefore have a clearly designated accountable person or organisational role within the organisation, supported by clearly defined decision rights and responsibilities.
ACCOUNTABLE PERSON / ROLE | DEFINITION | ACCOUNTABLE FOR |
|---|---|---|
Executive sponsor | Senior person with authority to support, approve or reject significant AI decisions. | Risk appetite, resources and approval of Tier 3 AI uses. |
AI system owner | Person accountable for the AI system throughout its organisational lifecycle. | Approved purpose, risk, performance, lifecycle and overall accountability for the AI system. |
Business / process owner | Person accountable for the business process in which the AI is used. | Workflow fit, guest/employee impact, adoption and fallback arrangements. |
Technical owner | Person responsible for the technical implementation and operation of the AI system. | Architecture, identity, integration, testing, security and technical change control. |
Data steward | Person responsible for the appropriate management of data used by the AI system. | Data source, purpose, quality, access, retention and correction. |
Security / privacy / legal | Specialist functions providing review and advice within their respective areas. | Specialist review, assurance and advice within their remit; does not replace system ownership. |
Vendor / procurement owner | Person responsible for managing the organisation’s relationship with the AI vendor or provider. | Vendor due diligence, contractual controls, service levels, change notification and exit arrangements. |
Property accountable manager | Person with operational authority for the property’s use of AI. | Local operating conditions, staff readiness, escalation and authority to suspend use where necessary. |
Each organisation should designate the authority responsible for approving Tier 2 + AI uses.
1.5 Group, brand, franchise and property reality
Where AI is governed across a group, brand, franchise or individual property, decision rights should be clearly allocated between the entities involved. Corporations may establish policy, risk tiers, approved vendors and high-tier approval requirements, while properties retain responsibility for local implementation, operating conditions, staff readiness, guest and employee issues, and emergency suspension. Approval at one property does not automatically authorise the same AI use across other properties or the wider group.
People & oversight
Pillar 2: People, guests & workforce
AI can affect people directly or indirectly, including through decisions, communications, recommendations and workplace processes. Organisations should ensure that AI is used transparently, fairly and responsibly where it affects guests, employees or other individuals, with appropriate human oversight and meaningful opportunities to question, correct or challenge AI-influenced outcomes.
2.1 Transparency
Transparency is the provision of appropriate information about the use and role of AI so that people can understand when AI materially affects them and what avenues are available for human review or challenge.
AI-generated guest communications, review responses and marketing should meet the same standards of accuracy and honesty expected of human-generated content. Where the nature or context of the content could reasonably lead people to believe it was created by a human, appropriate disclosure or labelling should be provided.
People are given appropriate notice about how AI is used and, where consent is required, consent is obtained for the specific use of their data. Consent should not be assumed simply because a person has provided their data for another purpose.
2.2 Fairness
AI systems that make or materially influence decisions affecting guests or employees are assessed for bias, discriminatory patterns and other unfair or unjustified outcomes before deployment and at appropriate intervals thereafter, taking account of the nature, scale and risk of their use.
AI used in recruitment, scheduling, monitoring, performance management or other employment-related processes should receive governance proportionate to its potential impact on employees. Employees should be appropriately informed where AI materially influences decisions affecting them and should have a meaningful opportunity for human review or challenge.
Where AI interacts with people who may be particularly vulnerable to harm, additional safeguards, human involvement or restrictions should be applied proportionately to the circumstances.
2.3 Human oversight
Human oversight means ensuring that a person with appropriate authority, competence and context can understand, monitor, question and, where necessary, intervene in AI-supported decisions or actions. The level of human involvement should be proportionate to the potential impact and risk of the AI use.
Human oversight may operate at different levels:
- Human-in-the-loop: A human reviews or approves the AI output before a decision or action is taken.
- Human-on-the-loop: A human monitors the AI system and can intervene, override or stop it, when necessary, without reviewing every output.
- Human-out-of-the-loop: The AI operates without routine human intervention. This should only be appropriate where the consequences of autonomous operation are sufficiently low and the system remains within approved boundaries.
Human oversight must be meaningful, not nominal. A person should have sufficient information, authority, time and competence to question or override the AI. Human review should not become rubber-stamping, where a person routinely accepts AI recommendations without meaningful consideration.4
Human oversight is particularly important where AI can materially affect a person's rights, opportunities, access to services, employment, safety, privacy or experience, or where errors could cause significant harm. The organisation should define in advance when human intervention is required, who is responsible, what they are expected to consider, and when a decision must be escalated, overridden or stopped.
2.4 Contestability & redress
People affected by an AI-influenced decision or outcome have a meaningful opportunity to question or challenge it and, where appropriate, obtain human review.
An affected person can reach a human with the authority, competence and information necessary to review the AI-influenced outcome and, where appropriate, correct, reverse or provide redress for it while it still matters.
The organisation should provide clear routes for raising concerns and define how challenges are considered, escalated and resolved. The process should be proportionate to the impact of the AI use.
2.5 Workforce & acceptable use
Employees should be given practical guidance on the responsible use of AI in their work. The organisation defines which AI tools and uses are approved, what information may be entered into AI systems, when human review and verification are required, and what uses are prohibited or restricted.
The organisation maintains reasonable controls to identify and manage shadow AI, including the use of unapproved AI tools, personal accounts, AI features embedded in other software and independently deployed AI agents. Employees should know how to raise or disclose the use of an AI tool or use case that has not yet been approved without fear of automatic reprimand or penalty, so the organisation can assess, manage and, where appropriate, bring that use within its governance arrangements.
Employees are encouraged to surface rather than conceal AI use. Asking whether an AI use is acceptable, reporting an unapproved use or seeking guidance should be treated as part of responsible AI use, while deliberate misuse or disregard of established safeguards remains subject to appropriate accountability.
Data, security & assurance
Pillar 3: Data, security & assurance
AI systems depend on data and connected technologies, creating governance responsibilities for how data is used, how systems are protected, how performance and controls are tested, and how governance can be demonstrated. This pillar establishes the safeguards needed to ensure that AI operates securely, uses data appropriately, remains within its approved boundaries, and can be appropriately challenged, interrupted or corrected, with important governance decisions, actions and outcomes evidenced in a manner proportionate to risk.
3.1 Data stewardship
Data stewardship is the responsible governance of data used by AI systems throughout its lifecycle, establishing what data may be used, for what purpose, under whose authority and subject to what safeguards, including how data is classified, accessed, protected, transferred, retained and disposed of in accordance with its sensitivity and applicable requirements.
Where AI is used for pricing, revenue management or other commercially sensitive decisions, the organisation should understand what data informs the AI and ensure that competitively sensitive information is not used or shared in ways that create inappropriate exposure or undermine fair competition.
STEWARDSHIP AREA | WHAT IT COVERS |
|---|---|
Data classification | Classify data according to sensitivity and applicable organisational requirements, such as Public, Internal, Confidential and Restricted. |
Purpose & permitted use | Define why data is being used by the AI system and ensure it is not repurposed beyond its approved purpose without appropriate authority and, where required, a new lawful basis or consent. |
Data minimisation | Use only the data necessary for the approved AI purpose. Avoid unnecessary collection, exposure or retention of guest and employee information. |
Data access & permissions | Define who and what may access data used by the AI system, including AI agents, applications, employees and vendors. |
Data quality & provenance | Understand where data comes from, whether it is reliable and appropriate for the intended use, and how it moves through connected systems. |
Cross-border data flows | Identify where data is processed, stored or transferred and understand the jurisdictions and requirements that apply. |
Vendor & training-data use | Establish whether vendors may access, retain, reuse or use hotel data to train or improve their models, and ensure that this is governed through appropriate contractual and organisational controls. |
Retention & deletion | Define how long data may be retained and how it is deleted or otherwise disposed of when it is no longer required. |
Sensitive & prohibited data | Establish enhanced controls or prohibitions for particularly sensitive data, including payment information, credentials and biometric data*, according to the organisation's policies and applicable requirements. |
Vulnerable individuals | Apply additional safeguards where AI interacts with vulnerable people, including minors and guests in distress. |
Cross-customer data use | Whether recommendations, prices, or models are informed by non-public data from other customers, including competitors, and how such data is segregated. |
*Biometric AI: Where biometric identification or verification is used for guests or employees, it should operate under explicit consent with defined retention and destruction arrangements consistent with applicable requirements, a non-biometric alternative should remain available, and emotion recognition should not be used in relation to employees. Biometric uses are assessed at the highest applicable tier.
3.2 Security
Security is the protection of AI systems, their data and connected environments against unauthorised access, misuse, compromise and unintended actions. AI systems should be subject to security controls proportionate to their risk and function, including identity, access, integration and misuse controls.
SECURITY AREA | MINIMUM EXPECTATION |
|---|---|
Identity & access | AI systems are subject to the organisation's normal identity and access controls, with permissions appropriate to the system's risk and function. |
System & integration security | AI systems and their integrations are protected against unauthorised access, misuse and compromise. |
Data security | Data accessed or processed by AI is protected in accordance with its sensitivity and applicable security requirements. |
Misuse & abuse | Controls address foreseeable misuse of the AI system, including unauthorised actions or attempts to manipulate system behaviour. |
Adversarial behaviour | Higher-tier guest-facing systems are tested against deliberate attempts to produce unsafe, inappropriate or unintended outcomes, including prompt injection where relevant.5 |
3.2.1 AI-specific security considerations
In addition to the expectations above, the following AI-specific considerations apply proportionately to the system’s tier and function.6
AI-SPECIFIC AREA | WHAT IT SHOULD COVER |
|---|---|
Agent & model credentials | AI systems and agents authenticate with their own scoped, revocable credentials; shared or human credentials are not used for AI access. |
Prompt & input handling | Untrusted input (guest messages, documents, web content) is treated as potentially adversarial; systems resist instruction injection and do not reveal hidden instructions, credentials or other users’ data. |
Output handling | AI output that can trigger actions (links, commands, transactions, records) is validated before execution; downstream systems do not implicitly trust AI output. |
Data leakage prevention | Controls limit exposure of guest, employee and commercial data through prompts, context, logs, caches or vendor training; sensitive data is excluded or masked where not required. |
Least-privilege integrations | AI integrations with PMS, CRS, payment, loyalty and messaging systems follow the organisation’s existing least-privilege and access-management disciplines, with scoped tokens and segregated environments. |
Security monitoring | AI-relevant security events (unusual access, injection attempts, abnormal agent behaviour, unexpected data egress) are logged and monitored proportionate to tier through the organisation’s existing security monitoring arrangements. |
Vendor security posture | Vendor security controls, certifications, vulnerability management and incident practices are assessed for AI services as for other critical systems (see Pillar 4). |
Model & component provenance | The organisation can confirm that the model, components and plugins running in production are the ones that were assessed and approved, and that unapproved changes are detected. |
Knowledge & training data integrity | Sources that train the AI or feed its answers, including knowledge bases it retrieves from, are controlled, and unauthorised changes to them can be detected. |
Action authorisation | Where AI can call tools or take actions, each action is checked at the moment it happens against what that use is permitted to do, not only at initial setup. |
Usage & cost limits | Limits prevent an AI system from being driven into unbounded usage, load or cost, whether through abuse or through its own looping behaviour. |
Session separation | One guest’s or user’s conversation, data and cached responses cannot appear in another’s session on shared AI infrastructure. |
Common adversarial techniques against AI systems are catalogued in MITRE ATLAS and the OWASP Top 10 for LLM Applications (see Sources and References).
3.3 Testing & assurance
The organisation should be able to establish that an AI system operates as intended, remains within its approved boundaries and can be appropriately challenged, interrupted or corrected.
ASSURANCE AREA | MINIMUM EXPECTATION |
|---|---|
Intended behaviour | Test whether the AI performs its approved function reliably and within its defined purpose and boundaries. |
Edge cases & failure | Test foreseeable edge cases, failure modes and recovery arrangements in the actual hospitality environment. |
Human intervention | Test whether required human intervention, escalation, override and shutdown mechanisms work as intended. |
Fairness & impact | Test for unfair or harmful outcomes where relevant to the AI system's use and affected population.7 |
Monitoring | Establish appropriate monitoring to identify material degradation, unexpected behaviour or emerging risks after deployment. |
Assurance | Obtain an appropriate level of independent or cross-functional challenge for higher-risk systems. |
3.4 Evidence & auditability
The organisation should be able to demonstrate what was decided, who decided it, what controls were applied, what happened and how issues were addressed, without having to reconstruct the governance history after the fact.
EVIDENCE AREA | MINIMUM EXPECTATION |
|---|---|
Governance records | Relevant records should evidence the AI system's registration, risk classification, approval, conditions and accountable owner. |
Testing & assurance records | Testing, validation, review and assurance activities should be documented at a level proportionate to risk. |
Operational records | Above Risk Tier 0, relevant operational records and logs should be available without reconstructing events after the fact. |
Vendor evidence | Where available, vendor log export and relevant assurance information should form part of the governance arrangements. |
Incident & review records | Material incidents, near-misses, complaints, reassessments and resulting actions should be recorded. |
Retention | Governance records should be retained for a period appropriate to the AI system's risk, use and applicable organisational and regulatory requirements |
Vendors & lifecycle
Pillar 4: Vendors, tech stack, procurement & AI lifecycle
Hospitality organisations increasingly rely on vendors and technology providers to deliver AI capabilities embedded within the systems used to operate their businesses. AI may therefore enter a hotel through procurement, existing software, vendor updates, integrations or third-party services, without the organisation directly developing or controlling the underlying AI. This creates governance dependencies and risks relating to vendor transparency, data use, security, system performance, contractual accountability, changes to AI functionality and the organisation's ability to intervene when something goes wrong.
Organisations should therefore govern AI throughout its lifecycle, including how AI is procured and provided by third parties, how it is deployed and operated within approved boundaries, how changes and incidents are managed, and how systems can be suspended, replaced or retired. Reliance on a vendor does not transfer the organisation's accountability for how AI is used or for its impact on guests, employees and the business.
4.1 Procurement & vendor governance
The organisation should assess whether a vendor and its AI services are appropriate for the proposed use before procurement and should govern the resulting risks and dependencies throughout the vendor relationship.
GOVERNANCE AREA | WHAT IT SHOULD COVER |
|---|---|
AI functionality & purpose | What AI functionality the vendor provides, where it is used, what it is intended to do, what decisions or actions it may influence, and whether AI is embedded within a broader product or service. |
Vendor transparency | Appropriate information about the AI, including relevant model or provider dependencies, capabilities, limitations, known risks and material changes to functionality. |
Purpose & boundaries | The approved purpose of the AI, permitted uses, prohibited uses, operating boundaries and any restrictions on autonomy or actions. |
Data access & use | What guest, employee and operational data the vendor receives, why it is required, where it goes, who can access it and whether it is shared with other parties. |
Data retention & deletion | How long data is retained, including prompts, inputs, outputs, logs and other AI-related records; whether retention can be controlled; and whether data can be securely deleted when no longer required or when the relationship ends. |
Data subject / individual rights | Whether the vendor can support the organisation in responding to applicable access, correction, deletion, restriction, objection, portability or other individual rights requests, including locating and retrieving relevant data. |
Training & secondary use | Whether hotel, guest or employee data, prompts, inputs or outputs may be used to train, improve or otherwise develop the vendor's models or services. |
Data location & transfers | Where data is stored and processed, including relevant jurisdictions, cross-border transfers, subprocessors and onward transfers. |
Security | Appropriate technical and organisational security controls, including identity and access management, authentication, data protection, system security, logging, vulnerability management and controls appropriate to the AI system's risk. |
Incident notification & response | Vendor responsibilities for identifying, containing and reporting security, privacy, AI or operational incidents, including appropriate notification timeframes and information needed by the organisation to respond. |
Performance & assurance | Evidence that the AI operates as represented, including relevant testing, assurance, certifications, performance information, known limitations and material failures. |
Human intervention & control | The organisation's ability to review, override, suspend or stop the AI where necessary, and the vendor's responsibilities for supporting intervention and correction. |
Subcontractors & dependencies | The parties and technologies on which the AI service depends, including model providers, cloud providers, subprocessors and other critical third parties, and how changes to those dependencies are governed. |
Contractual accountability | Clear allocation of responsibilities between the organisation and vendor for data, security, performance, incidents, human oversight, regulatory support and other governance obligations. Reliance on a vendor does not transfer the organisation's accountability for its use of AI. |
Change notification | How and when the vendor must notify the organisation of material changes to models, functionality, data processing, hosting, subprocessors, autonomy, security or other characteristics that could affect the AI's risk or approved use. |
Audit & assurance rights | Appropriate rights to obtain information, assurance evidence and, where proportionate, audit or otherwise verify the vendor's compliance with agreed requirements. |
Data return & portability | The organisation's ability to retrieve or export its data in a usable form and migrate it where necessary. |
Exit & termination | Arrangements for termination of the vendor relationship, including transition support, data return, migration or deletion, revocation of access, removal of integrations and dependencies, and confirmation that the vendor no longer retains or processes the organisation's data where deletion is required. |
4.1.1 Vendor red flags
Risk Tier 2 and Risk Tier 3 procurement should be paused, slowed or escalated where the vendor:
- cannot identify the AI, model or provider chain behind the service (the level of disclosure may be subject to IP, privacy and contract terms);
- cannot clearly explain how organisational data is used, retained or deleted;
- cannot provide adequate information about material changes, incidents or relevant assurance; or
- cannot provide appropriate means of human intervention, suspension or exit.
4.1.2 Vendor questionnaire
A practical short-form question set that operationalises the governance areas above is provided at Appendix C. Record the answers as part of the AI Vendor Due Diligence Record.
4.2 Deployment & operational control
AI systems should be deployed and operated in accordance with their approved purpose, risk classification, permissions and operating boundaries. The organisation should ensure that the controls, human oversight, data arrangements, integrations and escalation mechanisms established during approval are implemented effectively in the live operating environment. AI should not be deployed with greater authority, access, autonomy or scope than has been approved, and operational teams should have clear procedures for monitoring its use, intervening when necessary and suspending or reverting to an appropriate human or manual process when the system cannot operate safely or reliably within its approved boundaries.
4.3 Monitoring & operational oversight
AI systems should be monitored throughout their operation to identify material changes in performance, reliability, behaviour, usage or risk. Monitoring should be proportionate to the system's risk, purpose and level of autonomy and should provide sufficient visibility to identify unexpected or harmful outcomes, operation outside approved boundaries, degradation or emerging risks. The organisation should define what is monitored, who is responsible for reviewing it, what thresholds or events require escalation, and when the system should be restricted, suspended, reassessed or subject to human intervention. Monitoring should continue after deployment and should not rely solely on the vendor's monitoring or assurances where the organisation remains accountable for the AI's use and impact.
4.4 Incident & response
Organisations should have appropriate arrangements to identify, report, assess and respond to AI-related incidents, errors, harmful outcomes and near misses. This should include clear responsibilities and escalation routes for incidents involving AI systems, vendors, data, security, unauthorised actions or material impacts on guests, employees or the business. Incidents should be contained and addressed promptly, with appropriate human intervention, suspension or restriction of the AI system where necessary to prevent further harm. Material incidents, near misses and other significant errors or unexpected events should be reviewed proportionately to understand their cause and impact and to determine whether changes to the AI system, controls, risk classification or operating arrangements are required.
4.5 Change management
Changes to an AI system should be identified, assessed and controlled throughout its lifecycle. This includes changes to the system's purpose, model or version, data, permissions, integrations, autonomy, affected population, vendor, operating environment or other characteristics that could materially affect its risk or approved use. Changes should be assessed for their impact on the existing governance arrangements and, where appropriate, trigger additional testing, risk reclassification, new controls or reapproval before implementation. The organisation should maintain appropriate change records and ensure that material changes can be rolled back, suspended or otherwise controlled where they produce unexpected or unacceptable outcomes.
4.6 Continuity, retirement & exit
AI systems should have defined arrangements for continuity, suspension, retirement and exit from the point at which they are deployed. Organisations should ensure that critical processes have appropriate fallback arrangements where an AI system becomes unavailable, unreliable or unsafe, and that authorised people can suspend or stop its operation when necessary. When an AI system is retired, replaced or the organisation exits a vendor relationship, the organisation should manage the transition in a controlled manner, including the return, migration or deletion of data, withdrawal of access and permissions, removal of integrations and dependencies, preservation of required governance records, and confirmation that the system and associated services are no longer operating on the organisation's behalf. Replacement systems should be subject to their own governance assessment and approval rather than automatically inheriting the approval of the retired system.
Agents & ecosystem
Pillar 5: AI agents and hospitality ecosystem
AI agents can increasingly act in roles that were previously performed by people, including searching, evaluating options, making or recommending decisions, communicating, negotiating, booking, purchasing and taking other actions on behalf of an individual or organisation. This changes the nature of AI governance because an AI system may no longer simply produce an output for a person to consider; it may exercise delegated authority and act within a business or transactional environment.
Hospitality organisations therefore need to govern both AI agents acting on their behalf and AI agents acting on behalf of guests, partners, vendors or other external parties. An organisation's own agents may interact directly with people, systems, vendors and other AI agents, while external agents may interact with the organisation's booking, pricing, service or other operational systems as a substitute for human decision-making.
Organisations should establish clear governance over agent identity, delegated authority, permissions, boundaries, actions and accountability, including how authority is granted, limited, monitored and withdrawn. Where agents interact with other agents or automated systems, the organisation should ensure that identity and authority remain attributable and that an agent cannot acquire greater authority merely through delegation or interaction with another agent. AI-to-AI interaction should therefore remain within defined governance boundaries, with appropriate mechanisms to detect unexpected behaviour, escalate decisions, require human intervention where necessary, and interrupt or stop agent activity that exceeds its authorised role.
The fundamental governance question is not simply what an AI agent can do, but what it has been authorised to do, on whose behalf, within what boundaries, and with what consequences if it acts incorrectly.8
5.1 Identity → Who/what is acting?
5.2 Delegated Authority → What has the organisation authorised it to do?
5.3 Permissions & Boundaries → What technically constrains what it can do?
5.4 Internal Oversight → How does the organisation remain in control?
5.5 Inbound Agents → How does the hotel deal with an external agent?
5.6 AI-to-AI / Ecosystem Interaction → How do we prevent the interaction between agents from creating authority, actions or consequences that neither agent was individually authorised to create?
5.7 Data Collection & Disclosure → What may be accepted from, or disclosed to, an agent?
5.1 Agent identity
Where an AI agent can take actions on behalf of the organisation or within organisational systems, it should operate under a distinct, identifiable non-human identity that allows its actions to be distinguished from those of human users and attributed to the agent and the authority under which it is operating. Agent identities should be authenticated, subject to appropriately scoped and revocable permissions, and maintained across interactions with organisational systems, people and other AI agents. The organisation should be able to determine which agent acted, on whose behalf it acted, what actions it took and under what authority, with sufficient records to trace its decisions and actions. Agent access should be capable of being restricted, suspended or revoked without unnecessarily affecting human access to the underlying systems.
GOVERNANCE AREA | WHAT IT SHOULD COVER |
|---|---|
Distinct agent identity | Each agent operating within organisational systems has a distinct non-human identity that can be distinguished from human users. |
Authentication | Agent identity is appropriately authenticated before access to organisational systems, data or services is granted. |
Attribution | Actions and decisions can be attributed to the specific agent, the organisation or individual on whose behalf it acts, and the authority under which it operated. |
Traceability & logging | Agent decisions, instructions and actions are appropriately logged so that activity can be reconstructed and investigated. |
Revocation & suspension | Agent credentials, permissions and access can be restricted, suspended or revoked promptly when required. |
Agent-to-agent identification | Where agents interact with other AI agents, each agent's identity remains distinguishable so that actions and authority can be attributed across the interaction. |
Inbound agent identification | Where external AI agents interact with the organisation, the organisation should have appropriate means to identify the agent and, where necessary, establish the person or organisation on whose behalf it is acting. |
5.2 Delegated authority
Where an AI system is permitted to act on behalf of the organisation, its delegated authority should be explicitly defined and proportionate to the risk of its use. The organisation should specify the decisions and actions the AI is authorised to take independently, those requiring human confirmation, and those that are outside its authority. Delegated authority should have defined limits and should be reduced, suspended or withdrawn when circumstances, performance or risk change. Delegating authority to an AI system does not transfer accountability away from the organisation or its accountable owner.
5.3 Agent permissions and boundaries
AI agents should be given only the access and permissions necessary to perform their approved role. Permissions should enforce the agent's delegated authority by defining the systems, data, functions and actions it may access or perform, including any prohibited or conditional actions. An agent should not be able to expand its own permissions, obtain access to additional systems or data, or delegate authority beyond what has been approved. Where an agent reaches a defined boundary or encounters a situation outside its authorised permissions, it should be prevented from proceeding and, where appropriate, escalate to an appropriately authorised person.
Technical capability or system access does not, by itself, constitute authority to act.
GOVERNANCE AREA | WHAT IT SHOULD COVER |
|---|---|
System & tool access | The systems, applications, tools and services the agent is permitted to access, limited to those necessary for its approved role. |
Data access | The categories of data the agent may access, use, modify or disclose, with access limited to what is necessary for its authorised purpose. |
Action permissions | The actions the agent may perform independently, including creating, modifying, approving, communicating, booking, purchasing or otherwise acting within organisational systems. |
Prohibited actions | Actions the agent must not perform, regardless of whether the underlying system technically permits them. |
Conditional actions | Actions that may be taken only when defined conditions are satisfied, such as a value limit, additional verification, human approval or other control. |
Transaction limits | Defined limits on financial, contractual, booking, purchasing or other material transactions the agent may initiate or complete. |
Scope limitations | Limits on the properties, systems, users, data, jurisdictions, services or other operational areas within which the agent may act. |
Delegation restrictions | Controls preventing an agent from granting itself or another agent greater authority, permissions or access than has been approved. |
Boundary enforcement | Technical or operational controls that prevent the agent from accessing systems, data or actions outside its approved permissions rather than relying solely on the agent to follow instructions. |
Escalation at the boundary | Defined circumstances in which the agent must stop and refer an action to an appropriately authorised person rather than proceeding when authority or permission is unclear or exceeded. |
Permission review & revocation | Permissions are periodically reviewed and can be reduced, suspended or revoked when the agent's purpose, risk, performance, circumstances or authority changes. |
5.4 Internal agent oversight
AI agents acting on behalf of the organisation should remain subject to appropriate human oversight throughout their operation. The organisation should have sufficient visibility into the agent's actions, decisions, interactions and outcomes to identify unexpected or inappropriate behaviour and determine when intervention is required. Oversight should be proportionate to the agent's authority, autonomy and potential impact, and should include defined triggers for human review, escalation, intervention, suspension or termination. People responsible for oversight should have the authority, information and competence necessary to intervene effectively, and agents should not be permitted to continue operating solely because a human has failed to intervene.
GOVERNANCE AREA | WHAT IT SHOULD COVER |
|---|---|
Operational visibility | The organisation can see what the agent is doing, including material decisions, actions, transactions and interactions. |
Human monitoring | Appropriate monitoring is established based on the agent's risk, authority, autonomy and potential impact. |
Intervention triggers | Defined circumstances require human review, intervention, escalation or suspension. |
Human authority | The person responsible for oversight has actual authority to intervene, override, restrict or stop the agent. |
Circuit breakers | The agent can be suspended or stopped promptly when defined conditions or unsafe behaviour occur. |
Escalation | Situations outside the agent's authority, competence or confidence are directed to an appropriately authorised human. |
Ongoing review | Agent performance, behaviour and use of delegated authority are periodically reviewed, with authority reduced or controls strengthened where necessary. |
Traceability | Sufficient records are maintained to understand what the agent did, why it acted, and what happened as a result. |
5.5 Inbound AI agents
AI agents may act on behalf of guests, partners, vendors or other external parties and may interact directly with the organisation's systems, people or services. The organisation should establish appropriate conditions for accepting and responding to such interactions, including proportionate means of establishing the agent's identity, the person or organisation on whose behalf it is acting, and the scope of authority relevant to the interaction. Access to systems, data and services should be limited to what is necessary and authorised, and the organisation should be able to restrict, refuse or escalate interactions that cannot be appropriately verified or that fall outside defined boundaries.
5.6 AI-to-AI / ecosystem interaction
Where AI agents interact with other AI agents, automated systems or digital services, organisations should ensure that the interaction remains within the authority and boundaries established for each agent. An agent should not be able to acquire greater authority, permissions or access merely through interaction with another agent, nor should one agent be able to cause another to bypass its own controls or approval requirements. Where interactions involve conflicting instructions, material transactions, cascading actions or circumstances outside the agents' defined authority, the interaction should be restricted, stopped or escalated as appropriate. The organisation should maintain sufficient traceability to understand material agent-to-agent interactions, including the actions taken and the resulting outcomes.
5.7 Data collection and disclosure through agents
When an agent is involved, personal data changes hands without anyone completing a form, reading a notice or making a choice at the moment it happens. The organisation’s obligations to the individual are unchanged. This section sets out how the organisation decides whether to accept, limit or refuse personal data arriving through an agent, and what its own agents may collect or disclose. It describes decisions and outcomes, not technical mechanisms.
Before personal data is accepted from, or disclosed to, an agent, the organisation should be able to answer five questions: on whose behalf the agent is acting; what permits the use of the data; whether each element is necessary for what is being asked; whether anything sensitive or unrequested has been volunteered; and whether the person’s rights can still be honoured afterwards.
Refer to Appendix D for the reference question set and guidance on applying each question.
Three outcomes, and the default
OUTCOME | WHEN IT APPLIES | WHAT IT MEANS IN PRACTICE |
|---|---|---|
Accept | The agent’s principal is established to a proportionate degree, the basis for use is clear, and the data is limited to what the transaction requires. | Proceed, record what was received and why, and apply the same protection as if the person had provided it directly. |
Accept with limits | The interaction is legitimate but the data offered exceeds what is needed, or includes categories the organisation has not agreed to accept through an agent. | Take the necessary subset only; decline or discard the remainder; exclude sensitive categories; hold nothing beyond the transaction unless a separate basis exists. |
Decline, with a route to a human | Attribution cannot be established, the basis for use is unclear, or the request would require the organisation to hold data it should not hold. | Refuse the data rather than the guest: offer a path to a person so the individual is not disadvantaged by the limits of their agent. |
Default posture. Where the answer to any of the five questions is unclear, the governed response is to narrow the interaction rather than proceed. Declining to collect personal data is always available to the organisation and is rarely the wrong answer.
What the organisation’s own agents may collect and disclose
Collect only for the approved purpose. Conversational interaction elicits more than a form does. An agent should gather what its approved purpose requires, and personal detail a guest happens to mention should not be retained merely because it was said.
Never disclose one person to another. An agent must not reveal a guest’s information to another guest, to a third party, or to another person’s agent, including confirming whether a named individual is staying at a property.
Define in advance what may be revealed to another organisation’s agent. Where an agent transacts or negotiates with a partner, platform or vendor agent, the categories it may disclose are decided beforehand rather than left to the exchange.
Treat agent interactions as records. Where an agent interaction involves personal data, its retention position is decided by the organisation or relevant governing authority rather than inherited from a platform default, and it is covered by the same deletion arrangements as other guest records.
Notice when no one is reading
Privacy information is written for a person looking at a screen. When an agent transacts, no person reads it at the time. The organisation should be able to state where its data practices are published in a form an agent can retrieve, and at what point the individual is informed in a way that is meaningful to them, which for most hospitality transactions means at confirmation and before arrival.
Where jurisdictional requirements apply, they govern. This section describes governance expectations only and is not a statement of legal compliance; each organisation remains responsible for determining the requirements that apply to it.
Use this tool
Use this tool ↗Test human-in-the-loop with a hotel AI agent
Work through late-checkout and early-departure requests using front-desk and manager-on-duty views for approval, denial, escalation and baselining. Courtesy of Verified Digital Agents. This is a contributor-supplied test-data demonstration, not proof of legal compliance.
Pillar 5 in practice (informative)
Agent identity. A booking agent operating in the PMS acts under its own named non-human account; in the logs its rate changes are never confused with a front-desk user’s, and its access can be revoked in one step without affecting staff.
Delegated authority. A guest-messaging agent may resolve requests up to a defined value, such as granting a late checkout, but must hand refunds or rate overrides to a person; the limits are recorded, not tribal knowledge.
Permissions and boundaries. The agent’s system permissions match its authority: it can read availability and write a booking within approved rate plans, and it cannot reach payroll, exports or payment settings even if instructed to.
Internal oversight. Overrides, near-boundary events and unusual patterns route to a named owner with a working suspension switch that has been rehearsed, not assumed.
Inbound agents. When a guest’s AI assistant books a room, the hotel recognises it as an agent, applies proportionate verification and rate limits, provides machine-readable policies (cancellation, deposits, identification requirements), and can refuse or escalate interactions that cannot be verified.
AI-to-AI interaction. A hotel rate-negotiation agent dealing with a corporate travel platform’s agent cannot grant discounts beyond its mandate regardless of what the counterparty requests; conflicting instructions or cascading actions stop and escalate to a person.
Data collection and disclosure. A guest's AI assistant requests a room booking and volunteers additional personal and health-related information that the hotel has not requested and does not need for the booking. The hotel accepts the information necessary to complete the transaction, declines or discards the remainder, and retains only what is required for the approved purpose.
Governance health indicators
Governance is not a one-time exercise. Organisations should periodically assess whether their AI governance arrangements are operating as intended and whether they remain appropriate to the organisation's AI use, risk and circumstances. The organisation should be able to demonstrate, proportionate to its governance arrangements:9
INDICATOR | WHAT THE ORGANISATION SHOULD BE ABLE TO DEMONSTRATE OR ANSWER | WHY IT MATTERS |
AI visibility | Can the organisation produce a current AI register and identify what AI it uses, where it is used, for what purpose and who is accountable for it? How much AI in use was identified through review rather than declared? Which reviews are overdue? | Governance cannot operate effectively where AI use is unknown, incomplete or out of date. |
Accountability | Does every system requiring formal accountability still have a named and active owner with appropriate decision rights? Have changes in roles, personnel or organisational structure created accountability gaps? | Accountability can weaken over time even where it was clear at the point of approval. |
Risk review | Is there evidence that AI systems are reviewed when required, including following material changes in purpose, risk, autonomy, data, vendor or operating circumstances? | AI risk and governance requirements may change after adoption. |
Human oversight effectiveness | Is human oversight operating as designed and meaningful in practice? Are people actually intervening, correcting or overriding AI where appropriate? Are there signs that oversight has become routine, ineffective or merely procedural? | Documented human oversight does not necessarily mean that meaningful human judgement is being exercised. |
Harm, incidents and learning | What material AI incidents, errors, near misses, complaints or concerns have occurred? Can the organisation demonstrate how they were identified, managed, corrected and learned from? | Governance should improve in response to evidence of harm, failure or emerging concerns. |
Response capability | Can the organisation suspend or restrict material AI use, revoke access, retrieve relevant records and make necessary communications within an appropriate timeframe? Has this capability been tested rather than assumed? | An organisation may have an incident process but still be unable to stop or contain AI effectively when required. |
Vendor and change assurance | Is required vendor evidence current? Has the organisation identified and appropriately responded to material vendor, model or system changes in time? | Third-party AI can change materially after adoption, affecting risk, controls and accountability. |
Contestability and redress | Where a guest, employee or other person may be materially affected by AI, are meaningful routes available for human review, challenge, correction and, where appropriate, redress? How quickly can an affected person reach an appropriately authorised human? | People should not be left without a meaningful route to question or correct significant AI-influenced outcomes. |
Governance literacy | Do people with AI-related responsibilities have the knowledge and understanding necessary to perform their governance roles? Has capability been maintained following staff changes, new responsibilities or new AI uses? | Governance arrangements depend on people understanding the responsibilities they have been assigned. |
Suspension in practice | Has the ability to suspend or constrain an AI system been tested rather than assumed, including who exercises it, at what hours, and by what means? | A rehearsed stop is the best predictor of incident response. Untested suspension authority is an assumption, not a control. |
Governance and value | Can the organisation distinguish between whether AI is delivering its intended commercial or operational value and whether it is being governed effectively? Is AI commercially or operationally successful but poorly governed, or well governed but failing to deliver its intended value? | Governance effectiveness and business performance are separate questions and should not be confused. |
These indicators should be reviewed at a defined cadence and following a significant incident or material change by someone accountable for reviewing and improving the governance system.
An organisation that can demonstrate these things has evidence that its AI governance is functioning in practice, not merely documented.
Minimum viable governance
Organisational size does not remove the need for basic AI governance. Regardless of size, structure or maturity, every hospitality operator should establish a small set of foundational governance records that provide visibility, accountability and control over its use of AI. At minimum, the organisation should have:
- AI Register — a current record of the AI systems in use, including embedded AI, their purpose, risk level and accountable owner.
- AI Use & Risk Assessment - a documented assessment of what each material AI system is used for, its approved purpose, boundaries, key risks and required level of governance.
- AI Governance & Acceptable Use Policy - clear organisational rules covering approved AI use, data handling, verification, human review, prohibited uses and employee responsibilities.
- AI Vendor Due Diligence Record - a record of the key questions asked of vendors and the answers received before adopting material third-party AI.
- AI Approval & Decision Record - evidence of who approved the use of material AI, under what conditions, and with what delegated decision rights or controls.
- AI Incident & Change Record - a simple record of material incidents, concerns, changes, reviews and resulting actions.
- AI Review & Assurance Record - evidence that material AI systems are periodically reviewed and that required controls, human oversight and risk assessments remain appropriate.
- Human Review & Redress Route - documented route through which an affected guest or employee can reach an appropriately authorised human to question, review or correct an AI-influenced outcome.
These are the foundational records, not a complete governance system. They provide the minimum foundation from which more sophisticated governance can develop as the organisation's use of AI, risk and maturity increase. What differs between a single property and a global group is the depth, formality and sophistication of these arrangements, not the need for them.
Eight foundational records, plus an agent-specific supplement. The Implementation Workbook provides these eight records and a supplementary Agent Controls worksheet for organisations using AI agents under Pillar 5. Agent Controls is not a ninth foundational record.
Status and use
This framework is a voluntary AIHA industry reference. AIHA does not certify, audit or endorse conformity with it. Adoption creates no membership, fee or compliance obligation. It is not legal advice and does not establish compliance with any law. Where applicable law or binding contractual obligations differ, those requirements govern.
Reference material
Appendices
All guidance in the appendices are informative and should not be misconstrued as legal advice.
Appendix A: Regional regulatory and standards signals
Snapshot: August 2026. This appendix is informative, not normative. It is not exhaustive and is not legal advice; each organisation remains responsible for verifying the requirements that apply to it. Links point to primary sources where available. AIHA intends to maintain a companion regulatory watch updated on a defined cadence.
REGION | KEY INSTRUMENTS AND SIGNALS | MOST RELEVANT FRAMEWORK AREAS |
|---|---|---|
European Union | AI Act, Regulation (EU) 2024/1689 (phased: prohibited practices and AI literacy since Feb 2025; general-purpose AI since Aug 2025; transparency since Aug 2026; high-risk obligations from 2 Dec 2027 for Annex III systems and 2 Aug 2028 for high-risk systems embedded in regulated products); GDPR incl. special-category biometric data; Article 101 TFEU competition law. | Risk classification and tiers; human oversight; transparency, contestability and redress; data stewardship; AI governance literacy |
United States | No comprehensive federal AI statute. Federal direction runs through executive action, agency guidance and procurement policy. State and city patchwork incl. Colorado Automated Decision-Making Technology Act (SB26-189) (applicable duties from Jan 2027); Illinois BIPA and analogues; NYC Local Law 144 (AEDT); California AI Transparency Act (SB 942) and companion chatbot law (SB 243). Active antitrust enforcement and litigation on algorithmic pricing, incl. revenue-management settlements (2025) and a developing appellate split (2025–2026). | Risk classification; vendor governance and cross-customer data use; biometric uses; employment AI; transparency and fairness |
United Kingdom | Principles-based, regulator-led approach; ICO guidance on AI and data protection; CMA work on AI foundation models. | Risk classification; vendor governance; transparency and fairness |
Asia-Pacific | Republic of Korea AI Basic Act (in force Jan 2026); China generative AI measures, algorithmic recommendation rules and AI-content labeling measures (in force Sep 2025) plus PIPL; Japan AI Promotion Act (Act No. 53 of 2025); Singapore Model AI Governance Framework incl. Agentic AI edition (IMDA, Jan 2026) and AI Verify; India Digital Personal Data Protection Act, 2023. | Register and shadow AI; risk classification; transparency; authenticity and content labeling; AI agents and ecosystem |
Middle East | UAE national AI strategy and federal AI authority (2026); Saudi Arabia SDAIA AI ethics principles and PDPL; MENA AI harmonisation initiative (UAE, Saudi Arabia, Qatar, Oman, 2026). | Foundations and principles; vendor governance; transparency and people protections |
International standards | ISO/IEC 42001 (AI management systems); ISO/IEC 42005:2025 (AI system impact assessment); ISO/IEC 23894 (AI risk management); NIST AI Risk Management Framework; OECD AI Principles. | Whole framework; risk and impact assessment methodology; assurance and evidence |
Appendix B: Alignment with the NIST AI risk management framework
Indicative, non-exclusive mapping to the NIST AI RMF functions (reference 1). The framework remains standards-neutral. This is an AIHA crosswalk, not a NIST-endorsed mapping or evidence of compliance.
THIS FRAMEWORK | NIST AI RMF ALIGNMENT |
|---|---|
Foundations: principles, functions, governance literacy | GOVERN (policies, accountability, culture, workforce competence) |
Pillar 1: register, risk classification, accountability and decision rights | GOVERN and MAP (context, categorisation, risk framing) |
Pillar 2: people, guests and workforce | MAP (impact identification) and MANAGE (response, redress) |
Pillar 3: data stewardship, security, testing and assurance, evidence | MEASURE (assessment, TEVV) and MANAGE (controls, documentation) |
Pillar 4: vendors, lifecycle and operational control | GOVERN (third-party) and MANAGE (monitoring, incident, change, retirement) |
Pillar 5: AI agents and ecosystem | MAP and MANAGE applied to agentic autonomy; emerging area beyond current RMF core text |
Governance health indicators and minimum viable governance | MEASURE (effectiveness evaluation) and GOVERN (continuous improvement) |
Appendix C: Vendor due diligence questionnaire
Informative companion to the vendor governance areas in Pillar 4. A property-usable question set; record the answers as part of the AI Vendor Due Diligence Record.
ASK THE VENDOR | WHAT TO ESTABLISH |
|---|---|
What AI or models power this system, and how are they updated? | Model and provider chain, material changes and how changes are communicated. |
What data do you collect and what is it used for? | Data categories, purpose, inputs, outputs, telemetry and secondary uses. |
Do you use our data to train or improve your models? | Whether organisational data trains or improves models, and whether it is isolated from other customers. |
Are your recommendations informed by other customers’ data? | Whether pricing or other recommendations draw on non-public data from other customers, including competitors, and how it is segregated. |
Where is our data stored and processed, and does it cross borders? | Locations, jurisdictions, subprocessors and transfer safeguards. |
How long do you retain our data, and can it be deleted? | Retention for inputs, outputs, logs and backups; deletion process and evidence. |
Who can access our data? | Vendor personnel, subprocessors, support arrangements and access controls. |
What can the AI do without human approval? | Action boundaries, permissions, human review, override and suspension capability. |
How will we know if something changes or goes wrong? | Material-change and incident notification, relevant records and escalation. |
What happens when the relationship ends? | Data return or deletion, records, continuity and exit assistance. |
Appendix D: Applying the five questions for personal data through agents
Informative companion to the data collection and disclosure gate in Pillar 5. Each question is restated with guidance on how it is applied.
Five questions before personal data is accepted from, or disclosed to, an agent
1. On whose behalf is the agent acting, and can that be established?
2. What permits this use of the data, and does the agent’s assertion satisfy it?
3. Is each element necessary for what is being asked?
4. Has the agent volunteered anything sensitive, or anything that was not requested?
5. Can the person’s rights still be honoured afterwards?
How each question is applied
1. On whose behalf is the agent acting, and can that be established? Personal data offered by an agent is only as reliable as the link between the agent and the person it claims to represent. Where that link cannot be established to a degree proportionate to the sensitivity of the data, the organisation should confine the interaction to what does not require personal data, or decline it.
2. What permits this use of the data, and does the agent’s assertion satisfy it? An agent stating that its principal agrees is not, in itself, that person’s consent. Where the intended use depends on consent, the organisation should obtain it from the person, or rely on a different and properly recorded basis such as performing the booking the person has asked for. An agent’s convenience is not a lawful basis.
3. Is each element necessary for what is being asked? An agent may transmit an entire guest profile when a reservation requires a name, dates and a means of payment. The organisation should take what the transaction requires and decline the remainder rather than retain it because it arrived. Receiving personal data is a decision, not an accident.
4. Has the agent volunteered anything sensitive, or anything that was not requested? Agents routinely relay dietary, accessibility, health, family or religious detail in order to be helpful. Such information attracts heightened protection whether or not the organisation asked for it, and it can also be inferred from apparently ordinary preferences. The organisation should decide in advance which categories it will accept through an agent and what it does with unsolicited sensitive information, including declining or discarding it. That an agent supplied it is not authority to keep it.
5. Can the person’s rights still be honoured afterwards? Notice, access, correction and deletion assume a person who can be reached. Where a transaction is machine to machine, the organisation should be able to say how the individual receives the information they are owed, and how a later request from that person is satisfied across the records the agent interaction created.
Appendix E: A working example
When AI answers the guest, every seat is affected
Automation level is a governance decision, not a vendor default. Decide it deliberately, per function, and revisit it: a quiet product update can turn assistance into action. |
Repeatable tools
Governance in action
Use this tool
Use this tool ↗Test human-in-the-loop with a hotel AI agent
Work through late-checkout and early-departure requests using front-desk and manager-on-duty views for approval, denial, escalation and baselining. Courtesy of Verified Digital Agents. This is a contributor-supplied test-data demonstration, not proof of legal compliance.
Use this tool
Use this tool ↗Check if your hotel meets the EU AI Act
Review hospitality-relevant EU AI Act and GDPR questions. Courtesy of Verified Digital Agents. Use it for orientation, not as legal advice or compliance certification.
Contributors
People whose substantive inputs shaped this guide
The distinction between guest and AI-system lifecycles, governance needs across adoption stages, and technical review of the data-security and regulatory content incorporated into the framework.
Audience and publication structure, risk-tier refinements, the boundary between governance guidance and legal advice, source reconciliation, and the public framework and diagram package.
Hospitality privacy and consent controls, employee use of consumer AI, higher-consequence treatment of recruitment screening, and accessible risk examples for non-technical operators.
The Human-in-the-loop hotel-agent test and the Check if your hotel meets the EU AI Act tool; escalation examples; and the Governance Harness white paper.
Framework leadership and synthesis; definitions, principles, literacy, the five pillars and color-coded mind map; hospitality risk examples, biometric safeguards, vendor questions and final model-chain disclosure wording.
The practical adoption and living-document perspective, including how governance remains usable as technology and organizational maturity change.
Proposed practical guidance on where AI agents belong in operations, explicit escalation and human-in-the-loop expectations, and usability for teams of different sizes—topics reflected in Pillar 5 and the proportionate approach to adoption.
The V4 foundation and mind-map-first structure; technical and appendix review and biometric footnote treatment. Identified five additional AI-security areas, from model provenance to session separation, which Abhijeet incorporated into the final security table.
Workgroup leadership and the higher-level-first sequence that begins with governance principles and data models before lower-level implementation detail.
Further reading
External resources
Sources and references
1. National Institute of Standards and Technology. AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023. nist.gov/itl/ai-risk-management-framework
2. International Organization for Standardization. ISO/IEC 42001: Artificial intelligence management system. iso.org/standard/42001
3. International Organization for Standardization. ISO/IEC 42005:2025: AI system impact assessment. iso.org/standard/42005
4. International Organization for Standardization. ISO/IEC 23894: AI risk management guidance. iso.org/standard/77304.html
5. OECD. OECD AI Principles (adopted 2019, updated 2024). oecd.ai/en/ai-principles
6. European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act), 2024. eur-lex.europa.eu/eli/reg/2024/1689/oj
7. OWASP Foundation. OWASP Top 10 for LLM Applications (2025 edition). genai.owasp.org/llm-top-10
8. MITRE. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. atlas.mitre.org
9. Infocomm Media Development Authority (IMDA). Model AI Governance Framework for Agentic AI, launched 22 January 2026. Official framework launch and resources. Cited in Pillar 5, footnote 8.
10. (2026). Governing Agentic AI: A Strategic Framework for Autonomous Systems. Preprint introducing the Zoned Governance Model for progressive autonomy, building on the LOKA Protocol (Ranjan et al., 2025). researchgate.net/publication/395967098
11. (2026). The Governance Harness: Why AI Agent Accountability Is Hospitality's Next Audit Line. Verified Digital Agents (Rawson Consulting B.V.). aihospitalityalliance.com/insights/governance-harness-ai-agent-accountability
Regional legislation and regulation are cited with links in Appendix A.
Footnotes
NIST AI RMF (AI 100-1); ISO/IEC 42001; OECD AI Principles; EU AI Act (Regulation (EU) 2024/1689). See Appendix A and References.
↩(2026). Governing Agentic AI: A Strategic Framework for Autonomous Systems (preprint). researchgate.net/publication/395967098; see Sources and References.
↩EU AI Act (risk-based approach); NIST AI RMF, Map function. See Appendix A.
↩EU AI Act (human oversight); NIST AI RMF, Govern and Manage functions. See Appendix A.
↩MITRE ATLAS; OWASP Top 10 for LLM Applications. See References.
↩The areas from model and component provenance to session separation correspond to OWASP Top 10 for LLM Applications categories (supply chain, data poisoning, excessive agency, unbounded consumption) and MITRE ATLAS techniques including ML supply chain compromise. See Sources and References.
↩ISO/IEC 42005:2025 (AI impact assessment); ISO/IEC 23894 (AI risk management). See Appendix A.
↩Singapore Model AI Governance Framework for Agentic AI (IMDA, January 2026). See Appendix A and reference 9.
↩ISO/IEC 42001 (performance evaluation and improvement). See Appendix A.
↩
Links cited in the framework
The regional appendix retains the document’s August 2026 snapshot, with the separately checked EU timeline and Colorado law updates. Appendix B is an indicative AIHA crosswalk: the People and Data rows retain their corresponding NIST functions. It is not a NIST-endorsed mapping. Verify requirements for each organisation and jurisdiction. Access checks do not certify accuracy or legal applicability.
- AI Act, Regulation (EU) 2024/1689Standard or official guidance · HTTP 202 response; full access not verified · 7 September 2026
- GDPRStandard or official guidance · HTTP 202 response; full access not verified · 7 September 2026
- Article 101 TFEUStandard or official guidance · HTTP 202 response; full access not verified · 7 September 2026
- Colorado Automated Decision-Making Technology Act (SB26-189)Standard or official guidance · HTTP 200 response; enacted summary independently verified · 7 September 2026
- Illinois BIPAStandard or official guidance · Could not verify access · 7 September 2026
- NYC Local Law 144 (AEDT)Standard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- California AI Transparency Act (SB 942)Standard or official guidance · Could not verify access · 7 September 2026
- companion chatbot law (SB 243)Standard or official guidance · Could not verify access · 7 September 2026
- ICO guidance on AI and data protectionStandard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- CMA work on AI foundation modelsStandard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- AI Basic ActStandard or official guidance · Could not verify access · 7 September 2026
- AI-content labeling measuresIndustry perspective · HTTP 200 response; content not independently verified · 7 September 2026
- AI Promotion Act (Act No. 53 of 2025)Standard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- Model AI Governance Framework incl. Agentic AI edition (IMDA, Jan 2026)Standard or official guidance · Official January 2026 launch page verified; cited edition retained · 10 September 2026
- AI VerifyIndustry perspective · HTTP 200 response; content not independently verified · 7 September 2026
- Digital Personal Data Protection Act, 2023Standard or official guidance · Access restricted or unavailable (HTTP 404) · 7 September 2026
- UAE national AI strategyStandard or official guidance · Access restricted or unavailable (HTTP 403) · 7 September 2026
- SDAIAStandard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- ISO/IEC 42001Standard or official guidance · Access restricted or unavailable (HTTP 403) · 7 September 2026
- ISO/IEC 42005:2025Standard or official guidance · Access restricted or unavailable (HTTP 403) · 7 September 2026
- ISO/IEC 23894Standard or official guidance · Access restricted or unavailable (HTTP 403) · 7 September 2026
- NIST AI Risk Management FrameworkStandard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- OECD AI PrinciplesStandard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- genai.owasp.org/llm-top-10Standard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- atlas.mitre.orgStandard or official guidance · HTTP 200 response; content not independently verified · 7 September 2026
- researchgate.net/publication/395967098Contributor-supplied preprint · Access restricted or unavailable (HTTP 403) · 7 September 2026
- NIST AI RMF Core — functions used in Appendix BStandard or official guidance · Official MAP, MEASURE and MANAGE function descriptions verified; AIHA crosswalk remains indicative · 10 September 2026
Governance in action
- Test human-in-the-loop with a hotel AI agent — courtesy of Verified Digital Agents; contributor-supplied working example, not compliance certification.
- Check if your hotel meets the EU AI Act — courtesy of Verified Digital Agents; contributor-supplied orientation tool, not official legal guidance or compliance certification.