GDPR and AI on your travel website: 5 real-case decisions

On my website there is a free tool, the Prompting Genie, that processes users' text with an AI model. You describe in two sentences what you want to achieve, choose which AI it is for — ChatGPT, Claude, Gemini, Midjourney, Veo and others, across text, image, video, agents and SEO — and it returns a prompt tuned for that specific model, ready to paste. No sign-up. Building it forced me to answer, with concrete decisions, the same questions any travel business faces when adding a chatbot, a smart form or plain analytics: what do I store, what do I disclose, and whom do I ask for permission. These are the five decisions I made and why — with the upfront caveat that I am not a lawyer, and this is documented experience, not legal advice.

1. Consent has to actually block

The most widespread mistake on travel websites is the decorative banner: it appears, asks for permission... while the measurement scripts have already loaded. That is not consent; it is stage dressing.

In my case, the tag manager — and with it all analytics — does not load until the user clicks accept. If they reject, it never loads. And rejecting costs exactly the same click as accepting, which is the criterion the Spanish data protection authority has been setting for banners. The acid test is technical and anyone can run it: open your website in a private window, accept nothing, and check in the browser tools which requests go out. Whatever loads before your "yes" tells on you.

2. The best data is the data you don't store

When I designed my tool's usage log, the most important decision was negative: not storing IP addresses. I didn't need them for anything useful, and every piece of personal data you store is liability you take on — it must be protected, declared and deletable on request.

It is the minimisation principle applied with business logic: before storing a field, the question is not "might it be useful someday?" but "what concrete decision will I make with it?". No clear answer, out it goes. For a hotel or agency, the same filter applied to the booking form usually removes half the fields — and improves conversion along the way, because every extra field scares people off.

3. If AI processes text, you say so — plainly and right there

My tool sends the user's text to an AI provider for processing. That gets disclosed, and disclosed where it is used: a short notice next to the form itself — the text is processed with AI, don't enter personal or confidential data, it is stored anonymously — with a link to a terms page detailing what is kept, for how long and with what rights. Two layers: brief notice at the point of use, full detail one click away.

While building it I asked myself the question anyone would: if I use the free quota of the Gemini API, does Google train its models on that text? Outside Europe, it can. Inside, it doesn't: the Gemini API terms state that in the European Economic Area, Switzerland and the United Kingdom the same data-use terms as the paid version apply to the whole service, free quota included. And those terms say Google does not use prompts or responses to improve its products. I work from Spain, so the text that goes through my tool does not train Gemini.

But not training on it doesn't mean the data vanishes, which is why the notice still asks people not to enter personal data. For three reasons:

• Google logs it for a while. The same terms say it keeps prompts and responses for a limited period to detect abuse and meet legal obligations. The text travels to its servers and gets recorded.
• My own infrastructure stores it too. The goal, the context and the generated prompt are kept anonymously for up to 12 months to improve the tool. If someone types their ID number there, their ID number stays there. Every system a text passes through is one more point it can leak from.
• Some data has its own rules. A name next to an allergy is already health data, a special category under the GDPR. A raw card number falls under the PCI DSS standard. A general-purpose AI API is neither designed nor certified to act as a payment gateway or a medical record.

It is exactly what any travel chatbot should carry, and almost none does: the guest writing to a hotel's assistant deserves to know their text is processed by a third party's machine, and what happens to it.

4. Name the provider, not your architecture

A nuance learned while drafting my own terms: the law requires identifying the companies processing data on your behalf — it does not require publishing your technical diagram. In my policy I name the providers and their function (technical infrastructure, AI text processing) without detailing versions or specific configurations. You comply just the same, and you don't hand a free map of your installation to anyone looking for seams. In an industry handling payment and travel data, that technical modesty is basic security hygiene.

5. Customer data never goes into public AI. Ever.

The most important rule is also the easiest to break on a rushed Tuesday: no pasting customer names, emails, bookings or incidents into the public versions of ChatGPT, Gemini or similar. Doing so means losing control of the data, which may end up used for training — and no customer gave you permission for that. The hotel industry's own guidance already says it expressly (Cloudbeds, 2026). Working with real data requires enterprise versions or APIs with contractual guarantees.

The operational fix is simple and cheap: anonymised templates. "Draft a reply to a guest complaining about noise in room X on night Y" works just as well without a name, an email or a booking number. It is the same ground rule that opens the five steps of the AI marketing plan: real business data, yes; customers' personal data in public tools, never.

The honest summary

None of the above required expensive lawyers or blocked any feature: they were design decisions taken in time, almost all cheaper than their careless alternative. That is the reading I offer any travel business adding AI: GDPR is not the tax you pay at the end of the project — it is a set of product decisions that, taken at the start, come almost free, and taken late, cost a refurbishment. And in a business built on the trust of people who hand you their name, their card and their holiday dates, treating data with that care is not just compliance: it is consistency with what you sell.