SearchHorwath HTL opens in a new tab

Tech · Hotel AI Readiness Check

Resources and usage notes

Answers to common questions, checks for a proposed application, templates you can copy, definitions and the reference frameworks we compared against.

Contents

Before a trial

Additional checks for a proposed application

Before a trial, confirm its purpose, tools, information, users/operators, accountable person, quality standard, boundaries and review arrangements. Apply the following additional checks according to its characteristics. These are follow-up implementation prompts, not extra core readiness points or an exhaustive risk audit.

Checks to resolve before the affected live use
CharacteristicChecks to resolve before the affected live use
Restricted guest, employee, payment or business informationConfirm permitted use, access, retention and other required information-handling arrangements. Obtain appropriate specialist approval.
Direct guest interactionTest factual answers, boundaries, languages and user needs; establish appropriate disclosure, reachable human escalation and service recovery.
Automatic read access to systemsConfirm authorised access, property-level restrictions, data quality, timeliness, monitoring and source reconciliation.
Changes to records, prices, commitments or transactionsDefine allowed actions and approval limits; test permissions, action records, failure handling, monitoring, stopping and correction or reversal where possible.
Safety or other consequential decisionsObtain qualified domain and risk review; test against authoritative information and define decisions that must remain outside the application.
Connected tools exposed to incoming messages or documentsInclude technical testing for malicious or misleading instructions, unauthorised information access and actions beyond the intended boundaries.

A written instruction to the AI is not a substitute for an enforced permission where enforcement is required. More automated work does not necessarily require a person to approve every step, but it does require a justified and workable accountability arrangement.

Result language

Describe a result in terms such as:

  • “Foundations reported in place across the hotel; complete the applicable deployment checks before live use.”
  • “Resolve these named gaps before this use.”
  • “Verify these requirements before deciding.”

Do not use “Approved”, “Certified safe” or an unconditional “Ready to deploy”.

Unresolved requirements prevent the use that depends on them. They do not necessarily prevent all other uses. A qualified person must make the final deployment decision; the website is not that approver.

Usage notes

Frequently asked questions

Must every employee have an account?

No. Direct users need suitable access; reviewers need appropriate oversight capability; affected staff need explanation and a feedback route. Some people have several roles.

Does an Enterprise subscription score better?

Not by its label. Judge fitness, coverage, administration and approved information use. More expensive access and more licences are not goals.

Can central or external support count?

Yes, when it is reliably available to the assessed scope. An independent does not need a corporate department; a chain property does not need to duplicate a working central service.

What does openness mean?

The ability to obtain and reuse information and authorise supported connections on workable terms. It does not mean public guest information, mandatory open-source software or free access.

Do we need a data warehouse?

Not as a scoring prerequisite. The chosen work needs accessible and dependable information. Assess the suitability of the arrangement, not its architecture.

Do we need working AI in production?

No. Appropriate demonstrations, exercises and safe connection tests can establish readiness for a first trial. Adoption stage is separate from readiness.

What if staff disagree?

Identify the different teams, shifts or situations behind their answers. Record a coverage gap or seek verification. Do not average contradictory answers into a misleading full score.

What if nobody can answer a supplier question?

Use Not sure and create a verification task. Do not assume that uncertainty establishes lack of capability or vendor openness.

What if we have no good application yet?

Browse the role guide and involve the people doing the work. A provisional result can prioritise selecting a useful task; it must not automatically recommend an invented one.

How do we use this for a chain?

Assess shared provision once where possible, then confirm property-level access and coverage. Keep property variation and critical gaps visible. A group average cannot establish readiness at every hotel.

What about group scope across countries?

Record the included locations and obtain appropriate local information-handling and other specialist review. This framework does not determine jurisdiction-specific compliance.

Should results be compared between hotels?

Use caution: task scope, coverage, applicability and self-reporting can differ. Compare like-for-like assessments and retain version/date/scope. Do not publish league tables or external benchmarks before validating the assessment method.

