What permissions should an AI assistant get at a hotel? Reading, drafting and acting

Give an AI assistant three levels, not one switch: read (it can look), draft (it can prepare, a person sends) and act (it can change something). Scope each level to the records and dates the task needs, set an expiry, name who approves each action, and log what it did. AI assistant access permissions at a hotel are three separate decisions, not one.

A general manager opens the assistant's settings and finds one switch: connected, or not connected. Behind that switch sit the rate screen, the guest list and the send button. This article gives you a working method instead: three permission levels, a way to scope each one, a rule for when a person must approve, and a one-page table you can fill in for any assistant you evaluate.

What are the three permission levels for a hotel AI assistant?#

Three: read, draft and act. Read lets the assistant look at records, draft lets it prepare something a person must approve, and act lets it change a record or send something without a further step.

Read means the assistant can query reservations, rates, occupancy and housekeeping status, and cannot change anything. It is the most useful level and the lowest risk, but it is not risk-free: guest names and stay dates are personal data, so even reading needs a scope.

Draft means the assistant produces a guest reply, a rate suggestion or a report, and nothing leaves the building until a person approves it. Most of the value available to a hotel today sits at this level, because drafting is where assistants are strongest and mistakes are cheapest to fix.

Act means the assistant writes to the system: assigning a room, applying a discount, sending a message, preparing a document. This is the level that needs the most design, not the most enthusiasm.

One switch fails because it forces a choice between an assistant that cannot see the rate it was asked about and one that can change everything. Neither is a decision a manager can defend to an owner after an incident. The three levels are also not a maturity ladder: a hotel can run usefully at read and draft indefinitely, and act should be granted task by task, never as a package.

Keep the words straight while you decide. An assistant answers and prepares; an agent carries out steps on your behalf. The permission question is the same for both, but the consequences are not. If the distinction is new, the glossary of agent, assistant and chatbot terms for hoteliers covers it.

What does scoped access mean, and why does it matter more than the level?#

Scoped access means the permission names exactly what the assistant may touch: which records, which fields, which dates and which outlets. A level without a scope is not a permission, it is a promise.

Scope by record type. An assistant answering how full the hotel is next week needs reservations, room types and dates. It does not need passport scans, payment card data or staff records.

Scope by field. Inside a reservation, the guest name and stay dates may be needed to answer the question. The identity document image and the card details are not, and should be excluded by name.

Scope by date. A rate question rarely needs the full history. Say last 90 days, or the current and next season, and write the range into the permission.

Scope by outlet. A hotel with two restaurants and a spa should not let the restaurant assistant read the spa's bills. Outlet-level scoping is where multi-outlet hotels usually find a leak.

Minimum necessary is also a data-protection habit. The personal data law in Türkiye expects data to be adequate, relevant and limited to its purpose; describe your own position in general terms and confirm it with a legal adviser rather than relying on a vendor's summary.

Should an assistant's access expire, and how do you revoke it?#

Yes. Every permission should carry an end date or a review date, and revocation should be a single action you can test, not a request to a supplier.

Grant access per task where you can. A one-off question, for example comparing this August with last August, needs access for a week. Grant it, answer the question, revoke it. Grant per season for seasonal work: the winter assistant does not need the July rate screen, and the summer assistant does not need last winter's group contracts. Grant per contract: when a trial or a contract ends, access ends on the same day. Put that sentence in the contract, because it is easier to agree before the work starts than after.

Revocation must be testable. After you revoke, ask the assistant the same question and confirm it is refused. A permission you cannot test is a hope. Revocation also has a hard limit: it stops future actions. It does not recall a message already sent to a guest, and it does not delete a document already issued. That limit is why irreversible actions deserve their own discussion.

Name a role, not a person, as the approver, and keep the role current. When someone leaves, their approval rights must not quietly pass to the assistant. Keep a simple list: who granted what, to which assistant, on what date, and when it was revoked. One page is enough, and it answers most auditor questions.

Which actions should need a person?#

Anything that leaves the hotel, costs money or creates a legal record should need a person. Reading and internal drafting can run without one.

