Why AI Otel built the safety layer before choosing a model

An AI safety layer for hotels is the set of rules a hotel's AI runs inside: which actions may run alone, which need a person, what is recorded, and how each hotel's data is kept apart. AI Otel built those rules first, then chooses the model by measured evaluation.

A general manager asks the obvious question first: which AI model do you use? It is the wrong first question. A model is a component that gets replaced on a vendor's schedule, while the permissions, records and data boundaries stay with the hotel for years. This article explains what an AI safety layer for hotels actually contains, why the rules should come before the model, and gives you eight questions to put to any vendor before a demonstration.

What is an AI safety layer for a hotel?#

It is the set of rules an AI runs inside, kept separate from the AI itself: what it may do alone, what needs a person, what gets recorded, and whose data it can see. Each part answers a different question. Permission tiers answer "may it do this alone?". The decision record answers "what changed, and can it be undone?". The audit record answers "can I trust the record?". Tenant isolation answers "whose data is this?".

The word "layer" matters. The model sits inside the rules, so replacing the model does not replace the rules the hotel lives with. A safety layer is not a promise about the model's intelligence. It is a set of boundaries that hold whether the model is clever or not.

There is useful public vocabulary for this. The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) (opens in a new tab), which is voluntary, lists the characteristics of trustworthy AI as valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. A hotel can borrow that list as vocabulary for evaluating any vendor, not as a certificate.

For status honesty: in AI Otel's case all four mechanisms are built, and the decision record and audit record run in a public demo environment. Nothing in AI Otel's technology is live, and the company publishes the five status words AI Otel uses so readers can hold it to that.

Why build the rules before choosing a model?#

Because a model is replaceable and the rules are not: a hotel lives with the permissions, records and data boundaries long after any particular model has been swapped out. Models are replaced on a vendor's schedule, not the hotel's. Rules written around one model's habits become obsolete with it; rules written around the hotel's operations do not.

This is why the seam is deliberate. AI Otel's architecture is model-agnostic: models are chosen per deployment by measured evaluation, and no model or vendor name is fixed into the product. You can read more about how AI Otel will choose a model by measured evaluation.

The sequence is not idiosyncratic. The NIST AI RMF 1.0, section 5.3 Measure (opens in a new tab) states that AI systems should be tested before deployment and regularly while in operation, and that measurement should include rigorous software testing, comparisons to performance benchmarks, and formalized reporting and documentation of results. In other words: the test harness exists before the choice. AI Otel's benchmark is built and not yet run, 30 cases and 5 traps, and results will be published when measured.

The order is also what a hotel's auditor, insurer or legal adviser asks about. They ask which actions need a person and what the record shows, not which model answered. The trade-off is real: building rules first is slower and looks less impressive in a short demo. It is what survives the first model swap.

How do safety tiers decide what AI may do alone?#

Every action the assistant can take sits in one of three tiers: some run directly, some need one person's confirmation, the most sensitive need two. In the June 2026 registry snapshot that is 207 actions: 107 run directly, 90 need one confirmation, 10 need two.

An action here means a defined software operation, such as reading a rate, changing a room's status or preparing a message. It is not a chat reply. The registry lists operations, not sentences.

The tiering logic is consequence and reversibility. Low-consequence and reversible actions run directly. Actions that touch money, a guest or a legal record get one confirmation. Actions that combine both, or that are irreversible, get two. For example, illustrative only and not our registry: reading tonight's occupancy might run directly, a rate change might wait for one confirmation, and a refund might need two.

This is a written form of something frameworks already ask for. The NIST AI RMF 1.0, Appendix C, says human roles and responsibilities in decision making and in overseeing AI systems need to be clearly defined, noting that some systems may not require human oversight while others specifically require it. Tiering is that definition written down per action, which is the topic of our companion piece on which hotel AI actions need a person.

The split is the useful part. A hotel can ask for the full list and see which 10 actions need two people, instead of accepting an average. One honest limit: the tier assignment is fixed in code today. It is not yet a slider each hotel sets for itself, and saying otherwise would overstate what is built.

What does the decision record change about hotel AI?#

