What Guest Data Should Hotels Avoid Putting Into Public AI Tools?

Hotel staff should not paste identifiable guest records, identity documents, payment information, sensitive requests or confidential case histories into an unapproved public AI service. A tool being easy to access does not establish that the hotel is authorised to disclose information to it. The practical rule is to use approved public material or genuinely fictional examples for ordinary drafting, and to route any proposed use of real guest data through the hotel's defined review process.

This guide focuses on the everyday decisions a Cyprus hotel team faces: translating a complaint, drafting a reply, analysing booking patterns or preparing training examples. It distinguishes an unapproved consumer tool from a separately assessed business implementation, without assuming that a paid account, a private-looking chat or a local installation automatically makes every use compliant. The hotel needs a purpose, appropriate arrangements and controls for the actual data flow.

Understand what counts as guest data

Personal data is broader than a guest's name. The EDPB identifies booking references, contact details, location information and other information linked to an identifiable person as examples. Removing a name therefore does not necessarily remove the personal nature of a reservation record. A combination of stay dates, room number and a distinctive event may still identify someone in context. [1]

Think about what the proposed prompt reveals when combined with other information. A description of the only wedding party staying on a particular weekend may identify people even if the organiser's name is removed. A complaint mentioning an employer, flight and unusual request can be similarly revealing. The assessment concerns the information as a whole, not whether one obvious identifier has been deleted.

The hotel's policy should cover text, spreadsheets, screenshots, photographs, audio and attached documents. Staff may understand that a guest database is sensitive while overlooking a screenshot of the same database in a support conversation. An attachment can also contain hidden columns, comments or metadata. The upload format does not change the underlying question of whether the information may be shared.

Keep identity documents and registration records out of unapproved tools

Passport images, identity-card scans and completed registration forms should remain within the hotel's approved processes. They can combine several identifiers in one file and may include information irrelevant to the task an employee wants AI to perform. Asking a public tool to extract a name or improve a document's readability is still a disclosure of the uploaded material.

If the real need is to explain the registration process, draft a generic instruction using a fictional example. If the need is operational document processing, assess an appropriate solution specifically for that purpose, including access, retention, accuracy and the applicable legal requirements. Do not make a consumer chatbot the informal bridge between an identity document and the PMS because it appears convenient.

Train employees to recognise the difference between explaining a workflow and processing a real person's record. A training prompt can describe that a hotel checks an identification document without including an actual scan. Use invented fields and obvious sample values when demonstrating a form. The final operational process should be approved by the people responsible for compliance and system security.

Do not use guest payment information as prompt material

Card numbers, security codes, payment credentials, bank details and sensitive transaction information do not belong in an unapproved general-purpose AI conversation. If an employee needs help wording a payment reminder, the model does not need the guest's card or complete payment history. Draft the generic wording first, then insert the necessary details through the hotel's authorised system.

Keep troubleshooting within the approved payment-provider process. A screenshot intended to explain a failed payment may expose more than the error message. Review what support actually needs, use the provider's secure route and avoid sending credentials or unnecessary financial details. The same caution applies when an AI feature is embedded in another product: determine what data it receives rather than assuming the surrounding brand makes the feature suitable.

PCI SSC explains that outsourcing payment processing does not remove the merchant's responsibility to ensure that the third party protects payment data properly. This is not an invitation to build a separate AI payment workflow without assessment. The hotel's acquiring bank, payment provider and appropriate security advisers should help establish the approved implementation and staff procedures. [5]

Treat health and other sensitive requests with particular care

Guests may share information about allergies, disabilities, illness or personal circumstances so that the hotel can respond appropriately. Those details can be highly sensitive. The EDPB explains that health information and certain other categories receive special protection under the GDPR, with additional conditions for processing. Do not assume that receiving the information for service delivery authorises sending it to an unrelated tool. [1]

For a drafting task, remove the personal case and ask for a general communication structure. For example, request wording that acknowledges a service request and routes it to the responsible team, without naming a condition, guest or stay. The competent staff member can then prepare the actual response using the approved information and process. AI should not invent assurances about safety or suitability.

Keep the operational record in the authorised system with access limited to the people who need it. A broad staff chat or shared prompt library is not the right place to duplicate the guest's circumstances. If a proposed AI solution genuinely requires sensitive information, obtain the specific legal and technical assessment before introducing it, including whether an impact assessment is required for the intended processing.

Avoid full complaint histories and identifiable conversations

A complaint may contain names, booking details, staff identities, payment disputes and information about other guests. Copying the entire exchange into a public tool to obtain a polished reply can disclose substantially more than the writing task requires. A summary prepared by staff should focus on the communication problem and omit the identifiable narrative wherever possible.