When should we repeat it?

Revisit affected answers after changes to people, scope, tools, data sources, permissions or actual performance, and at the trial review. A broader scope can reveal new gaps without implying the original team has deteriorated.

What should not be entered?

Guest records, personal staff cases, payment details, access keys and confidential documents. Role names and descriptions of work are usually sufficient.

What do the scores not establish?

They do not establish legal compliance, security assurance, employee competence certification, financial return or approval of an AI application. They reflect reported foundations for a stated scope.

Supporting templates

Templates

Supplier enquiry template

Subject: Access and integration arrangements for our hotel account

We are reviewing whether our hotel can connect approved tools to your system. Please confirm:

  1. Whether our actual account can export the required information, including fields, detail and history, and the conditions for reuse or switching suppliers.
  2. Whether API or equivalent supported access is available to us or our authorised technical partner, including any partner restrictions and approval steps.
  3. Which information and functions are accessible, and whether access can be restricted by property, information type and read/write permission.
  4. What supported connectors, automated exports, documentation and safe testing arrangements are available.
  5. The setup/ongoing charges, usage limits, expected access timing and support responsibilities.
  6. How we revoke access, handle failures and retain appropriate access to our information when changing tools or suppliers.

Please distinguish capabilities included in our current arrangement from features requiring upgrades, additional contracts or approval.

Assessment note: Record confirmed access separately from advertisements. Staff assistant licences and system/API access are separate questions.

Approved-tool register

Approved-tool register
FieldEntry
Tool or capabilityName and work purpose.
Approved informationCategories permitted; restrictions and prohibited uses.
Intended users/coverageRoles, teams, shifts or properties.
Access arrangementAccount/subscription/entitlement and relevant limits.
AdministratorResponsible role and escalation route.
Approval referenceWho reviewed this use, when, and any conditions.
Review trigger/dateWhen to recheck terms, access or changing uses.

Do not put passwords, API keys or sensitive records into this register or the readiness questionnaire.

Information ownership record

Information ownership record
FieldEntry
Information setProperty facts, procedures, reports or other source.
Authoritative locationWhere the current approved information is maintained.
Owner and backupWho can validate and correct it.
Update triggersChanges requiring review or refresh.
Correction routeHow errors are reported and resolved.
Downstream copies/connectionsWhere changes must propagate and how obsolete content is withdrawn.

One-page trial and action template

One-page trial and action template
FieldEntry
Task and problemWhat happens today and what should improve.
Alternative consideredWhether a simpler process or existing feature could meet the need.
Participants and coverageDirect users/operators, reviewers, affected staff, locations and shifts.
Owner and supportAccountable role, sponsor and practical support.
Tools and informationApproved capabilities, sources and access arrangement.
BoundariesWhat the application may and may not do; excluded information/actions.
Starting measurePresent effort, cost, quality or service result.
Success criteriaA worthwhile improvement, including total checking/correction effort.
Additional checksApplicable requirements, their status and approver where required.
Failure responseWho detects, stops, corrects and provides an alternative process.
Review dateWhen to decide continue, change or stop.
ActionsUp to three priorities, each with owner, target date and completion test.

Illustrative result narrative

Scope: Sales proposal drafting and supervisor-prepared housekeeping briefings at one named property, across the teams and shifts specified by the respondent.

Reported position: Sales has practical experience. Housekeeping briefing preparation is less consistent across shifts. Approved accounts do not yet cover every intended supervisor. Property information exists, but responsibility for updating some procedures is unclear.

Next step: Consider a bounded, staff-reviewed briefing trial using approved internal information after confirming its permitted use. Do not include guest records or operational system changes without separate review.

Suggested actions: Extend or deliberately redesign the briefing preparation arrangement to cover participating shifts; assign ownership of the procedure source; practise the task and review process with the intended users.

Important limitation: System integration has not been established by these findings. Functions outside the recorded scope have not been assessed. This narrative illustrates how reported answers should be summarised; it is not a result for a real hotel.

