AI in hotel guest service: how to use it without breaching the LGPD

Why AI in guest service is, first of all, personal data processing

A chatbot that answers booking questions, an assistant that confirms check-in times on WhatsApp and a tool that summarises a guest's history for the front desk have something in common: to work, they need to read the guest's name, phone number, booking number and sometimes preferences and stay history. That is personal data processing in the exact sense of the LGPD, regardless of whether the team thinks of the tool as "guest service technology" rather than as a "system that holds guest data".

The risk is not in the AI itself. It lies in adopting these tools through marketing or operations without the same compliance assessment that would apply to replacing a PMS or a payment gateway. When that happens, the hotel often finds out months later that guest data is being processed (and sometimes stored) on an AI supplier's servers with no processor contract, no security clause and no defined retention period.

Where generative AI is entering hotel operations today

• WhatsApp and Instagram chatbots: answer frequently asked questions, capture contact details and, in many cases, already have read access to the PMS to confirm availability and booking status.
• Voice assistants and AI call centres: transcribe and sometimes record guest calls to train future answers. The recording and the transcript are personal data, and the guest must be told that the call is recorded and why. If the tool uses voice characteristics to identify the guest, that becomes biometric data, which the LGPD treats as sensitive data (art. 5, II).
• Summarising and triage tools: used by the front desk or reservations to summarise a guest's emails, messages or history before a conversation.
• Personalisation and recommendations: suggestions for upsells, packages or marketing messages based on previous stays and guest behaviour.

Each of these categories has a different legal basis and level of risk, but they all share the same blind spot: the guest's data leaves the PMS or the service channel and starts to exist inside the AI supplier's infrastructure as well.

The legal bases that apply

Performance of a contract: covers most legitimate operational service, such as confirming a booking, giving the check-in time or answering questions about the contracted stay. It does not require separate consent, but it does require the use of AI to be proportionate to that purpose.

Legitimate interest: can support using AI to improve service quality or detect booking fraud, as long as the hotel documents a balancing test (the benefit outweighs the risk to the data subject) and explains it in an accessible way, for example in the privacy policy.

Consent: tends to be the appropriate basis when the purpose goes beyond providing the accommodation service, such as using a guest's history to train the hotel's own model, generating personalised marketing recommendations across the group's brands, or sharing data with a commercial partner. Generic consent hidden in long terms of use does not meet the LGPD standard; it has to be specific to that purpose. Consent is not the only option either: depending on the case, another basis in art. 7 may be more appropriate, and that choice should be documented and validated by the hotel's legal advisers.

The AI supplier is usually a processor, not a bystander

When the hotel connects a chatbot, voice assistant or summarising tool to real guest data, the hotel remains the controller and the tool's supplier generally acts as a processor under art. 5, VII, of the LGPD. If the supplier uses that data for its own purposes, such as training its models, it may also become a controller for that processing. That is why the contract needs to define the role of each party, and many guest service SaaS contracts signed without legal review do not do this properly. In practice, the contract should cover:

• A clause that prohibits the supplier from using the hotel's data to train general-purpose models, unless this is explicitly authorised, and that states how long conversations and logs are kept.
• An obligation to notify the hotel within a defined period if there is a security incident in the supplier's infrastructure.
• A clear definition of where the data is processed and stored, and which subcontractors (such as the provider of the language model behind the tool) have access to it. When the data leaves Brazil, the international transfer needs one of the mechanisms set out in the LGPD and regulated by the ANPD, Brazil's data protection authority, in Resolution CD/ANPD No. 19/2024, such as standard contractual clauses.
• A retention period and a process for deleting data at the end of the contract or at the data subject's request.

If the AI supplier has an incident, the controller's obligations stay with the hotel: assessing the incident, deciding on notification to the ANPD and to the affected guests, and responding to them. The supplier can also be held liable as a processor, but that does not take the hotel out of the front line. A well-drafted contract does not prevent the incident, but it defines the supplier's security obligations, how quickly it must tell the hotel and how it cooperates in the response.

