Can We Use AI on Customer Data We Already Hold? Practitioner Q&A

Lawful basis, purpose compatibility, training versus inference and transparency duties when AI is applied to customer data your organisation already holds.

Usually yes, with conditions. You need a lawful basis that covers the new AI purpose, and that purpose must be compatible with the one you originally described to the customer. You also owe customers updated transparency information. Reuse is a legal question about purpose, not a technical question about tooling.

This Q&A covers lawful basis, purpose compatibility, the training-versus-inference distinction and transparency duties, for product owners, exec sponsors and the DPOs reviewing their proposals. It is general information, not legal advice; take your own advice on your specific circumstances.

Can we use AI on customer data we already hold?

Usually yes, provided the lawful basis covers the new AI purpose and that purpose is compatible with the one you described when the data was collected. Transparency information owed to customers has to be updated to match. The question is a legal one about purpose rather than a technical one about tooling.

Document three things before the build starts: what the data was collected for, what the AI use will do with it and why a reasonable customer would consider the second consistent with the first. The question usually arrives as “can we run AI on our customer database?”, which is a purpose question in technical clothing. If the third point fails, you need a fresh lawful basis or a different dataset.

Often not. Consent is one of six lawful bases under UK GDPR and it is frequently the weakest choice for internal AI work, because it must be freely given, specific and capable of being withdrawn. If a customer withdraws consent after a model has been trained, you inherit a problem that is expensive to unwind.

Many organisations rely on legitimate interests for analytical and operational AI, supported by an assessment weighing business benefit against intrusion on the individual. Contract necessity may apply where the AI function forms part of the service the customer bought. Special category data such as health, biometrics or political opinions narrows the options and typically requires explicit consent or a statutory condition. Establish the basis with legal input before development, not during AI Security Gap Analysis remediation. The same analysis applied to general-purpose assistants is covered in our answer on whether ChatGPT use can comply with UK GDPR.

What does purpose limitation mean for an AI project?

Purpose limitation says personal data collected for one specified purpose cannot be reused for an incompatible one. It does not prohibit all reuse. It requires you to assess compatibility.

Compatibility turns on the link between old and new purposes, the collection context, the nature of the data, consequences for the individual and safeguards such as pseudonymisation. Using support-ticket text to train an internal triage model sits close to the original purpose; using the same tickets to build a propensity score that changes what a customer is charged sits much further away. Document the reasoning, because regulators and auditors will ask for it. Our AI Governance entry covers recording these decisions and our AI risk assessment entry covers structuring the analysis.

Is training a model different from running inference on customer data?

Yes. Training involves the model absorbing patterns from a dataset, which can leave personal data embedded in model weights in ways that resist deletion. Inference means passing a record through an already-trained model to produce an output, which leaves no persistent trace unless you or the provider log it.

Inference on existing customer data is easier to justify and easier to reverse. Training raises harder questions about erasure: if an individual asks you to delete their data, you must explain what that means for a model already trained on it. Many organisations train on synthetic or heavily pseudonymised data and reserve live records for inference only. Understanding what the model does with the data it receives is the core of AI Behaviour Verification.

Do we have to tell customers we are using AI on their data?

In most cases yes. UK GDPR transparency duties require you to inform people about the purposes of processing, and adding an AI purpose to existing data usually means your privacy notice is now incomplete. Where the AI produces automated decisions with legal or similarly significant effects, additional information and rights apply.

The common failure is treating this as a legal-page update six weeks before launch. Decide early, in plain language, what you will tell customers about what the AI does and does not do. Notice language stretched to cover any conceivable future use tends not to survive challenge. The EU AI Act adds separate disclosure obligations for certain classified system types where your organisation operates in EU markets.

What if the AI tool is a third-party service?

A third-party AI tool creates a processor relationship you must establish and a set of contractual controls you must verify. Sending existing customer data to an external AI service means someone else processes it, possibly outside the UK, possibly in ways that improve their product rather than only serving you.

Check three things. Whether the provider trains on submitted data by default, and whether that can be disabled contractually rather than by a toggle someone can flip back. Where processing occurs and what international transfer mechanism covers it. What retention applies to prompts and outputs. Where staff have already begun using external tools without this scrutiny, you have a Shadow AI problem rather than a procurement one, and our Shadow AI Discovery service is the usual first move.

Does ISO 42001 help with any of this?

It helps with the process, not the legal conclusion. ISO 42001 is a management system standard for AI. It requires you to identify AI systems, assess their impacts, assign accountability and maintain records of decisions. Those requirements produce the documentation trail that a purpose-compatibility assessment needs.

What it does not do is decide your lawful basis. Certification demonstrates a repeatable process for making and recording these judgements, not that any individual judgement was correct. ISO 42001 alignment produces most of the evidential record an AI Act readiness assessment calls for, leaving the substantive legal analysis as separate work. Our EU AI Act preparedness guide sets out the current timeline, including the high-risk deadlines deferred to 2 December 2027 and 2 August 2028.

What is the simplest decision path for a new AI idea?

Four questions, in order. What was this data originally collected for? Is the proposed AI purpose compatible with that, or does it need its own lawful basis? Will the data be used for training, inference or both? Does the customer need to be told something new?

If you can answer all four with documented reasoning, the project can proceed and the reasoning becomes your audit evidence, feeding the wider AI security programme controls the system needs, including the CIA+EFT tests applied to its behaviour. If any answer is unclear, that is where the assessment work sits, with your own legal advisers. Question two is the one that most often cannot be answered, because the original purpose was rarely written down precisely enough to test compatibility against it. Which regulator will ask you first is covered in UK AI regulation by sector.

Answer the purpose question before you build

We work through lawful basis, purpose compatibility and transparency for each proposed AI use, and leave you with the reasoning written down as audit evidence.