It makes each change visible and reversible: small changes apply automatically and are logged, larger ones wait for a person, and every change can be undone except a message already sent to a guest. For each change the record holds what changed, when, on whose authority, and what the value was before.

Undo is a mechanism, not an apology. The previous value is restored and the reversal is itself logged, so the record shows both the change and the correction. One case is irreversible: a message already sent to a guest. A rate can be restored; a sent message cannot be recalled, so the record says so instead of pretending otherwise.

There is also a legal reason to keep a person in the loop. Article 11 of Law No. 6698, Türkiye's personal data protection law (consolidated text, June 2024), gives a person the right to object to an outcome against them that arises solely from analysis by automated systems. A person confirming sensitive actions is how that right is honored in daily work. Confirm your own case with a legal adviser.

What does a tamper-evident audit record prove?#

That alterations are detectable, not that they are impossible: past records can only be appended, changing or deleting them is closed in the database, and if someone still alters one, the chain shows it.

Definition first. The NIST Computer Security Resource Center glossary (opens in a new tab) defines "tamper evident" as a process which makes alterations to the data easily detectable. Detectable, not prevented. The same glossary, citing SP 800-53 Rev. 5, defines an audit trail (opens in a new tab) as a chronological record that reconstructs and examines the sequence of activities surrounding or leading to a specific operation, procedure or event, from inception to result.

The mechanism in plain words: each entry carries a fingerprint of the entry before it, so removing or editing one breaks the chain at that point. It does not stop an administrator with database access from trying. It makes the attempt visible to the next person who reads the record.

Why a hotel cares: a dispute with a guest, an agency, an accountant or an inspector becomes a matter of reading a record rather than reconstructing memory. Words to keep out of any vendor's answer: tamper-proof, blockchain, "cannot be deleted". Each one overstates what is built. AI Otel's audit record is built and runs in a demo environment, and it is tamper-evident, nothing stronger.

Why is each hotel's data separated before any cross-hotel learning?#

Because a hotel's data is its own, and separation has to exist before anything is designed to learn across hotels: each hotel's data is separated at the database level. In plain words, one hotel's records cannot be reached from another hotel's session, and the boundary is enforced in the database rather than in a screen.

This is also a legal duty, not only good engineering. Article 12 of Law No. 6698 (consolidated text, June 2024) (opens in a new tab) requires the data controller to take all necessary technical and administrative measures to prevent unlawful processing of and unlawful access to personal data and to ensure its safekeeping, and to notify the person concerned and the Board as soon as possible if data is obtained unlawfully. Separation is one of those technical measures.

Order of operations matters. Isolation comes first. The Platform Brain, designed to learn patterns across the network with privacy thresholds so that no single hotel can be identified, is architected and not trained. The principle in one line: three levels of brain, one promise, a hotel's knowledge stays its own. That line is architected, and should be labeled as such.

A check any buyer can run: ask where separation is enforced, and whether it is a display setting or a database boundary. One thing this section does not claim: moving hosting and AI processing into Türkiye is on the roadmap, and until it is done, it is not claimed.

What should a hotel ask of any AI inside its operations?#

Ask for the list of actions and their tiers, the record of what changed, the audit trail, and where data separation is enforced. A vendor that cannot show these is asking for trust instead of evidence. The questions below work on any system, not only ours; they are the practical output of the whole article. For context on AI Otel's own order of work, see what AI Otel is building, and in what order.

In our own case: the PMS assistant carries out routine actions and a person confirms anything sensitive, with 207 actions in three tiers (registry snapshot, June 2026); the decision record and audit record are built and run in a demo environment; each hotel's data is separated at the database level. And the honest zero, in our own words: we have no trained model yet, and the product says so on screen. What exists is the architecture, the decision infrastructure a model would run inside, and a benchmark to choose the model.

What to do next#

Before any demonstration, ask the vendor for the full list of actions the AI can take, the tier each one sits in, and where data separation is enforced. The parts of this article fit in one order: rules first, because a hotel lives with them; the model second, because it is chosen by measurement and replaced on someone else's schedule. AI Otel's own status is published on the trust page, and you can request a briefing at info@ai-otel.com.