GDPR and Generative AI: Choosing a Lawful Basis

Every generative AI project reaches the same question at roughly the same moment: on what lawful basis are we processing this personal data? The answer is rarely one basis for the whole project, and the mistake that causes the most rework is treating it as a single question rather than three.

Separate the processing operations first

There are at least three distinct operations in most deployments, and they can have different lawful bases, different controllers and different data subjects.

Training or fine-tuning. Personal data in the training corpus, processed to adjust model parameters. The data subjects here are frequently not your customers, and may not be identifiable to you at all.

Inference. Personal data in a prompt or in retrieved context, processed to generate an output. The data subject is usually someone in your existing relationship.

Output handling. Personal data in the generated output, which may be about the same person, a different person, or a person who does not exist but is identifiable by inference.

Collapsing these produces the familiar failure: a legitimate interests assessment written for training that is then cited to justify inference on a different population entirely.

The candidate bases

Consent

Clean where obtainable, but demanding: freely given, specific, informed, unambiguous, and withdrawable with the same ease as it was given. For training, withdrawal is the problem — if consent is the basis and a data subject withdraws, the position of a model already trained on that data is uncomfortable and the technical answers (machine unlearning, retraining on a filtered corpus) are expensive or immature. Consent is generally better suited to inference-time features a user can turn on and off.

Contract

Available where processing is necessary for performance of a contract with the data subject. “Necessary” is the operative word and it is interpreted narrowly: necessary for the service the user actually signed up for, not for the improvements you would like to make. Using contract as the basis for training on customer content is a stretch that supervisory authorities have repeatedly declined to accept.

Legitimate interests

The realistic basis for most training and much inference — and the one that requires actual work rather than a checkbox. It is available where processing is necessary for legitimate interests pursued by the controller or a third party, except where overridden by the interests or fundamental rights and freedoms of the data subject.

Writing a legitimate interests assessment that would survive scrutiny

Three limbs, in order, each answered on the facts rather than in the abstract.

Purpose. Identify the interest precisely. “Innovation” is not an interest. “Improving the accuracy of clause classification in our contract review product, so that customers detect material risks they would otherwise miss” is. Interests may be commercial; they may not be vague.

Necessity. Is the processing necessary to achieve that interest, and is there a less intrusive route? This is where most assessments are weakest. Would synthetic data work? Would a smaller sample? Would pseudonymisation before training achieve the same accuracy? If you have not tested the alternatives, you cannot assert that they are inadequate — and “we did not try” reads badly.

Balancing. Weigh the data subject’s interests against yours, taking account of: the nature of the data (special category data effectively rules this basis out on its own); the relationship — is there one at all?; the reasonable expectations of the data subject at the time of collection; the possible consequences, including the risk of the model reproducing personal data in output; and the safeguards you apply.

Safeguards are what shift the balance, and they should be specific: filtering identifiable data from the training corpus, deduplication to reduce memorisation, output filters, rate limiting, restricting the model to an internal population, retention limits, and a genuinely accessible objection mechanism.

An assessment that concludes in your favour on every limb without engaging with a single argument against you is not an assessment. It is a document that will be read aloud to you.

The web-scraped corpus problem

Where training data was collected from public sources, two obligations bite hard.

Transparency. Article 14 requires information to be provided to data subjects when data is obtained other than from them. The disproportionate-effort exemption may apply at scale, but it is not automatic: you must still take appropriate measures, which in practice means a public, findable and specific notice describing the collection, the purposes, the basis and the objection route.

Accuracy. Article 5(1)(d) requires personal data to be accurate. A model that generates plausible but false statements about an identifiable person is processing inaccurate personal data, and rectification requests do not have an obvious technical answer. Output filtering and a responsive correction process are the practical mitigations; neither is complete, and the honest position is to document the residual risk rather than to claim it away.

Data subject rights, operationally

Rights do not pause because the architecture is inconvenient. Practical positions that hold up:

• Access. Provide the data held in identifiable form — training records, prompts, logs, outputs associated with the person. Model weights are not a copy of the data and are not usually within scope, but say so and explain why rather than leaving the request unanswered.
• Erasure. Delete from corpora, indices, retrieval stores, logs and backups on a defined schedule. Where the model itself cannot be scrubbed, document that, apply output filtering, and commit to exclusion from future training runs.
• Objection. Where legitimate interests is the basis, objection must be accommodated unless you demonstrate compelling grounds. Design the mechanism before you need it; a form that routes to an unmonitored inbox is worse than no form.
• Automated decision-making. If output materially affects someone without meaningful human involvement, Article 22 is engaged. “A person clicks approve” is not meaningful involvement unless that person has the information, competence and authority to disagree.

A workable default

For most enterprise deployments the defensible shape looks like this: legitimate interests for training on data you already hold lawfully, supported by a written assessment with real safeguards; contract necessity for inference that delivers the service the user asked for; consent for optional features that go beyond it; no special category data in training without an Article 9 condition and a very good reason; retention limits enforced technically rather than by policy; and a transparency notice that a reasonable person would understand on one reading.