Data that, as a rule, should not reach a third-party AI service tool

Not every piece of information that passes through the front desk needs to (or should) feed a chatbot or AI assistant. As a practical rule, keep the following out of the flow of any AI guest service tool:

• Full payment card numbers or checkout details, even when the guest types them into a conversation unprompted. A chatbot that receives or stores card data tends to bring the tool, and the supplier, into PCI DSS scope; the safer path is to reply with a payment link from the hotel's gateway. More on this in our guide to PCI DSS for hotels.
• Copies or numbers of identity documents beyond what in-person check-in requires.
• Sensitive data as defined by the LGPD (health, racial origin, sexual orientation, among others), which rarely has anything to do with accommodation service and should not be requested or processed by a third-party AI.

This applies both to what the guest types directly and to what the tool automatically retrieves from the PMS to build a reply. A badly configured integration that gives a chatbot broad read access to the guest record, instead of only the fields it needs (name, booking status, dates), is a frequent mistake in this kind of project.

Actions, authentication and escalation: the risks specific to AI

Beyond the LGPD, an AI guest service tool brings risks that a form or an email does not. Three of them deserve attention before any integration with the PMS or the booking engine:

• Unsupervised actions: an AI allowed to change, cancel or refund bookings can be induced to do so by a carefully crafted message (what OWASP calls prompt injection) or can misread a request. In general, the AI can look things up and prepare the action, but changes, cancellations, refunds and payments should require confirmation by a person or by the guest through a verified channel.
• Weak authentication: booking numbers, names and phone numbers appear in confirmation emails, OTA statements and screenshots. They are fine for answering general questions, but not enough to reveal booking details or change them. For sensitive operations, use a code sent to the email or phone number on file.
• Escalation to a person: guests need to be able to reach a person when the AI cannot resolve their issue, and the conversation should reach the front desk or reservations with its history, so the guest does not have to repeat everything.

A practical example: a guest asks on WhatsApp what time check-in is and whether the booking is confirmed. The chatbot replies using only the booking status and dates. If the guest asks to change the dates, the chatbot confirms their identity with a code sent to the email on file and passes the request to reservations with the conversation history. If the guest sends a photo of their card, the tool does not keep the image and replies with the gateway's payment link.

A practical checklist before switching on any AI guest service tool

1. Map exactly which guest data the tool will read, store and (if applicable) use for training.
2. Define the legal basis for each purpose, and update the privacy policy if the purpose is new.
3. Review the supplier contract: processor clause, incident notification, place of processing and retention.
4. Limit the scope of the PMS integration to the minimum the tool needs to work.
5. Set the limits in writing: which topics or data the AI must never handle, and where to escalate when that happens.
6. Require identity verification and human confirmation before any change, cancellation, refund or payment.
7. Make sure guests can reach a person, and that the conversation reaches the team with its history.
8. Set the retention period for conversations and logs, and who on the team can consult them.
9. Test before going live: try to make the AI reveal data from another booking or ignore its own rules.

Next steps

Adopting AI in guest service does not mean giving up compliance, but it does mean treating the decision with the same rigour as any other system that accesses guest data. Many problems in this kind of project come from skipping the mapping and contract stage because "it is just a chatbot", the same mistake that has already exposed hotels in other areas, such as payments and guest networks.

This connects directly to the hotel's overall LGPD compliance and to how it governs technology suppliers as a whole; the broader picture is in our guide to AI governance in hospitality. Our team can assess an AI tool before you sign, review the supplier contract and map the data flow between the PMS and any guest service assistant. Talk to our team.

Sources

• Lei nº 13.709/2018 (LGPD), arts. 5, 7, 11, 33 and 42 (in Portuguese), planalto.gov.br
• ANPD, Resolução CD/ANPD nº 19, de 23 de agosto de 2024 (international data transfer regulation and standard contractual clauses, in Portuguese), gov.br/anpd
• OWASP, Top 10 for LLM Applications 2025 (LLM01 Prompt Injection and LLM06 Excessive Agency), genai.owasp.org