Before You Use AI: A Data, Privacy and Security Checklist for Tourism Businesses

Responsible AI in a tourism business

A member of staff pasting an enquiry into a public AI tool may feel no different from using a search box. It is different. The prompt can contain customer information, confidential rates, internal problems or commercially sensitive plans. Before encouraging experimentation, a business needs a few clear rules.

This checklist is designed for tourism, hospitality and experience businesses using generative AI tools for ordinary work. It is not a substitute for legal, data-protection or cyber-security advice, and the appropriate controls will depend on the tool and the use case.

1. Identify the information involved

Begin with the real task. What would a member of staff need to place into the system for it to be useful?

Tourism businesses may hold:

• customer names, email addresses and telephone numbers;
• travel dates, locations and accommodation details;
• passport or identity information;
• dietary, health, mobility or accessibility information;
• payment details and financial records;
• supplier rates, contracts and commissions;
• staff information, rotas and performance notes;
• unpublished itineraries, proposals and commercial plans.

Do not assume that information is harmless because it appears in an email. Ask whether the AI task genuinely requires it. If not, remove it.

2. Distinguish public tools from approved business systems

A free consumer chatbot, a paid individual account and a managed business service may have different contractual terms, retention arrangements, access controls and settings. Product names alone do not answer the question.

For every approved tool, record:

• which account or subscription staff must use;
• whether prompts and outputs are used to improve the provider’s models;
• where information is processed and stored;
• how long it is retained and how it can be deleted;
• who at the provider or within your business may access it;
• whether the supplier terms meet your data-protection and confidentiality requirements.

The NCSC advises organisations to understand a provider’s terms and privacy policy and not to include sensitive information in prompts to public large-language-model services.

3. Create a clear “do not enter” list

A simple rule that staff can remember is more useful than a policy nobody reads. It should still be supported by a fuller assessment for the people responsible for systems and data.

4. Minimise or anonymise information

Replace names and contact details with neutral labels where the task allows it. Use “Guest A” rather than a customer’s name. Remove booking references, exact addresses and unnecessary personal context.

Anonymisation is not achieved merely by deleting a name. A combination of dates, location, employer, family detail or unusual requirements may still identify someone. The ICO’s guidance stresses data minimisation, accountability, transparency, accuracy and security throughout the use of AI.

5. Decide who is accountable for the output

An AI-generated answer should never become nobody’s responsibility. Name the role that checks it and define what they must verify.

The level of review should reflect the consequence of an error:

6. Protect accounts and access

Use business-managed accounts where possible. Enable multi-factor authentication, avoid shared passwords and remove access promptly when somebody leaves or changes role. Staff should know how to report a suspicious login, unexpected output or accidental disclosure.

If an AI tool connects to email, cloud storage, a booking platform or customer database, review the permissions carefully. Give it access only to the information required for the defined task. A broad connection made for convenience can create a much larger exposure than copying a single approved document.

7. Test for errors and manipulation

Large language models can produce false information and can be vulnerable to prompt injection—content designed to make a system ignore its intended instructions. This matters when an AI workflow reads websites, customer-supplied documents or incoming messages.

Test with past examples, awkward cases and deliberately misleading content. Define what the system should refuse, flag or pass to a person. The NCSC’s secure AI guidance recommends treating security as a requirement throughout design, deployment, operation and maintenance—not a final check.

8. Keep records proportionate to the risk

For a small trial, a one-page record may be enough. It should state:

• the business problem and intended benefit;
• the approved tool and account type;
• the data permitted and prohibited;
• the human reviewer;
• how the trial will be measured;
• known failure points and what to do if they occur;
• the review date and decision to continue, change or stop.

More consequential uses may require a formal data protection impact assessment, security review, supplier agreement or specialist advice.

9. Give staff short, practical guidance

People will experiment whether or not the organisation has a strategy. A complete ban can drive that activity into unapproved accounts. Provide a safe route instead:

• a short list of approved tools;
• three or four examples of permitted work;
• a memorable “do not enter” rule;
• a requirement to check all externally used output;
• a named person for questions and incidents.

Review the guidance as tools, contracts and business uses change.

10. Start small and revisit the decision

Approval should not be permanent by default. Trial one workflow, examine real corrections and check whether staff are following the controls. A tool that was acceptable for rewriting public website copy may not be suitable for analysing customer records.