Can You Legally Use Your Own Customer Data to Train AI? A UK Business Guide

You collected it. You stored it. You paid for the systems holding it. It is, in every ordinary sense, your data.

That does not mean you can use it to train an AI model, and the gap between owning information and being permitted to use it for a new purpose is where a good many enthusiastic projects stop.

This article sets out the UK position in plain English, what usually makes a project workable, and the three obstacles businesses hit in practice.

This is a practical summary, not legal advice. For anything material, take proper counsel.

This article is part of our guide to the data you already own.

The distinction that decides everything

Is it personal data? Meaning: does it relate to an identified or identifiable living individual?

If no, UK GDPR does not apply. Machine performance logs, aggregated non-identifying transaction patterns, technical measurements. You still have contractual questions to resolve, and the data protection layer is not in play.

If yes, and in most business archives a great deal is, you need a lawful basis for the new purpose, and that is a genuine constraint rather than a formality.

Note that identifiability is broader than people expect. A B2B contact record is personal data. A quote addressed to a named individual is personal data. A job record with the engineer's name on it is personal data about the engineer. See data privacy.

Obstacle one: purpose limitation

This is the big one and it catches almost everybody.

Under UK GDPR, personal data collected for one purpose cannot simply be used for a different, incompatible purpose. You collected customer records to fulfil orders and manage the relationship. Using them to train a model is a new purpose, and you need to establish either that it is compatible with the original one, or that you have a fresh lawful basis.

The compatibility assessment considers the link between the purposes, the context in which the data was collected, the nature of the data, the possible consequences for the individual, and the safeguards in place.

In practice, training an internal model to improve your own service to the same customers is a considerably easier argument than training a model you intend to sell.

Obstacle two: your lawful basis

Six exist. For this kind of project, realistically two are candidates.

Legitimate interests. The usual route. It requires a documented three-part assessment: is there a legitimate interest, is the processing necessary for it, and does it override the individual's rights and freedoms. That last part is a genuine balancing exercise, not a formality, and the document is what demonstrates you did it.

Consent. Clean where you have it, and rarely available retrospectively across a whole archive. Consent must be specific, informed and freely given, and "they agreed to our terms in 2014" almost never satisfies that for a purpose that did not exist in 2014.

Contract, legal obligation, vital interests and public task will not generally apply to a training project.

Obstacle three: what you told people

Your privacy notice matters more than owners expect. If it does not mention anything resembling this processing, you have a transparency problem regardless of your lawful basis.

The fix is prospective and straightforward: update the notice, tell people, and be clear about what you are doing. The fix is not retrospective, which means the archive you collected under the old notice may need different treatment from data collected after the update.

What usually makes it workable

Three moves, in order of how often they resolve the problem.

Aggregate. Most of the commercial value in these projects is in patterns, not individuals, as the data you already own sets out. "Jobs of this type run 19 per cent over" needs no personal data at all. If the useful output is aggregate, strip the identifiers at the start rather than at the end.

Anonymise properly. True anonymisation takes the data outside UK GDPR entirely, which removes the whole problem. The bar is higher than removing names: the test is whether an individual can be identified by any means reasonably likely to be used, including by combining with other data. Pseudonymisation, replacing names with codes you still hold, is a safeguard and not an exemption.

Narrow the scope. Train on the last three years rather than twenty. Use one data type rather than everything. A narrower project has a much easier compatibility argument and usually answers the question just as well.

The obstacle that is not GDPR

For professional services firms this frequently bites before data protection does.

Client confidentiality under your engagement letters and professional rules may restrict use more tightly than the law does. A commitment to use client information only for the purposes of that engagement is common, and it does not have an aggregation carve-out unless someone wrote one in.

Similarly, check whether data created under a client contract actually belongs to the client, whether platform terms restrict what you may do with data extracted from them, and whether data acquired with a business carries restrictions from its original collection.

These are contract questions rather than regulatory ones, and they bite hardest in professional services firms, and they are usually easier to resolve, often by asking.

A practical sequence

Establish whether it is personal data. Genuinely, field by field, rather than by assumption.

Check the contracts first. Confidentiality and ownership questions are quicker to answer and can stop the project before you spend anything on the data protection work.

Test whether aggregation solves it. In most cases it does, and it is the cheapest answer.

If you need identifiable data, document the assessment. Legitimate interests assessment, compatibility assessment, and a DPIA if the processing is high risk, which for profiling and automated decision-making it usually is.

Update the privacy notice before processing data going forward.

Record the decision. One page: what you are doing, on what basis, what you considered, who decided, when. If anyone asks later, this is the difference between a defensible position and an indefensible one.

Key Takeaways

• Owning data is not permission to use it for a new purpose. Purpose limitation under UK GDPR is the specific obstacle.
• Legitimate interests is the usual basis and requires a documented balancing assessment. Old terms and conditions almost never supply valid consent for a purpose that did not exist then.
• Aggregation resolves most of these projects, because the commercial value is usually in patterns rather than individuals.
• True anonymisation removes the problem entirely. Pseudonymisation does not, it is a safeguard.
• For professional services, client confidentiality often bites before data protection does. Check the engagement letters first, because it is quicker and can stop the project early.

Frequently Asked Questions

Can we use client data if we anonymise it?

If it is genuinely anonymised, UK GDPR no longer applies and the data protection obstacle is gone. The bar is that no individual can be identified by means reasonably likely to be used, including by combination with other data, which is stricter than removing names. Your contractual confidentiality obligations are a separate matter and may still apply.

What about data from customers who have since left?

Same rules, and an additional question: do you still have a basis to retain it at all? Retention is a frequent weak point. Data kept past its purpose is a liability rather than raw material. See dark data: how to audit what your business is already storing.

We want to use our data with ChatGPT. Does that change anything?

Yes, because you are now sending it to a third party, which is a separate processing question on top of the purpose one. Check the tier. Business tiers generally do not train on your inputs by default; consumer tiers often do. This is also the most common real-world incident in UK businesses, covered in shadow AI.

Do we need a DPIA?

If the processing is likely to result in high risk to individuals, yes, and large-scale profiling or automated decision-making generally qualifies. For an aggregate analysis of anonymised operational data, generally not. When in doubt the assessment is cheaper than the alternative.

---

Want to know whether your data project is legally viable before you spend anything on it? Talk to Halo Technology Lab. Our strategy and scoping service establishes this during feasibility rather than at the end, which is where it usually gets discovered.