Removing guest details before using AI: masking, pseudonyms and what still identifies a guest

Data anonymization for AI means making personal data impossible to link to an identified or identifiable person, even when combined with other data. Removing a guest's name is not enough: dates, room, nationality and a rare request can single out one booking. Mask, generalize or remove those combinations, then test whether a colleague could still name the guest.

Someone on the guest relations team exports last month's complaints, deletes the name column, and pastes the rest into an AI chat tool. The row still says a Russian family, two connecting rooms, the second week of August, and a complaint about the lift. Anyone who worked that week can name that family in seconds.

This article shows how to prepare such an export properly: which fields identify a guest, how masking, pseudonyms and anonymization actually differ, what a prepared file looks like, and how to test your own work before anything leaves the hotel.

Why is removing the guest's name not enough?#

Because identification rarely needs a name. A handful of ordinary fields, taken together, can point to one booking in a month of records.

A direct identifier works alone: a full name, an identity or passport number, an email address. An indirect identifier works in combination: a check-in date, a room type, a nationality and one unusual request. Four indirect identifiers together are often as good as a name, and unlike a name they are rarely deleted.

The bar comes from the regulator, not from intuition. Türkiye's Personal Data Protection Authority (KVKK) sets it in its guide on deletion, destruction and anonymization, Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Rehberi (opens in a new tab) (KVKK Publications No. 71, April 2025).

Before choosing anonymization over deletion or destruction, the guide asks the controller to be sure of three things: the dataset cannot be de-anonymized by combining it with another dataset; no single value or set of values forms a meaningful whole that singles out a record; and the remaining values cannot combine to produce an assumption or conclusion about a person.

The third check is the one hotels miss. A complaint's own text can produce that conclusion: the guest in the corner suite whose air conditioning failed, the honeymoon couple who asked for a late check-out. The story itself identifies, even with every name gone.

The duty sits with the hotel, not with the AI tool. A provider's privacy page does not make an export anonymous. The safe default is to treat the export as personal data until a test on that specific file says otherwise, and to record the test.

Which fields in hotel data identify a guest, directly or indirectly?#

Names and identity numbers identify directly. Dates, room, nationality, booking references, free text and the file's own metadata identify in combination.

Sort the export into three piles before touching it: fields that identify alone, fields that identify in combination, and fields that carry a story. Free text is the most overlooked pile. Notes, requests, message threads and review replies carry the details a guest chose to share, and those details are exactly what makes a row unique.

The same field can be harmless in one property and identifying in another. For example, a nationality plus a date is unremarkable in a 400-room resort in August and unique in a 12-room boutique hotel in February. Decide per field, not per file: a field the analysis does not need should be removed, not masked, because removal cannot be reversed.

Metadata travels with the file. The file name, the author, the creation time and the sheet name can point to a shift, and through the shift to a guest. Write down what you keep and why, so the next export is prepared the same way and a colleague can check your reasoning.

If you are building guest profiles in the first place, it is worth knowing what to record and what never to record, because data you never stored does not need to be anonymized later: guest profiles in hotels: what to record and what never to record.

Masking, pseudonyms and anonymization: how do they differ?#

Masking hides characters inside a field, pseudonyms replace identifiers with codes that a key can reverse, and anonymization is the result the guide describes: data that cannot be linked back to a person even when combined with other data.

Masking is a security measure applied to a field, such as deleting, crossing out, painting over or starring its value, and it is not a verdict on a dataset. The guide treats anonymization as irreversible and lists techniques such as grouping, derivation, generalization and randomization; a masked value counts as anonymized only if the original data is destroyed or the value is irreversibly generalized. Keeping the original and the key means the data is pseudonymized, and the guide's test, that the result cannot identify a specific person, is not met.

It groups the example methods into three families. Methods that do not perturb values include removing variables, removing records, regional suppression, generalization, top and bottom coding, global coding and sampling. Methods that perturb values include micro-aggregation, data swapping and noise addition. Statistical methods that strengthen anonymization include k-anonymity, l-diversity and t-closeness.

Pseudonyms work differently. The identifier becomes a code, and a key file maps codes back to guests. While that key exists and the hotel can use it, the data can still be associated with a person, which is the opposite of the guide's test. Whether a specific dataset is still personal data is a legal question, so take it to your adviser.

Every method costs signal. Grouping dates to weeks loses the day-of-week pattern; grouping nationality to region loses the source-market detail. Decide which question you are answering before you choose the method. A practical order follows: remove what the question does not need, generalize what it needs only roughly, and mask last, because masking keeps the shape of a value that often still points to one person.