For example, a fictional prompt can ask for a calm response to a room-readiness delay, with placeholders for the verified remedy and next contact. It should not include the original guest's name, exact itinerary, room number or medical explanation for why the delay mattered. The employee remains responsible for the facts, the promised remedy and the tone of the actual reply.

Take care with recorded calls and voice notes. A request to transcribe or translate can expose voices and contextual information as well as spoken names. Use only an approved process for real recordings. For training, write a synthetic dialogue that illustrates the service skill without reproducing a recognisable conversation from a particular stay.

Do not assume a public review is unrestricted input

A guest may have posted a review publicly, but that does not settle every question about reusing it in another system. Public availability and permission for a new processing purpose are different issues. If the hotel wants help drafting a response, consider whether a short non-identifying description of the issue is enough rather than uploading a profile, review history and linked personal details.

Avoid building informal guest profiles from reviews, social media and booking records in a general-purpose tool. Combining sources can reveal more than any one source alone. A hotel can analyse broad service themes through an appropriately designed process without asking staff to assemble a detailed dossier on an individual guest.

When using review examples in training, fictionalise the scenario and preserve the lesson rather than the identity. Staff can practise acknowledging a complaint, explaining an investigation and avoiding defensive language with an invented case. A useful training exercise does not need the original reviewer's name or the exact details that make the incident recognisable.

Removing names is not a complete anonymisation method

Replacing a name with Guest A may reduce an obvious identifier, but the remaining information can still identify a person or be linked back to the source record. Treat such material cautiously rather than calling it anonymous by default. A booking identifier, rare event, precise location or distinctive combination of facts may preserve the connection.

In July 2026, the EDPB announced anonymisation guidelines that consider identifiability in context and the means reasonably likely to be used. At this article's review date, the announcement states that consultation runs until 30 October 2026. The guidance should therefore be treated with its stated consultation status. The practical lesson for hotel staff is that anonymity needs assessment, not merely a removed name or a vendor checkbox. [3]

For routine drafting, a genuinely invented scenario is often simpler than trying to anonymise a real case. Change the underlying facts and use only what the task requires. If analysis needs real records, ask the responsible data-protection and technical personnel to design the method. Do not ask the public AI service to anonymise a file that the hotel was not authorised to upload in the first place.

Use aggregate hotel data carefully

A report containing monthly totals may be appropriate for a particular approved analysis, but aggregation does not automatically remove every identification risk. Very small groups or unusual combinations can reveal individual behaviour. A segment consisting of one guest is not meaningfully protected merely because the spreadsheet labels it as a segment rather than a person.

Review the business sensitivity separately from personal-data status. Even a dataset without identifiable guests may contain confidential rates, contracts, owner information or commercially sensitive forecasts. An employee's authority to access that report internally does not necessarily include authority to disclose it to an external service. The hotel's information policy should cover both privacy and commercial confidentiality.

For an early demonstration, create synthetic numbers that preserve the calculation structure without reproducing live results. Label them clearly as fictional so they are not later used in an owner report or business case. When the actual analysis is approved, define the exact fields, recipient service and output handling rather than allowing an unrestricted export of the PMS database.

Distinguish an approved implementation from an ordinary account

CNIL's guidance advises users to submit only information they are authorised to share and warns against providing confidential personal or business information to consumer services. It also discusses contracts, deployment choices and internal rules for organisational use. This is regulator guidance for assessing use, not a statement that every hosted AI service is prohibited or every on-premise system is compliant. [2]

A business subscription may offer useful controls, but the hotel must check the actual plan, configuration and terms. Questions include whether inputs are used for model improvement, how long records are retained, who can access them, which subprocessors are involved and what happens at termination. Obtain current answers rather than relying on a colleague's experience with a different account type.

The EDPB's controller and processor guidance explains the need to establish roles and appropriate contractual responsibilities. The hotel's review should address the proposed processing and any relevant international-transfer arrangements. Access controls, retention settings and a lawful purpose remain important even where the provider offers strong security features. Approval should be specific enough that employees know what they may and may not do. [4]

Give staff a usable alternative for common tasks

Create approved prompt patterns for low-risk work using public hotel facts or fictional examples. A marketing draft can use the hotel's published facilities and verified positioning. A training exercise can describe an invented arrival problem. A language exercise can use a generic message with placeholders. Make these patterns easy to find so employees do not need to improvise under time pressure.

Keep personalisation inside the authorised operational workflow. For example, ask the tool to draft a general pre-arrival explanation, have a responsible person verify it, then use the approved messaging system to insert the booking-specific details. This separates the writing assistance from the processing of an individual guest's record. The guest-message automation guide explains the controls needed around the final send. [7]

