Questions to ask an AI vendor before buying for your hotel

Ask for a status word on every feature: running at hotels today, built but not yet in use, or only designed. Then ask what the assistant can read and change, which actions need a person's approval, where data is stored and processed, and how you leave with your data. Get the answers in writing.

The screen looks convincing: rates, rooms, a chat box answering in full sentences. The question that decides the purchase is quieter. Which parts of this are running in a hotel today, and which parts exist only in the room you are sitting in? This article gives you the questions to ask an AI vendor before you buy, in an order you can follow in a sales meeting, with a note on what a clear answer and a weak answer sound like.

What is running at hotels today, and what is only built?#

Ask for a status word on every feature, and ask to see it on a real screen rather than a slide. The answer separates working software from a demonstration.

Use five labels and make the vendor place every feature in one of them. Then ask the vendor to say the label out loud during the demo, feature by feature, and to show where it appears in the product or the documentation. A label that exists only in speech is not a label.

Ask what "live" means precisely: how many properties, since when, and whether the person on the call can name one you may telephone. A number you cannot verify is a claim, not a fact. Ask which parts of the demo run on the same code as the live product and which are a mock built for the meeting.

Listen to tense. "We can", "it will" and "it is designed to" are all acceptable answers, as long as the vendor says which one applies. A young product with honest labels is easier to buy from than a mature-sounding one with none, because you can plan around what you know.

What can the assistant read, what can it change, and on whose authority?#

Ask for two lists: the data it can read and the actions it can take. Then ask who authorized each action and what identity the assistant carries when it acts.

Read scope first: reservations, guest records, identity documents, rates, invoices, staff notes. Reading guest records is already a personal data decision, so the list matters before anything is switched on. Then write scope: create a reservation, change a rate, send a message to a guest, issue a document, take a payment. Ask for the complete list, not three examples.

Authority matters as much as scope. Does the assistant act as the hotel, as the individual staff member who asked, or as itself? Ask what permissions that identity holds and who can revoke it. The OWASP Gen AI Security Project's entry on excessive agency (opens in a new tab) (LLM06:2025, 2026) traces damaging actions to too much functionality, too many permissions or too much independence of action, and recommends limiting tools and permissions to the minimum necessary.

If the assistant connects to other software over the web, ask how access is granted. In the Model Context Protocol specification (opens in a new tab), an open standard for connecting AI assistants to software, authorization is optional; where it is used it builds on OAuth 2.1, the common standard for granting an application limited access on a person's behalf, and clients should request only the permissions the task needs (protocol version 2026-07-28).

A concrete test: ask the vendor to sign in as a housekeeping user and try to make the assistant change a rate. If it succeeds, the permission model is decorative.

For a wider picture of where AI touches hotel operations, see AI in hotels: a practical guide to uses, limits and safeguards.

Which actions need a person's approval, and can you undo them?#

Ask for the approval rule per action and for the undo. If either is missing, the assistant is doing things your hotel cannot reverse.

Ask about tiering: some actions run directly, some need one confirmation, the most sensitive need two. Ask which actions sit in which tier, who set the tiers, and whether the hotel can change them. The MCP specification's tools section (opens in a new tab) states that, for trust, safety and security, there should always be a human in the loop with the ability to deny an action, that applications should show which tools are exposed to the model, signal clearly when one is used and ask the user to confirm, and that tool usage should be logged for audit (protocol version 2026-07-28).

Undo is the other half. For each action, ask what reversal means in practice: a rate change can be reversed, a message already sent to a guest cannot. Ask the vendor to name the irreversible actions out loud. Then ask to see one record entry. It should show what changed, when, on whose authority and what the previous value was. Ask whether entries can be edited or deleted, and by whom.

Watch for approval fatigue. A system that asks for confirmation on everything gets clicked through, so ask how many confirmations a normal front-desk shift produces. For example, a price suggestion that arrives with its reasons and waits for the revenue manager is a different product from one that changes the rate at three in the morning. Ask which one you are buying; see also AI rate recommendations: what a revenue manager should check.

Where is your hotel's data stored and processed, and how is it kept apart from other hotels?#

Ask for the country or countries where data is stored and where it is processed, in writing, and ask at what level one hotel's data is separated from another's.