Related reading on this blog: KVKK's deletion, destruction and anonymization guide read for hotels. And if your hotel has not yet decided what staff may share with AI chat tools at all, start one level up: hotel AI policy: what staff may share with AI chat tools.

What does a month of complaints look like after preparation?#

Fewer columns, coarser values and text with the identifying details cut out, and the file still answers the question you actually asked.

Start from the question, not the export. If the question is which complaint types repeat and at which stage of the stay, the analysis needs the complaint category, the stage, the week and the property area. It does not need a name, a room number or a booking reference.

For example, a row that read "Room 412, Mr and Mrs K, 9 to 16 August, Russian, complained twice about the lift and once about breakfast noise" becomes "week 33, region: CIS, room type: double with sea view, category: lift, category: noise at breakfast, two complaints". The second row still tells you the lift is a recurring problem in sea-view rooms. It no longer tells you who stayed in 412.

Keep the complaint category and the cleaned free text, because that is where the useful detail lives. Drop everything that points at one booking. Accept the loss: after preparation you can no longer answer whether the same guest complained twice. If that question matters, answer it before anonymizing, inside the hotel, and send only the counts to the AI tool.

A prepared file is only as good as its categories. If the complaint categories are inconsistent, fix them first, or the AI tool will summarize noise. Save the transformation rules next to the export, so the next month is prepared identically and the two months can be compared.

If the goal is a short fix list rather than a compliance exercise, the same cleaned text feeds the method described in reading guest reviews with AI: from hundreds of comments to a short fix list.

The re-identification test: could a colleague name the guest?#

Pick someone who worked that week but did not prepare the export, show them ten rows, and ask them to name the guest or narrow it to one booking.

Choose the tester carefully. You already know the answers, so you cannot test your own work. A colleague from that week knows the arrivals, the incidents and the regulars, which is exactly the knowledge an outsider would need. The guide puts the same idea on the controller: before choosing anonymization over deletion, the hotel must check whether the data could identify a person using information known to be held by the organizations it transferred the data to, or publicly available information.

So run two tests, not one. The colleague test covers internal knowledge. The search test covers public knowledge: paste a distinctive phrase from the text into a search engine, because guests sometimes post the same complaint on a review site. Record the date, the tester and the outcome; a failed test is useful evidence that the preparation needs another round.

If one row survives the test, remove that row. Do not discard the whole dataset, and do not lower the bar for the rest. Repeat the test whenever the export changes shape: a new field, a new property, a new season with a different guest mix.

If you use pseudonyms, where does the key file live and who can open it?#

In a separate place from the export, opened by named people, logged, and deleted on a date you set before you start.

The key file is itself personal data, because it rebuilds the link. It needs the same care as the original export, and usually more, because it is small and easy to email. Keep it out of the AI tool, out of shared drives and out of the chat thread. If the tool needs a follow-up on one code, you do the lookup inside the hotel and send back only the anonymized answer.

Name one owner and one deputy, log every opening, and set the deletion date at the start rather than at the end. If nobody needs to re-link the codes, do not create a key at all: a random code with no key is simply a removed identifier.

Ask your adviser what the AI provider does with the data, where it is processed and how long it is kept. That is a contract and legal question, not a setting in the tool. The guide's recipient test applies here too: the hotel stays responsible for checking whether the data could identify a person using information held by the organizations it transferred the data to.

When should you not use AI at all?#

When the record contains a special category of personal data, concerns a child, or is a single case where the story itself identifies the guest.

Special categories arrive in hotel data disguised as service requests: a dialysis schedule, a gluten-free diet that reveals a condition, a wheelchair-accessible room, a prayer mat, a medical appointment noted in the free text. Children appear as a family booking, a kids' club note, or an age written into a request. Keep those records out of AI tools entirely.

Single cases carry their own identity: one accident, one dispute with a lawyer involved, one complaint that reached social media. There is no combination to break, because there is only one record. Do not use an AI tool to decide anything about a named guest, such as a refund, a compensation or a ban; a decision about a person needs a person who can explain the reason.

Handle these cases with the staff member who owns them, and ask your legal adviser before any processing. This article describes a method, not a legal opinion on your file. The same restraint applies to the tool itself: if you would not read the record aloud in a team meeting, do not paste it into a chat box.

For the questions worth taking to that adviser before any of this starts, see AI assistants and guest data: KVKK questions for your adviser.

What to do next#

Take one export you were about to send to an AI tool this week, prepare it with the steps above, and run the colleague test before anything leaves the hotel. The pieces fit together in one order: decide the question, remove what the question does not need, generalize what it needs only roughly, keep any key file separate and dated, and let a person who knows the week try to break it. If the test fails, generalize further and test again; if a single row survives, remove the row.