Is It GDPR-Compliant to Let AI Answer Guest Emails?

Yes, under conditions. A hotel can lawfully let AI read and answer guest emails if it has a lawful basis for each purpose, a data processing agreement with the vendor, data minimisation in practice, transparency towards the guest, and a human decision point wherever the outcome materially affects that guest. This guide explains each condition.

Last updated 20 August 2026.

This is not legal advice. We build hotel software, we are not lawyers, and compliance depends on facts specific to your properties. Take your own counsel, or run this past your data protection officer. What follows is written as an operator's guide to the questions a hotel should ask a vendor, which is both safer and more useful than a legal opinion from a company that sells the product.

One note on scope. This page is about the GDPR, and since 2 August 2026 there is a second regime sitting alongside it: the transparency obligations in the EU AI Act. They are separate laws with separate regulators, and meeting one does not meet the other. There is a section on the AI Act below.

What personal data is actually involved when AI reads a guest email?

More than most vendors admit, and one category more sensitive than most hotels expect. A reservations inbox carries names, contact details, stay dates, rates and booking references. It also carries dietary and accessibility requests, and those can be a different thing entirely under the law.

The Article 9 point is the one worth sitting with. Article 9 of the GDPR prohibits processing of data revealing health, religious belief and several other categories, unless a specific exception applies. Hotels have always handled this data. What changes when AI enters the inbox is that the data is now flowing through an additional system, run by an additional company, and your documentation needs to say so.

Is the hotel the controller or the processor?

The hotel is the controller. The AI vendor is a processor. That is the normal arrangement and it decides who is accountable for what. The EDPB's guidance on the two roles is the reference point if you need to argue the case internally.

Practically, controller status means four things sit with you and not with your vendor. You decide the purposes and the means. You own the lawful basis. You answer the guest when they exercise their rights. You are the one a supervisory authority contacts.

The vendor's obligations run through Article 28: process only on your documented instructions, keep the data confidential, apply appropriate security under Article 32, engage no sub-processor without your authorisation, help you respond to guest requests, and delete or return the data when the contract ends. If a vendor tells you it is jointly responsible for compliance, ask what it means. Compliance is a property of how you use a tool, not of the tool.

The stakes are set out in Article 83: the upper tier of administrative fines reaches 20 million euros or 4% of total worldwide annual turnover, whichever is higher. For a group, that is calculated on group turnover.

What lawful basis applies to AI answering a guest email?

It differs by purpose, and more than one basis can apply inside a single email thread. This is the detail most often collapsed.

Contract performance, Article 6(1)(b). Handling an enquiry about an existing booking, or steps taken at the guest's request before entering a contract. This covers the bulk of reservations mail.

Legitimate interests, Article 6(1)(f). Operational uses such as quality review, service level monitoring or fraud prevention. Requires a documented balancing test, and the guest can object.

Consent, Article 6(1)(a). Marketing. Also the realistic route for special category data under Article 9(2)(a), which requires explicit consent rather than ordinary consent.

A single thread can move across all three. A guest asks about availability, mentions a wheat allergy, and later receives a newsletter. Those are three purposes and three bases, and your record of processing activities should show them separately.

Does Article 22 apply to AI replying to a guest?

Usually not, and it is worth being accurate about this rather than overstating it to make a product look necessary.

Article 22 restricts decisions based solely on automated processing that produce legal effects or similarly significantly affect the individual. Three conditions have to be met together: a decision, taken solely automatically, with a legal or similarly significant effect. Answering an availability question almost certainly fails the third condition. Sending a rate quote does not decide anything about the guest's rights.

Some actions sit closer to the line. Cancelling a booking without human involvement. Refusing a rate or a stay to a specific guest on the basis of a profile. Applying a penalty charge. These alter a contractual position, and the argument that they only similarly significantly affect the guest is at least arguable.

Two points from case law and guidance are worth knowing. In Case C-634/21, decided on 7 December 2023, the Court of Justice of the European Union held that an automated probability value produced by one company can itself be an automated individual decision when a third party relies heavily on it. The scope of Article 22 is therefore wider than a narrow reading suggests. Separately, the EDPB's position is that human involvement must be capable of changing the outcome. A person who clicks approve without the authority, information or time to overturn the suggestion is not human involvement in the sense the regulation means.

The practical conclusion is unglamorous. Most guest email handling falls outside Article 22. The subset that might fall inside it is small, identifiable in advance, and easy to route to a person. That is a configuration decision, not a legal problem, provided your tool lets you make it per action type.

What does the EU AI Act add on top of GDPR?

A disclosure duty, and it is already live. Article 50 of the AI Act, Regulation (EU) 2024/1689, became applicable on 2 August 2026 and is enforceable by national authorities from that date.

This is worth stating plainly, because a lot of boards heard the opposite. The AI Act was widely reported as delayed in mid-2026, and the high-risk provisions were: the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the Annex III high-risk deadline to 2 December 2027 and the Annex I deadline to 2 August 2028. Article 50 was deliberately left out of that deferral. If your compliance plan was built around the high-risk cliff, you gained sixteen months. If it touches anything that talks to a guest, nothing moved at all.

The obligation itself is short. An AI system intended to interact directly with a natural person must be designed and operated so that the person is informed they are dealing with an AI system, unless that is obvious from the context. A website chat widget or a WhatsApp thread answered by an agent is squarely in scope. Email is the more interesting case, and the answer turns on your autonomy setting rather than on your vendor.

