AI washing: how to tell a real feature from a new label in a hotel software demo

AI washing is describing software as artificial intelligence when the work is done by a fixed rule, an ordinary report or a person. It is a labeling problem, not a technology problem. In a demo, test the claim: change the input, ask it to fail, and ask for the status in writing.

Halfway through the demo the presenter says the system uses artificial intelligence to set the rate, and a slide appears with a curve on it. Nobody in the room asks what happens when the curve meets a room type you do not sell, and the meeting moves on to the next slide. After reading this, you will have the questions to ask in that moment, the tests to run in ten minutes, and a one-page way to score what you actually saw.

What is AI washing, and why is a rule that works not a problem?#

AI washing is the gap between what a product does and what its label says: a fixed rule, a standard report or a person doing the work behind a screen that says artificial intelligence. The label is the problem, not the rule.

A demo can show you three different things, and only two of them can be tested in the room. The first is working software: it computes something you can check against your own numbers. The second is a rule: a person wrote the condition, and you can ask to see it. The third is a promise about a future version, which does not exist yet.

A rule is often the better engineering choice. A rule that says a booking of ten rooms or more goes to the sales manager behaves the same way every time, can be read by a person, and can be explained to new staff. When a simple rule does the hotel job better than a model, write the rule and keep the model out of it.

The mechanism of a rule is simple: a condition, a threshold and an action, all written by a person, all inspectable. When it fails, you trace the failure to a condition. When a model fails, you often have nothing but the wrong output.

The cost of the wrong label is concrete. You budget for a capability, you plan staffing around it, and you cannot write an acceptance test, because nobody has told you what the thing is supposed to do. A purchase built on a label cannot be verified at handover.

There is also a legal frame, in general terms. Article 9 of the Commercial Advertising and Unfair Commercial Practices Regulation, rewritten in the Official Gazette of 4 January 2017 (No. 29938) and unchanged by the amendment of 1 July 2026, places the burden on the advertiser to prove verifiable factual claims with scientifically valid information and documents, and requires documents from accredited or independent research, testing and evaluation bodies for claims compared in comparative advertising, according to the consolidated text on mevzuat.gov.tr (opens in a new tab). Confirm your own case with a legal adviser.

No public count exists of how many hotel products carry a mislabeled feature, so this article makes no claim about how common the practice is.

Before the demo, what should you bring into the room?#

Bring ten questions from your own operation and one messy file, and write down the answer you expect before the presenter speaks. A demo on the vendor's clean sample data tells you about the sample data.

Take ten real questions from last month, not from a brochure: tonight's rate for a specific room type, rooms left to sell on a date, what a group block has picked up, why a bill was corrected, which reservations have no identity notification yet, what housekeeping has left for a room, what happens to a no-show, how a split bill is closed, what a refund looks like on the record, and what the system shows when a rate changed mid-stay.

Export one month of your reservations, unedited, with the real problems in it: cancelled rows, a duplicate guest, Turkish characters, empty columns and one row a person typed badly. Ask in advance, in writing, whether the presenter will use your file or theirs. A refusal is an answer you can record.

Write the expected answer next to each question before the meeting. During the demo you mark right, wrong or not shown, and you stop arguing about impressions. Bring the person who will actually use the screen, not only the buyer; they notice the steps the presenter skips.

Decide before the meeting what you will not accept as evidence: a slide, a video, a customer logo, or a sentence that begins with the phrase "other hotels".

Live or recorded: how do you know the demo is real?#

Ask the presenter to change the input, live, to something that was not in the script. A recording cannot accept a value you type, and a scripted path usually breaks the moment the input is unfamiliar.

Ask for a date outside the prepared range, a room type you do not sell, or a guest name with a Turkish character in it, and watch what happens on screen. Watch the mechanics, not the story: does the presenter type, or does the screen move on its own? Is there a wait while something is calculated, or does the answer appear before the question is finished?

Ask what the system does with an empty result. Software that has been used answers this quickly; a prepared path often has no answer.

A recorded walkthrough is legitimate for a feature that is designed but not built, as long as it is labeled that way. It is not evidence of working software. Ask who is in the recording: a person behind the screen is a valid way to run a hotel, but it is not a feature you are buying. If the presenter declines the change of input, note it and move on. You have your result for that row.

How do you make an AI feature fail on purpose?#

Give it something it cannot know, something it should refuse, and then ask where its last number came from. A working system fails visibly and says so; a label changes the subject.

Ask about a facility your property does not have, a restaurant that closed, or a rate for a room type outside your inventory. A working assistant says it does not have that, and a rule simply does not fire. Ask about a period with no rates loaded or a date in the past, and watch whether the answer is a refusal, an empty state, or a confident number with nothing behind it.

Then ask it to cancel a booking, move money, or send a message to a guest. A system with safety tiers asks for a person; a system without them does it, and that is the more worrying result. Ask where the number on screen came from: working software points to the record or the rule; a scripted demo points at the presenter.

Ask what is written down afterwards. Is there a record of what the assistant did, can you see it, can you undo it, and can anyone edit the record later? Treat silence as data: a presenter who will not run a test has told you the status of that feature without using a word. A written test plan, run before staff or guests touch the assistant, turns those questions into answers you can compare.

Three tests you can run in ten minutes#

What do the words mean: AI-powered, built, designed, coming soon?#

AI-powered is not a status, it is an adjective. Ask for one of four states in writing: in use at hotels today, built but ahead of launch, designed, or planned.

Each state tells you something different as a buyer: whether you can test it now, whether you can plan a cutover around it, or whether you are buying a date. Ask which part of the feature is the model and which part is a rule, and ask them to point at the boundary on screen. A vendor who can answer this is describing their own system; one who cannot is describing a category.

Ask for the record: what the system logs, whether you can read it, whether a person confirms sensitive steps, and whether a change can be undone. A feature that cannot be inspected cannot be audited later. Ask what happens when the feature is wrong: a rule is wrong in a way you can trace to a condition; a model is wrong in a way you can only catch with a record.

Do not sign for a roadmap item and do not plan staffing around it. If it arrives, you will test it then, on your own data, with the same three tests. Put the answer in the contract language you already use: the claim, the status word, and the date the vendor gave you.

After the demo, how do you score what you actually saw?#

Fill one page: for every claim, write what was claimed, what you saw with your own eyes, and the status word the vendor will put in writing. Send it back and ask them to correct it.

Score each claim on three levels: demonstrated on your data, demonstrated on their data, described only. The middle level is not worthless, but it is not the same as the first. Keep the ten questions and their expected answers on the same page, so the score is about your operation and not about the presenter's manner.

Send the page to the vendor and ask for corrections in writing. A vendor who corrects it is telling you something useful; one who ignores it is telling you something too. Use the same page for every vendor you see, so the offers are comparable line by line rather than by impression.

Separate the buying decision from the labeling decision. You may still buy a product whose AI claim was overstated, if the rule underneath does the job you need. Keep the page: when the feature ships, you test it against the same three tests and the same ten questions.

Before you get to a demo, write your questions down and send them in advance, so every vendor answers the same set. To make offers comparable across vendors, put the same requirements document in front of each one and ask for a written response to each line.

What to do next#

Take one page into the next demo: your ten questions with the answers you expect, one messy export from your own system, and three columns for claim, what you saw and the status word in writing. The parts of this article fit together as one habit: name what the thing is, change the input so you can see it work, make it fail once, then write down what you saw before you sign. A rule that works is a good purchase; a label you cannot test is not.