Stored and processed are two different questions. A system can keep guest records in one country and send them to a model running in another. Ask both, and ask separately about the AI features. Ask for the answer in the contract or a signed annex: a verbal answer in a sales meeting is not a commitment and cannot be enforced later.

On separation, ask at what level tenants are separated, whether database, schema or row, and ask what stops one hotel's query from returning another hotel's rows. "We use a shared database" is an answer. "It is secure" is not. Then ask about backups: where they live, how long they are kept, and whether deleting a record also removes it from backups. Finally, ask for the list of sub-processors, including the model provider, and ask to be notified before the list changes.

If the vendor cannot answer, that is itself an answer. Write it down and price the risk before you sign. These questions sit inside the broader PMS purchase; see How to choose a hotel PMS in Türkiye: questions to ask vendors.

Who is responsible for guest data, and how do you leave with it?#

Your hotel is normally the data controller for guest data and the vendor is a processor acting on your instructions. Put the roles, the export and the exit in the contract, and have your lawyer read them.

In plain words: the controller decides why and how personal data is processed; the processor carries it out on the controller's instructions. For guest data, that normally makes the hotel the controller. Article 12 of Law No. 6698 (opens in a new tab) requires the controller to take all necessary technical and administrative measures for an appropriate level of security against unlawful processing and unlawful access, and makes the controller jointly responsible with anyone processing data on its behalf (Mevzuat Bilgi Sistemi, Kişisel Verilerin Korunması Kanunu, Madde 12, 2026). In practice you can outsource the work, not the duty. Confirm your own position with counsel.

Ask what the vendor does when it receives a request directly from a guest, and what it does when you give an instruction it believes is unlawful. Ask what happens after a data breach: who informs whom, how quickly, and in what form. Do not accept a verbal answer here. On exit, ask about the notice period, what happens to the data after termination, a written deletion confirmation, and how long your hotel keeps read access during the transition. Ask to see a sample export before signing rather than after, and never accept "we are compliant" as an answer: ask which measures, and ask to see the record that proves them.

How was the model chosen, how is it tested, and what happens when it is wrong?#

Ask which models the vendor uses, how it decided between them, and what fixed test set proves the choice. Then ask what the assistant does when it does not know.

Ask whether the architecture is tied to one model or can swap models per deployment. Models change every few months, and a product welded to one carries an expiry date. Ask for the evaluation: a fixed set of cases drawn from real hotel work, with expected answers, run before every change. Ask how many cases, who wrote them, and whether results are published or only described.

Ask for the failure path. When the assistant is unsure, does it say so, hand the task to a person, or answer confidently and wrongly? Ask to see a recorded case where it refused. Ask what happens to conversation data: whether it is used to improve the vendor's or the model provider's systems, and whether you can opt out. Ask how a model change reaches your hotel: silently, with a release note, or with your approval. Then test it yourself before staff or guests do; see How to test a hotel AI assistant before staff or guests use it. Ten real questions from your own front desk tell you more than a slide about accuracy.

What are the warning signs in an AI sales meeting?#

Most warning signs are about what the vendor will not put in writing. Treat the phrases below as questions, not as verdicts, and ask for the document behind each one.

A promised percentage with no source, no baseline and no date: ask what was measured, on which properties, and when. "Fully automatic" offered as a selling point, with no tier list and no approval step anywhere in the demo. No way to read the record of what the assistant did: if you cannot see the history, you cannot audit it or explain it to a guest.

A certification shown as a logo with no certificate, scope or date: ask for the document and the audit body, and verify it with the issuer yourself. A certificate also says nothing about what the assistant is allowed to change. Refusal to name where data is stored and processed, or a promise that data never leaves, with no clause in the contract. A demo where every feature is described in the present tense and no feature carries a status label. Pressure to sign before a trial on your own data, or a trial offered with no agreement about what happens to the data at the end.

What to do next#

Turn these questions into a one-page scorecard: one row per question, one column for what the vendor said, one for what you saw on screen, one for what is in the contract. Send it before the next meeting so the vendor can prepare real answers. Score evidence, not presentation, and do not sign until the hosting, processing, separation and exit answers have moved from the middle column to the last one.