GDPR and AI Training Data: What an SMB Building a Model Needs to Know

Training an AI model on personal data is a GDPR processing activity. It is not exempt because it is "AI," it is not exempt because the data is "public," and it is not exempt because the output is a model rather than a database. The same five questions the Article 30 RoPA asks of any processing — lawful basis, purpose, recipients, retention, security — apply to the training pipeline, with two extra ones: did the data subjects expect this, and is the model itself personal data?

An SMB building (or fine-tuning) a model on customer, employee, or scraped data is a controller for that training activity. An SMB deploying a vendor’s model on its own customer data is a controller for the deployment processing and may be a joint controller or a processor depending on the vendor’s role. In both cases GDPR applies, and the EDPB — the European Data Protection Board, the body that coordinates EU data-protection authorities — has repeatedly signalled that AI training is not a special category exempt from the regulation’s principles.

A grounding note: the canon summarises GDPR principles and names the EDPB as the EU coordinating body, but does not contain the EDPB’s AI-specific opinions verbatim. The positions attributed to the EDPB below reflect its established public direction on AI-model training (lawful basis including legitimate interest, purpose limitation between training and inference, anonymity of trained models as a factual question). Confirm the current EDPB position against the EDPB’s published opinions before relying on a specific point operationally.

The training pipeline is a processing activity

Break the model lifecycle into the processing activities the RoPA needs to record:

1. Data collection / ingestion. Where the training data comes from — your CRM, employee records, a scrape, a licensed dataset, user inputs to a deployed model. Each source is a row. 2. Preprocessing and labelling. Cleaning, annotating, pseudonymising. Processing in its own right, often by a separate team or vendor. 3. Training / fine-tuning. The model learns from the data. The lawful basis and purpose for this activity are the crux. 4. Validation / testing. Held-out data, evaluation. Still processing. 5. Deployment / inference. The model in production, processing new inputs — often the data subjects’ data the SMB actually cares about. 6. Retention and deletion. How long the training set is kept; whether the model itself is retained.

Each of these is a row in the RoPA. An SMB that records only “we use AI” has not documented the activity; an SMB that records the six stages has.

The lawful-basis question for training

GDPR Article 6 requires a lawful basis for each processing activity. For AI training the realistic bases are:

• **Consent (Article 6(1)(a)).** Clean but hard — consent must be freely given, specific, informed, and withdrawable, and withdrawal must be as easy as giving it. For scraped data or historical CRM data, consent is usually not feasible because it was never collected for this purpose.
• **Necessary for a contract (Article 6(1)(b)).** Where training is genuinely necessary to deliver a service the data subject is party to. Narrow — most training is not strictly necessary for an individual contract.
• **Legitimate interests (Article 6(1)(f)).** The basis the EDPB has signalled as most likely to fit general AI training, subject to a three-part test: a legitimate interest, necessity (no less intrusive way to achieve it), and a balancing test against the data subjects’ rights and reasonable expectations. The balancing test is where most training fails scrutiny — data subjects do not expect their CRM record or their scraped post to train a commercial model.
• **Special-category data (Article 9).** If the training set contains health, biometric, political, religious, or other Article 9 data, an additional Article 9 condition is required (typically explicit consent). This is the trap for HR datasets and for scrapes that incidentally scoop up special-category content.

Document the basis per training activity in the RoPA. “Legitimate interests” requires the written LIA (legitimate-interests assessment) — the balancing test is the artifact an authority asks for.

Purpose limitation: training vs inference

GDPR Article 5(1)(b) requires that data collected for a specified purpose not be processed in a way incompatible with it. Training a model on data collected for a different purpose (CRM data collected for service delivery, scraped data collected for nothing the subject agreed to) is a further processing — lawful only if compatible with the original purpose, or if a separate lawful basis applies. The EDPB’s direction treats training on data collected for an unrelated purpose as a compatibility question that frequently fails: a customer who gave you their address for shipping did not expect it to train a churn-prediction model.

The practical fix is a compatibility assessment documented per training activity, or — more often — a fresh lawful basis (consent or a passed LIA) for the training itself.

Minimisation, retention, and the “is the model personal data?” question