Plain language

Plain-language definitions

AI capability
A tool or feature used to assist or carry out work; not necessarily a standalone chatbot.
API
A supported interface through which software can request information or functions from another system.
Connector
A prepared connection between particular tools or systems; its coverage and restrictions still need checking.
Export
A copy of information taken from a system in a usable form.
Read-only access
Permission to retrieve information without changing the source records.
Accountable owner
The person or role responsible for deciding what is acceptable and dealing with the outcome.
Authoritative source
The approved place to obtain the current fact, instruction or record.
Coverage
The people, activities, shifts, locations, information or systems to which the capability must apply.
Controlled trial
A limited test with defined participants, boundaries, measures and a review point.
Openness
Workable access and reuse rights and supported connection options, not public access to private information.

Reference points

Reference frameworks and online resources

The following resources provide useful comparisons and deeper guidance. Their inclusion does not imply endorsement, certification or equivalence between their scores and this framework. Summaries below are brief descriptions; our questionnaire and improvement recommendations are our own design.

Resource descriptions are reviewed when publishers revise them, and each carries the date its link was last checked.

Primary references

  • AI Singapore and the AIRI Foundation

    AIRI

    AIRI covers organisational readiness across leadership/culture, governance, business value, data and infrastructure, using descriptions of observable capability. AI Singapore directs readers to the independently maintained framework site.

    How we use it: Check breadth and evidence-based assessment. Our distinct emphasis is hotel work, role/shift/property coverage, practical account and system access, and a short next-action plan. This is not an official AIRI assessment, and other frameworks are not implied to ignore practicality.

    Link checked 13 September 2026

  • Singapore Tourism Board

    AI Playbook for Tourism

    Tourism-specific adoption guidance covering business needs, information, technology choices, responsible use, integration and workforce adoption. It includes ready-made AI features in familiar software and discussion of system connections and portability.

    How we use it: Check hotel/tourism relevance and the balance between everyday tools and connected workflows. Convert considerations into short local questions rather than reproduce its adoption stages.

    Link checked 13 September 2026

  • NIST

    AI Risk Management Framework and Playbook

    Voluntary risk-management guidance for AI design, use and evaluation. The Playbook organises suggestions under Govern, Map, Measure and Manage and expressly does not require following every item as a complete checklist.

    How we use it: Check responsibility, oversight, evaluation and response to problems. Direct applications with greater consequences to deeper review rather than pretend 18 readiness questions constitute a risk audit.

    Link checked 13 September 2026

Additional comparison and deeper guidance

  • Additional comparison · Microsoft

    AI Readiness Assessment

    A broader enterprise assessment spanning seven areas, including strategy, governance/security, information foundations, organisational culture, infrastructure and model management, with tailored guidance.

    How we use it: An additional completeness check for larger hotel groups. Do not import model-building requirements into every property adopting a ready-made tool.

    Link checked 13 September 2026

  • Deeper guidance · IMDA and AI Verify Foundation

    Model AI Governance Framework for Generative AI

    Governance considerations including accountability, information, deployment, incident reporting, testing, security and content provenance, within a wider AI ecosystem perspective.

    How we use it: A further reference for provider arrangements and responsible deployment. Its broader policy and research dimensions are not additional hotel readiness questions.

    Link checked 13 September 2026

  • Deeper guidance · IMDA

    Model AI Governance Framework for Agentic AI

    Guidance for organisations deploying agents, including risk boundaries, meaningful human accountability, technical controls and user responsibilities. It distinguishes an agent's scope of permitted actions from its degree of autonomy.

    How we use it: Additional guidance when tools connect to systems or take actions. Do not require every respondent to read it before completing the basic check.

    Link checked 13 September 2026

What should not be entered?

What should not be entered?

Guest records, personal staff cases, payment details, access keys and confidential documents. Role names and descriptions of work are usually sufficient.

Describe the task, not individual cases. Do not enter guest names, booking details, passwords or confidential records.