What should an AI policy say about using customer emails, call notes and support tickets?

29 September 2026

What should an AI policy say about using customer emails, call notes and support tickets?

Do not write a blanket rule that says customer communications can or cannot be used with AI. Set a controlled route: approved tool, approved purpose, minimum data, lawful basis, access limits, retention period, output checking and an incident process. Personal accounts and unapproved browser tools should be prohibited for identifiable customer material.

Start with one clear rule staff can remember

Your policy should begin with a sentence that survives a busy Monday morning: customer communications may only be used in an approved AI service, for an approved work purpose, using the minimum information needed. That covers emails, attachments, contact forms, call recordings, transcripts, CRM notes, live chat logs and support tickets. These records may contain names, contact details, account history, payment problems, health information, complaints, opinions about staff and information about other people. Calling the task 'summarisation' does not make that data harmless.

Then turn the principle into three categories. Green uses include drafting a generic reply from a fictional example, classifying a ticket after identifiers have been removed, or summarising a conversation inside an approved system with a signed data processing agreement. Amber uses need manager or data protection approval, such as analysing complaint themes across many customers, creating call transcripts or connecting an AI assistant to the CRM. Red uses are banned, including personal AI accounts, unapproved browser extensions, uploading whole inboxes, asking AI to decide whether a customer is dishonest, or using customer conversations to train a model without a separate assessment.

This matters because adoption is moving faster than governance. The UK Business Data Survey 2026 found that 41% of businesses handling digitised data used AI for at least one purpose, but 17% of AI-using businesses had no AI policy. Your policy closes the gap between what staff can technically do and what the business has deliberately authorised.

State exactly which tools and accounts are approved

A useful policy names approved services, approved account types and the person who approves changes. 'Use AI responsibly' is not a control. A practical entry might say that staff may use the organisation's managed Microsoft Copilot, ChatGPT Business, Gemini for Workspace or a specific helpdesk feature, but may not use personal accounts, free consumer accounts or browser extensions that have not been reviewed. The right product depends on your contracts and configuration, not on the brand name alone.

Before approval, check where prompts and files are processed, whether customer data is used to train provider models, how long prompts and outputs are retained, whether administrators can control sharing, whether single sign-on and multi-factor authentication are available, and how data can be deleted or exported. Record the vendor, service tier, contract owner, renewal date, approved purposes, connected systems and the date of the last review. If the supplier changes its terms or adds a new connector, approval should be revisited.

Permissions should follow least privilege. A ticket summariser does not need access to the whole CRM. A reply assistant does not need payment records. Start with one queue, a limited group of users and read-only access where possible. The National Cyber Security Centre's secure AI guidance says AI systems should work without revealing sensitive data to unauthorised parties and highlights prompt injection and data poisoning as distinct AI risks. In practice, that means customer text entering an AI workflow must be treated as untrusted input, especially when the system can read files, send messages or update records.

Define purpose, lawful basis and transparency before use

Your policy should require an owner to define why customer communications are being processed before AI touches them. 'Improving the service' is usually too vague. Better purposes are: summarising a support call for the assigned adviser, suggesting a reply for a human agent, routing a ticket to the correct team, extracting agreed actions, or identifying recurring complaint themes in anonymised records. Each purpose should have a named owner, a data set, an output, a retention rule and a clear boundary on what happens next.

Under UK data protection law, using personal data with AI needs a lawful basis. Contract may apply where processing is objectively necessary to deliver the service the customer requested. Legitimate interests may apply to some operational improvements, but it needs a documented assessment of necessity and the effect on customers. Consent is not a convenient fallback if customers cannot freely refuse or withdraw it. Special category data, such as health information, needs both an Article 6 basis and an additional Article 9 condition. Get advice for anything sensitive or consequential.

The ICO's AI transparency guidance says privacy information should explain the purpose, retention period and who personal data is shared with. If data is collected directly, that information should be provided when it is collected. Your policy should therefore require the privacy notice, call recording message and support channel wording to match the actual AI use. The ICO notes that parts of its AI guidance are under review following the Data (Use and Access) Act, so the policy owner should check for updates rather than treating today's wording as permanent.

Minimise and redact data instead of copying whole records

The policy should tell staff to use the smallest useful extract, not the entire conversation history. If the task is to improve the tone of a reply, the AI may need the proposed reply and a short description of the issue. It probably does not need the customer's full signature, phone number, account number, previous orders and three years of notes. If the task is to identify complaint themes, aggregate or anonymise records before analysis wherever possible.

Define redaction in practical terms. Remove names, email addresses, phone numbers, postal addresses, account and order numbers, payment information, login details and any free text that can identify the person. Also remove third-party information and sensitive details that are irrelevant to the task. Pseudonymisation, such as replacing a name with 'Customer A', reduces exposure but does not take the data outside UK GDPR if the business can reconnect it to the person.

Be honest about the trade-off. Over-redaction can remove the context needed for a useful answer. The answer is not to send everything. It is to design a controlled workflow that selects the relevant fields and keeps the source record in the system of record. For example, a helpdesk integration might pass the issue category, product, latest customer message and approved knowledge articles to the model, while keeping contact and payment fields out. Test the output with realistic synthetic examples before using live records.