If someone on your team reads the suggested reply, can change it, and sends it, a person sent that email. If the reply goes out on auto-send with nobody in the thread, the guest is corresponding with software and has not been told. That second case is where the disclosure belongs. The practical rule is that the disclosure requirement scales with the autonomy level, which makes it a configuration question in exactly the same way approval is.

Two further points for a procurement conversation. Article 50(2) requires machine-readable marking of AI-generated content, and systems already on the market before 2 August 2026 have until 2 December 2026 to comply, so ask your vendor where that work stands rather than assuming it is done. And AI Act transparency breaches sit in a fine tier of up to 15 million euros or 3% of worldwide turnover, which is exposure separate from and additional to Article 83 of the GDPR.

Note also that Article 50 splits duties between the provider of the system and the deployer of it. The vendor builds the capability. You, as the hotel, decide whether it is switched on. Neither of you can point at the other.

What should a hotel ask an AI vendor before signing?

Thirteen questions. They apply to any vendor in this category, including ours, and the third column matters as much as the first.

How does data residency work for EU hotels?

If processing and storage stay inside the EEA, there is no international transfer and Chapter V does not apply. That is the simplest position and the one to aim for.

If data leaves the EEA, you need a transfer mechanism. An adequacy decision by the European Commission is the cleanest: the destination is treated as offering essentially equivalent protection, and no further instrument is required. Standard contractual clauses are the usual fallback, and since Schrems II they come with an obligation to assess the destination country's laws and add supplementary measures where the clauses alone are not enough.

Two practical notes. A US-hosted vendor is not automatically a problem, but it is a question with a documented answer rather than a shrug. And adequacy is not permanent: the renewed EU adequacy decisions for the UK, adopted in December 2025, run to 27 December 2031 and are monitored throughout. Build a review date into the contract rather than assuming today's position holds.

What does human in the loop actually mean in practice?

It means a person who can change the outcome, not a person who clicks approve. The distinction is the whole point, and it is where a lot of vendor language goes soft.

Rubber-stamp approval, where a reviewer sees fifty suggestions an hour and approves forty-nine, is not meaningful review. Genuine review requires authority to override, access to the underlying data, and enough understanding of how the suggestion was produced to disagree with it. The ICO's guidance on AI and data protection is the most readable treatment of this if you are building the internal case.

Which is why a single approval switch is the wrong shape. If everything requires review, reviewers stop reading, and the control becomes theatre. If nothing does, you have no control at all. The defensible configuration is three levels set per action type, per property and per risk level: draft only, approve before sending, or send automatically.

And there is a second decision hiding inside the third level. Setting an action to auto-send decides two things, not one. It decides that nobody reviews the message, which is the GDPR question this page started with. It also decides that a machine is now corresponding with your guest under your hotel's name, which is the AI Act question. Where a reply goes out with no person in the thread, say so in the reply. It costs a line and it removes the argument entirely.

A control that fires on every message is a control nobody reads. Let a parking question send itself, and make a cancellation wait for a person. That is what makes the review real when it happens.

Kristoffer Pedersen, co-founder, Altek AI

That granularity is also what makes the Article 22 question answerable. If the small set of actions that could significantly affect a guest is routed to a person by configuration, you are not arguing about whether Article 22 applies. You have removed the condition that would trigger it.

How Altek handles this

Everything above applies to any vendor. This section is about ours, and it is at the end deliberately, because the rest of the page should be usable whether or not you ever talk to us.

Altek processes and stores data in dedicated cloud regions, with the region that applies to your properties named in your DPA. Today that is the EU. A Data Processing Agreement is available, data flows are documented, and retention policies are under your control. The sub-processor list and current certification status are in the security pack, available on request. ISO 27001 and SOC 2 processes are underway and not yet complete, and we will say certified when the audits say so and not before.

On model training, the answer is no, with a distinction most vendors skip. Altek does not train or fine-tune AI models on hotel data. What it does do is measure which replies convert at your property and use that to optimise the prompt itself, so the system gets better at your hotel over time. Training a model and tuning a prompt are different mechanisms, and a vendor that answers only the first half has not answered the question. Ask any vendor, including us, for both answers in writing.

On execution, permissions are defined by property and by action. Altek requests only the access scopes needed for the operations you enable, per system, and every execution is recorded in an audit trail. Approval is the default rather than the ceiling: three levels per action type, configured per property and per risk level. Human approval on every action is the starting configuration.

On disclosure, where a reply is sent automatically with nobody in the thread, Altek tells the guest they are dealing with AI. At the draft and approve levels a member of your team reads the reply and sends it, so a person sent that email. That is the Article 50 point in its practical form: the disclosure follows the autonomy level, which means it is set in the same place and at the same granularity as the approval rule.

We are not going to tell you Altek is GDPR compliant, because that is not a property a piece of software can have on its own. It is a property of how your hotel uses it, on your lawful basis, with your retention policy and your approval configuration. What we can do is answer all thirteen questions above in writing before you sign.

Altek handles hotel email end to end. It reads each guest inquiry, retrieves live availability and reservation data from the hotel's PMS, writes the reply and carries out the work behind it, including reservations, modifications, restaurant and spa bookings and payment links, with human approval on every action. Altek works with Mews, Opera Cloud and Visbook/BookVisit, and is used by 115 hotels across eight countries. Founded in Norway, headquartered in Oslo.