The working rule is one sentence: reversible and internal, let it run; irreversible or outward-facing, a person confirms. Write the rule down once and apply it to every new task.

Money comes first: discounts, refunds, complimentary nights and rate changes below a floor. The largest amounts should need two approvals, not one, because a single tired click is the usual failure. Messages to guests come next: a sent message cannot be unsent, so let the assistant draft freely and put the person at the send step, not at the writing step.

Legal records sit in the highest tier. In Türkiye, every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS) and personal data (KVKK). Each hotel should confirm its own scope with an accountant or legal adviser. Inventory has its own rule: an assistant that can hold a room must also be able to release it, and every hold must expire, or the assistant becomes a quiet source of rooms that cannot be sold.

The table is illustrative, not a standard. Fill your own version with your own roles, and label every row with the person who signs it off. For a longer treatment of the approval question, see which hotel AI actions need human approval.

This is also where AI Otel's own design is worth naming. Our PMS assistant is built so that every action it can take sits in one of three safety tiers: some run directly, some need a person's confirmation, and the most sensitive need two. 207 actions, June 2026.

How do you check what the assistant actually did?#

From a record written at the moment of the action, not from memory or a chat transcript. The record should say what was asked, what the assistant proposed, who approved, what changed and when.

A chat transcript is not a record. It shows the conversation, not the change to the reservation, and it usually cannot be searched by room, guest or date. A good record shows the actor (the assistant, named as itself), the action, the value before and the value after, the approver, the timestamp and the scope that was used.

Past entries should only be appendable. If changing or deleting an entry is possible, the record proves nothing, because the first question after a dispute is who could have edited it. The details of what a good record contains are covered in the guide to AI audit trails in hotels.

Read the record weekly at the start. Pick one action the assistant took, trace it end to end, and ask the person named as approver whether they remember approving it. The record is also your answer months later, to a guest complaint, to an owner or to an auditor. Build it while nothing has gone wrong.

And if the assistant borrows a person's login, none of this works: every entry looks like that person did it, including the ones they never saw.

How do you build a permission table for any assistant?#

Write one line per task with six columns, and treat a blank cell as no access. The table is the permission; the settings screen is only where you type it in.

Start from tasks, not from the software's menu. List the ten questions staff actually ask the assistant, then the ten actions it might take. For each line, record the level, the scope, the expiry or review date, the approver and whether the action is logged.

A blank cell means no permission. Say that out loud when you hand the table over, because a blank is otherwise read as "not decided yet, so probably fine". Review the table when a person leaves, when the season changes and after any incident; put those three triggers in the document itself. Keep it where staff can find it, not in an IT folder, because the front office supervisor needs to see what the assistant is allowed to send. One table per assistant: two assistants with one table is how permissions drift.

Plus the rule: an empty cell means no access.

What should you ask a provider before you grant access?#

Ask how the assistant identifies itself, what it can reach, who can revoke it and where the data is processed. If the answer is that it uses your admin login, stop.

Does the assistant have its own identity, or does it borrow a person's login? A borrowed login makes the record useless and revocation impossible without locking a person out. Can you set the scope and the expiry yourself, or does each change need a support ticket? A permission you cannot narrow in an afternoon is not under your control. Can you revoke in one step, and how quickly does it take effect? Ask for the answer in hours, not in business days.

Ask what the assistant sees of guest data, and where it is processed. Ask directly, and do not accept a vague answer. Ask what is logged, for how long, and whether you can export it; if the answer is a chat history, you have a transcript, not a record. Ask what happens when the assistant is wrong: who is told, what is undone, and how fast. A provider without an answer has not thought about the second day of use.

OAuth, in plain words: a way to give a program its own limited key, with a scope and an expiry, instead of handing over a password. The hotel keeps the right to revoke the key, and the record can name the assistant rather than a person.

What to do next#

Take the permission table and fill one line for the assistant you are evaluating today: the task, the level, the scope, the expiry, the approver and whether it is logged. If you cannot name the approver for a line, you are not ready to grant act on it. That is the answer to the whole question: read and draft are decisions you can make this week, act is a decision you make one task at a time. If you want to see how these tiers work in practice, request a briefing at https://ai-otel.com/contact.