• **Data minimisation (Article 5(1)(c)).** Training sets are routinely over-collected. Minimisation asks whether you need the identifiers, the free-text fields, the special-category-adjacent content you scraped. Pseudonymisation before training is the standard mitigation.
• **Storage limitation (Article 5(1)(e)).** Retention must be limited to what is necessary. Keeping a training dataset indefinitely "in case we retrain" is not a retention policy. Set a training-set retention and a model-retention.
• **Is the trained model personal data?** The contested question. A model that has memorised training examples and can regurgitate them is arguably processing personal data at inference. The EDPB has signalled that model anonymity is a *factual* question — a model is anonymous only if it cannot be made to emit personal data, which for many large models is not demonstrable. Treat the model as potentially personal data unless you can demonstrate non-reversibility; do not assume "it’s a model, not a database" exempts it.

Article 22 and automated decisions

If the deployed model produces decisions with legal or similarly significant effects on data subjects (loan screening, hiring filters, pricing), Article 22 applies — the right not to be subject to solely automated decisions, plus meaningful information about the logic. This is the deployment activity, not the training activity, but it is the downstream reason training-data quality matters. A DPIA is required for this kind of processing; the canon is explicit that automated decision-making involving profiling is high-risk and triggers a DPIA before implementation.

The DPIA for AI training

A DPIA (Article 35) is required for processing likely to result in high risk — and the canon names systematic and extensive profiling, large-scale special-category processing, and systematic monitoring as triggers. AI training on customer data, on scraped personal data, or on special-category data clears at least one trigger. The DPIA describes the processing, assesses necessity and proportionality, identifies risks to data subjects, and documents mitigations. For an SMB, the DPIA is also the document that forces the lawful-basis and compatibility questions to be answered in writing before training starts — not after the model is in production.

The DPIA dovetails with the ISO 42001 AI system impact assessment (clauses 6.1.4 and 8.4). The GDPR DPIA is the data-protection cut; the ISO 42001 impact assessment is the broader AI-system cut covering trustworthiness concerns — security, safety, fairness, transparency, data quality, lifecycle. If you run both, one analysis feeds both reports. See the ISO 42001 AI impact assessment template and the ISO 42001 AI governance pillar.

Vendors and the deployed model

Most SMBs do not train from scratch — they fine-tune or deploy a vendor model. The GDPR questions shift but do not disappear:

• **Is the vendor a processor or a controller?** If you send your customer data to the vendor’s model and the vendor uses it to improve its own model, the vendor is a controller for that improvement (or a joint controller), and a Article 28 data-processing agreement is not enough — you need a joint-controller arrangement or a guarantee the vendor will not train on your data.
• **Where does inference happen?** On-prem, in an EU region, or transmitted to a US endpoint? Third-country transfer rules apply (Standard Contractual Clauses, adequacy). The RoPA’s transfer column catches this.
• **What does the vendor do with prompts?** Many model APIs retain prompts for a retention period or for safety review. That is a processing activity you should record and a retention you should know.

What an SMB should do before training or deploying

1. Add the model lifecycle to the RoPA as the six processing activities above, with lawful basis and purpose per stage. 2. Run the LIA if relying on legitimate interests, and the compatibility assessment if training on data collected for another purpose. Document both. 3. Run the DPIA before training or deploying if the processing is high-risk (it usually is). Start from the DPIA template. 4. Pseudonymise the training set and set a training-set and model retention. 5. Decide the model-anonymity position in writing — do not default to “the model is anonymous.” 6. Check the vendor contract for training-on-your-data clauses and the inference endpoint’s location. 7. If you run ISO 42001, fold the DPIA into the AI impact assessment — one analysis, two reports.

How this fits the series

This is the AI cluster thread of the GDPR series — the bridge to the ISO 42001 pillar and the EU AI Act overlap. It assumes you have built the Article 30 RoPA (the model lifecycle is six rows in it) and read the data subject rights and 72-hour clock (Article 22 is the downstream rights trigger). The DPIA template is the operational artifact this article sends you to.

What to do next

Before you train on or send a single record to a model, write the six RoPA rows for the model lifecycle and run the lawful-basis question for the training stage. If the answer is “legitimate interests,” write the LIA and the compatibility assessment. If the training touches special-category data or produces Article 22 decisions, start the DPIA. The cost of doing this before training is an afternoon; the cost of doing it after an authority asks is a model you may have to retire.

Building or deploying an AI model on personal data and unsure where GDPR lands? Book a 30-minute **GDPR + AI training-data review** — we map your model lifecycle to the six RoPA rows, pressure-test your lawful basis and LIA, and scope the DPIA. Bilingual EN/FR, no obligation.

→ /contact · download the GDPR for SMBs readiness guide