The policy should also prohibit secrets in prompts: passwords, API keys, recovery codes, private links and security answers should never be entered. If a customer has included them in an email or ticket, remove them and follow your security procedure before any AI processing.

Require human review and keep responsibility with the business

Your policy should say that AI output is a draft or recommendation unless a separately approved automation rule says otherwise. The staff member sending a reply remains responsible for accuracy, tone, promises, deadlines and disclosure. They must compare summaries and extracted actions with the source record, especially where the conversation involves a complaint, cancellation, refund, vulnerability, safety issue, legal position or financial commitment.

Set explicit actions that AI must not take alone. It should not reject a complaint, determine compensation, label a customer as fraudulent, change contractual terms, make a credit decision, close a safeguarding concern or send a high-impact response without qualified human approval. Low-risk acknowledgements and routing may be automated after testing, but customers need an obvious route to a person when the system is wrong or the issue is exceptional.

Define a sampling regime as well as individual review. For an early pilot, review 100% of outputs for at least two weeks or the first 100 cases, whichever gives a meaningful sample. Record factual errors, invented details, missed actions, inappropriate tone, data leakage and the time staff spend correcting output. Only reduce review after the owner can show acceptable performance. Continue weekly or monthly sampling because suppliers, prompts, knowledge bases and customer behaviour change.

That operational discipline matters at national scale. The Office for National Statistics reported in July 2026 that AI use among UK businesses with 10 or more employees had risen from around 12% in late 2023 to around 35%, yet adoption remained relatively shallow. Buying a tool is easy. Building review, ownership and evidence around its use is the harder part.

Set retention, monitoring and incident rules

The policy should identify which copy is the official record. Usually that is the email, CRM, call system or helpdesk, not the AI chat history. Store the approved final response and any business-relevant summary in the system of record. Do not retain duplicate prompts and outputs indefinitely just because the supplier allows it. Set a retention period based on purpose, legal obligations and customer expectations, then configure deletion where the service supports it.

Logging must be proportionate. Keep enough information to investigate a problem, such as user, time, approved workflow, record reference and action taken, without creating a second uncontrolled archive of customer conversations. Restrict log access. Review unusual volumes, repeated exports, new integrations and failed safeguards. Staff monitoring should itself be transparent and proportionate.

Give employees a simple incident route. They should stop the workflow and report immediately if customer data is entered into an unapproved tool, the wrong customer information appears in an output, confidential content is exposed, a connector gains broader access than intended, or an AI-generated reply causes harm. The incident owner should preserve evidence, contain access, contact the supplier if needed, assess affected people and decide whether the ICO or customers must be notified. A personal data breach that is likely to risk people's rights and freedoms generally needs reporting to the ICO without undue delay and, where feasible, within 72 hours of awareness.

Finally, review the policy at least every six months and whenever a supplier, model, contract, data source or law changes. The policy should name one accountable owner and one deputy. A rule with no owner becomes optional as soon as work gets busy.

Is This Right For You?

This policy approach is right for you if staff already summarise enquiries, draft replies, classify tickets, extract actions or analyse customer conversations with AI. It is especially useful when your business has no full-time IT or compliance team and managers need rules ordinary staff can apply under pressure.

It is not enough if you process large volumes of health, legal, financial, safeguarding or other special category information, or if AI makes decisions with significant effects on people. Those uses need specialist data protection and legal review, a detailed data protection impact assessment where required, stronger technical controls and often a narrower use case. A short staff policy cannot turn a high-risk process into a safe one.

If no approved tool and controlled workflow exist yet, the safe interim rule is simple: do not paste identifiable customer communications into AI. Staff may use fictional or properly anonymised examples for training, but replacing a name while leaving an email address, order number and detailed complaint is not anonymisation.

Frequently Asked Questions

Can staff paste a customer email into ChatGPT if they remove the name?

Only if the business has approved that specific service and purpose, and the remaining text cannot identify the customer. Removing a name is not enough when an email address, order number, unusual complaint or other details still identify the person.

Do customers need to consent before AI summarises their support ticket?

Not always. Consent is only one possible lawful basis and is often unsuitable in an ordinary service relationship. You still need a valid lawful basis, transparent privacy information, data minimisation and appropriate safeguards. Seek specialist advice for sensitive or high-impact processing.

Can we use call recordings to train an internal AI assistant?

Possibly, but do not treat it as the same purpose as recording calls for service or quality. Assess the lawful basis, customer expectations, special category data, retention, security and whether anonymised or synthetic examples would achieve the goal with less risk.

Should AI-generated customer replies always be checked by a person?

Yes during introduction, and always for complaints, refunds, vulnerabilities, contractual promises, regulated advice or other consequential matters. Mature low-risk acknowledgements or routing can be automated only after documented testing, monitoring and escalation controls.

What should happen if an employee uses an unapproved AI tool with customer data?

Stop further use, report it through the incident route, preserve the facts and assess what data was shared, with whom, under what settings and whether it can be deleted. Treat it as a learning and containment issue first, while applying normal disciplinary rules only where conduct warrants it.

How often should this part of the AI policy be reviewed?

Review it at least every six months and sooner when a supplier changes terms, a new connector is enabled, the model or workflow changes, an incident occurs or relevant ICO guidance and UK law are updated.