Where employees repeatedly need a task that the policy prohibits, investigate the need instead of relying only on reminders. There may be a legitimate case for an approved specialised solution, or the process may be unnecessarily difficult. A policy becomes more effective when it offers a workable route for useful tasks and a clear person to contact about exceptions.

Include screenshots, connectors and hidden context in training

Modern tools may access more than the text typed into the prompt. File uploads, browser integrations, connected drives and conversation history can all affect what information is available to a service. Staff should understand the scope of the particular approved tool rather than assuming that only the visible sentence is involved.

Before attaching a screenshot, check every visible area, including background windows, names in tabs and notifications. Before attaching a spreadsheet, check hidden sheets, comments and embedded information using the approved review process. Where a safe example is enough, create one from scratch. Blurring a visible name does not establish that the underlying file no longer contains identifying information.

Treat connector permissions as a separate decision. A tool approved for drafting public descriptions is not automatically approved to read all reservations, emails or shared folders. Limit access to the authorised purpose and review changes when features or integrations are added. The hotel's technical and privacy owners should be involved in those decisions, with staff informed about the resulting boundaries.

Respond promptly if information is uploaded by mistake

Employees should report an accidental disclosure immediately through the hotel's incident process, without waiting to prove that harm occurred. Stop further sharing, record what was submitted, when, through which account and to which service, and preserve the information needed for assessment through an appropriate restricted route. Do not spread the same data more widely while explaining the incident.

The responsible team should assess containment options with the provider, including available deletion or access controls, while recognising that deleting a visible chat does not by itself prove every copy or processing consequence has disappeared. Determine what information was involved and who may have been affected. Legal, privacy and technical specialists should guide the assessment rather than leaving the employee to negotiate the incident alone.

The EDPB explains that personal-data breaches must be documented and, where the notification threshold is met, reported to the relevant authority without undue delay and within the applicable 72-hour framework after awareness. Communication to affected individuals is required where the relevant high-risk threshold is met, subject to applicable exceptions. Not every incident has the same notification outcome, but uncertainty is a reason for prompt assessment, not delay. [6]

Review outputs before they become hotel records

An AI output may repeat personal information from the prompt, introduce unsupported claims or infer details that the hotel has not verified. Review the result before placing it in a guest record, sending it to a guest or sharing it with staff. A polished summary should not become authoritative simply because it reads convincingly.

Keep the original verified facts distinguishable from generated suggestions. If the tool proposes that a guest is likely to behave in a particular way, do not add that speculation to the PMS as though it were established information. Use AI assistance for the approved task and retain human responsibility for service decisions. The AI-assistant guide discusses the related need for limited authority and meaningful oversight. [8]

Apply the same care to training materials and owner presentations. A fictional example should remain labelled as fictional, and an aggregate analysis should retain its definitions and limits. This reduces the chance that synthetic content or an unsupported inference is later mistaken for an actual guest event or an empirical finding about the hotel.

Hotel team checklist before using an AI tool

Ask what task you are trying to complete and whether it can be done with public facts or a fictional example. Check whether the tool and account are approved for that task, whether any file contains identifiable or confidential information and whether connected sources add more data than expected. If approval is unclear, use the established internal route rather than uploading first and asking afterwards.

For approved processing involving real records, follow the documented fields, access, retention and review rules. Know how to report an error and who can suspend the workflow. HoHo Consultancy can help structure practical hotel workflows and staff guidance alongside the hotel's qualified privacy and legal advisers. The aim is to make useful AI assistance possible without turning guest information into uncontrolled prompt material. [9]

Sources and related services

[1] EDPB: Data protection basics
Primary personal-data and special-category principles. Accessed 20 October 2026.

[2] CNIL: Q&A on use of generative AI
Primary organisational-use guidance; 2024 AI Act overview not relied upon. Accessed 20 October 2026.

[3] EDPB: July 2026 anonymisation guidance announcement
Current consultation status and contextual identifiability; not final guidance. Accessed 20 October 2026.

[4] EDPB: Controller or processor
Primary role and contractual responsibilities. Accessed 20 October 2026.

[5] PCI SSC: Outsourced payment processing
Primary merchant responsibility. Accessed 20 October 2026.

[6] EDPB: Data breaches
Primary documentation, risk assessment and notification framework. Accessed 20 October 2026.

[7] Companion: Guest-message automation
Internal controlled personalisation workflow. Accessed 20 October 2026.

[8] Companion: AI assistant oversight
Internal authority and review framework. Accessed 20 October 2026.

[9] HoHo Consultancy
Service contact. Accessed 20 October 2026.