Purpose Limitation and Reusing Customer Data to Train a Model

You have four years of support tickets, collected to answer support tickets. Somebody proposes fine-tuning a model on them. The question is not whether you have a lawful basis — you may well have one — but whether the new purpose is compatible with the one the data was collected for, which is a separate test with its own five factors.

The rule in Article 5(1)(b)

Article 5(1)(b) of Regulation (EU) 2016/679 requires personal data to be collected for specified, explicit and legitimate purposes and not further processed in a manner incompatible with those purposes. It adds that further processing for archiving in the public interest, scientific or historical research purposes, or statistical purposes, in accordance with Article 89(1), is not to be considered incompatible.

Two errors are common. The first is treating purpose limitation as satisfied by having a lawful basis: basis and purpose are separate requirements, and passing Article 6(1) says nothing about Article 5(1)(b). The second is treating a broad privacy notice as a specified purpose. “To improve our services” is not specified or explicit in the sense the article requires, and a purpose drafted that widely tends to fail on its own terms rather than authorising everything.

When the compatibility test is even available

Article 6(4) opens with a condition that is frequently read past: the compatibility assessment applies where the processing for another purpose is not based on the data subject’s consent or on Union or Member State law which constitutes a necessary and proportionate measure in a democratic society to safeguard the objectives in Article 23(1).

The consequence is sharp. If the original processing was based on consent, you do not get to argue compatibility — Recital 50 makes the point that where processing is based on consent, the data subject should be able to expect it to be limited to what they consented to, and the route to a new purpose is a new consent. Controllers who chose consent because it felt like the more respectful basis discover here that it is also the least flexible one, which is one of several reasons the basis decision is worth making deliberately — see writing a legitimate interest assessment for AI training.

Where the test is available and the further processing is found compatible, no separate legal basis is required for the new purpose — the original basis carries over. Where it is not compatible, you need a new purpose, a basis for it, and fresh transparency under Article 13(3) or 14(4).

The five factors in Article 6(4)

Article 6(4) requires the controller to take into account, among other things:

• (a) Any link between the original and the new purpose. Is training a support assistant connected to answering support requests? There is a genuine link, and it is stronger than the link between the same tickets and, say, a general-purpose foundation model.
• (b) The context of collection, in particular the relationship between data subject and controller. A customer in a contractual relationship, writing to your support desk, has different expectations from a member of the public whose post was scraped.
• (c) The nature of the data, in particular whether special categories under Article 9 or criminal data under Article 10 are involved. Support tickets in a health, financial or legal product routinely contain Article 9 data that nobody schematised.
• (d) The possible consequences of the intended further processing for data subjects. For training, the specific consequences are memorisation and regurgitation, inference, and irreversibility.
• (e) The existence of appropriate safeguards, which may include encryption or pseudonymisation. The only factor you can change by doing work, which is why it deserves the most attention.

The list is expressly non-exhaustive — “inter alia” — and reasonable expectations run through all of it.

A worked example: support tickets

The facts

Four years of tickets from business customers. Collected to resolve issues. Contain customer names, employer, product configuration, free text, and occasionally the personal circumstances behind a request. The notice at collection said the data would be used to provide and support the service. Proposal: fine-tune a model to draft first-line replies.

Running the factors

(a) Strong link. The new purpose is a means of doing the original one better, on the same data, for the same population. (b) Favourable context: an existing contractual relationship, with the data given deliberately for a service the customer wanted. (c) Mixed, and the factor that most often decides these: free-text tickets are not schematised, and if the product is one where users explain health or financial circumstances, Article 9 data is present in an unknown proportion. (d) The realistic consequence is that a fine-tuned model reproduces a memorised ticket — another customer’s name, or a configuration detail — in a draft reply, which is a confidentiality risk with a specific mechanism rather than a generic one. (e) Here is the work: strip direct identifiers before training; filter or exclude ticket categories most likely to contain Article 9 data; deduplicate to reduce memorisation; keep the fine-tuned model internal rather than exposing it to other customers; test for regurgitation of names before release.

A defensible conclusion

Compatible for the narrow purpose of drafting replies within the same service, subject to those safeguards, and documented as such. Considerably weaker if the same corpus is proposed for a general model sold to third parties: factor (a) collapses, factor (b) stops helping because the relationship no longer explains the use, and factor (d) gets worse because the model leaves your boundary. Same data, same collection notice, different answer — which is what a compatibility test is for.

If the answer is incompatible

Incompatible does not mean prohibited. It means the further processing is a new purpose that requires its own basis and its own transparency. The realistic routes are consent from the data subjects, which for a four-year archive means a contact exercise with a low response rate and the honest consequence that non-responders are excluded; or anonymisation to a standard that takes the data outside the Regulation entirely, which is a high bar and is discussed on anonymisation and pseudonymisation of training data; or narrowing the purpose until it becomes compatible, which is usually the practical answer and is why the analysis is worth running before the project is scoped rather than after.

The route that does not work is retroactively broadening the privacy notice. Updating the notice changes what future data subjects are told; it does not change the purpose for which the existing archive was collected, and treating a notice update as a licence to reuse historic data is one of the more commonly enforced errors in this area.

The research presumption is narrow

Article 5(1)(b)’s statement that further processing for scientific research is not incompatible is attractive to anyone training a model, and it is narrower than it looks. It operates in accordance with Article 89(1), which requires appropriate safeguards for the rights of data subjects — in particular technical and organisational measures to ensure respect for data minimisation, with pseudonymisation named expressly. Recital 159 describes scientific research broadly, including privately funded research, but the concept has been read as requiring genuine research conducted to accepted methodological standards, not simply product development that involves learning something.

Even where it applies, the presumption addresses compatibility only. It does not supply a lawful basis, it does not displace the transparency duties, and it does not remove the Article 9 problem for special-category data. A commercial fine-tune framed as research to avoid a compatibility analysis is a position that would have to be defended on the facts of what was actually done, and the safeguards Article 89(1) requires are the price of relying on it in the first place.