GDPR Data Protection Impact Assessment (DPIA) — for AI training and inference

Structure (11 sections)

1. 1. 1. Trigger determination and scope

   State which single processing operation (or which set of similar operations) this assessment covers, then justify why a DPIA is required. Art. 35(3) lists three mandatory cases: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based; large-scale processing of Art. 9(1) special categories or Art. 10 criminal data; and large-scale systematic monitoring of a publicly accessible area. Beyond those, score the nine wp248rev.01 criteria: evaluation or scoring; automated decision-making with legal or similar significant effect; systematic monitoring; sensitive or highly personal data; large-scale processing; matching or combining datasets; vulnerable data subjects; innovative use of new technological or organisational solutions; and processing that in itself prevents data subjects from exercising a right or using a service or contract. The Working Party’s rule of thumb is that meeting two criteria calls for a DPIA; if only one is met and you decide not to run one, record that reasoning here. Also state whether the processing appears on the mandatory list your supervisory authority published under Art. 35(4) — the most commonly skipped step, because national lists differ. Scope the description down to system and version: "training and live inference for recommendation model v3", not "our AI business".

   Evidence to attach

   • · Scoring table against the nine criteria, with assessor and date
   • · Comparison against the supervisory authority’s Art. 35(4) mandatory list
   • · Inventory of systems and versions in scope, noting what is excluded
   • · Where no DPIA is run: the written reasoning, countersigned by the DPO

   Common pitfalls

   • · Writing one DPIA covering "all our AI products", so no specific risk maps to a specific system;
   • · Citing only the three Art. 35(3) cases and never the nine criteria, leaving the reviewer unable to test the determination;
   • · Not checking the national mandatory list, assuming the Regulation text is the whole requirement;
   • · Back-dating: running the assessment after go-live, where the dates themselves prove the "prior to the processing" requirement was missed.

2. 2. 2. Systematic description of the processing

   Art. 35(7)(a) requires a "systematic description"; Annex 2 of wp248rev.01 breaks that into checkable parts: the nature, scope, context and purposes of the processing; a record of the personal data, the recipients and the retention period; a functional description of the operation; and identification of the assets personal data rely on (hardware, software, networks, people, paper and paper transmission channels). For AI, write it along the data lifecycle: acquisition (own products, third-party datasets, crawling, user input, synthetic data — one paragraph each) → cleaning and labelling → training and fine-tuning → evaluation → live inference and logging → feedback loops into retraining → deletion. Each stage states the data categories, categories of data subject, legal role (controller / processor / joint controller), and storage location inside or outside the EEA. Reconcile this with the Art. 30 records of processing (ROPA): a contradiction between the two documents is the easiest inconsistency for a reviewer to find.

   Evidence to attach

   • · Data-flow diagram marking storage locations and cross-border hops
   • · Field-level data inventory (data category, category of data subject, source, retention)
   • · The corresponding Art. 30 ROPA entries and a note reconciling them with this document
   • · Asset inventory (training clusters, vector stores, logging systems, outsourced labelling platforms)
   • · Recipient list covering processors, sub-processors and joint controllers

   Common pitfalls

   • · Mapping only the inference path, while training-data provenance, outsourced labelling and feedback logging are missing;
   • · Stating retention as "as long as the business needs", which is not a period — Art. 5(1)(e) requires it to be determinable;
   • · Processors listed in the ROPA differing from those in the DPIA, showing the two documents were written by different teams;
   • · Reading "assets" as a server list and omitting people and outsourced labelling — the assets that most often fail.

3. 3. 3. Lawful basis, necessity and proportionality

   Art. 35(7)(b) requires assessment of "the necessity and proportionality of the processing operations in relation to the purposes". Write it in three layers. First: map each purpose (training, evaluation, live inference, abuse detection, retraining) to a specific Art. 6(1) basis — do not let one blanket "legitimate interests" cover every stage. Where you rely on legitimate interests, work the three-step test explicitly: is the interest legitimate, is the processing necessary to achieve it, and how does the balance against data subjects’ rights and reasonable expectations come out; EDPB Opinion 28/2024 addresses this test specifically for model training. Second: state whether Art. 9 special categories and Art. 10 criminal data are excluded, and if not, which Art. 9(2) exception applies — special-category data riding along inside web-scraped corpora is the most common hole here. Third: set out the concrete minimisation and storage-limitation measures (deduplication, de-identification, field pruning, sampling, and what happens to the raw corpus after training). Close with Art. 5(1)(b) purpose limitation: repurposing already-collected user data for model training is either a compatible use or a new purpose — record the conclusion and the reasoning.

   Evidence to attach

   • · Purpose-to-lawful-basis mapping table, one row per processing stage
   • · Legitimate-interests assessment record, including the balancing outcome and how objections are handled
   • · Special-category screening method and the results of a sampling check
   • · Minimisation measures with before/after data volumes
   • · Compatibility analysis against each Art. 6(4) factor

   Common pitfalls

   • · One line of "legitimate interests" for the whole pipeline, with no three-step test and nothing on how Art. 21 objections are handled;
   • · Asserting the training corpus "contains no personal data" without a screening method or sampling evidence;
   • · Relying on consent for training when the consent obtained at collection cannot be shown to cover model training;
   • · Writing the necessity analysis as a product-value pitch — the reviewer wants to know whether less data would achieve the same purpose.

4. 4. 4. Arrangements for data subject rights

   Annex 2 of wp248rev.01 makes "measures contributing to the rights of the data subjects" a checked item: walk through how Arts. 12–22 are implemented in this system — information (Arts. 13 and 14, including the source disclosure where data was not obtained from the individual and the reasoning for any Art. 14(5) exception), access and portability (Arts. 15 and 20), rectification and erasure (Arts. 16, 17 and 19), restriction and objection (Arts. 18, 19 and 21). Answer the hard AI question head-on rather than avoiding it: for personal data already absorbed into a trained model, how is an erasure request executed — removal from corpus and index only, or retraining or weight-level intervention, and what are the technical limits and lead times of each; and how is incorrect personal information appearing in model output rectified (output filtering, retrieval-layer correction, or refusal). Put the Art. 12(3) one-month deadline (extendable by two months with reasons) into the workflow itself, not only into a policy document.

   Evidence to attach

   • · Privacy notice text covering the training purpose, with screenshots of where it is shown
   • · Rights-request SOP covering identity verification, the one-month deadline and an extension-reasons template
   • · Technical account of how erasure is executed at corpus, index and model level, with test records
   • · Rights-request register (received, responded, outcome)
   • · Written reasoning for any Art. 14(5) exception relied on

   Common pitfalls

   • · Stating "the model cannot delete an individual record" as the conclusion, with no alternative measure and no residual-risk analysis;
   • · No Art. 14 notice for scraped corpora and no argument for the Art. 14(5)(b) "impossible or disproportionate effort" exception;
   • · The rights-request entry point buried at the foot of an English-only privacy policy, more than three clicks away;
   • · A register in which every entry reads "handled", with no response times, so compliance with the one-month deadline cannot be shown.

5. 5. 5. Automated decision-making and profiling

   If the output feeds decisions with legal or similarly significant effects on individuals (credit, hiring screens, insurance pricing, content bans, differential pricing), this gets its own section. First decide whether it falls under Art. 22(1) "solely automated": does the human step have real capacity to intervene (authority to overturn, the information to do so, the time to do so), or is it a rubber stamp. If it does fall in, state which Art. 22(2) exception applies (necessary for a contract, authorised by Member State law, explicit consent) and the Art. 22(3) safeguards: the right to obtain human intervention, to express a point of view, and to contest the decision. Then spell out the "meaningful information about the logic involved" required by Arts. 13(2)(f), 14(2)(g) and 15(1)(h) — which feature families are used, their approximate weight or direction of effect, and the envisaged consequences, not "we use a machine-learning algorithm". Automated decisions on Art. 9 special-category data are subject to the tighter limits in Art. 22(4).

   Evidence to attach

   • · Determination record for solely-automated status, evidencing the human reviewer’s authority, information and time
   • · Legal analysis of the Art. 22(2) exception relied on
   • · Human-review workflow description and statistics on the override rate
   • · The "logic involved" explanation text as actually shown in the product
   • · Register of contests and appeals and how they were handled

   Common pitfalls

   • · Denying Art. 22 applies because "a human reviews it", with no override rate or review-duration data to back it;
   • · Giving the algorithm’s name as the "logic involved", leaving the individual unable to judge whether to contest;
   • · A contest channel that exists but is unstaffed, with months of empty register entries;
   • · Overlooking Art. 22(4): using health or biometric special-category features in an automated decision without the extra analysis.

6. 6. 6. Processors, sub-processors and the model supply chain

   Under Art. 28, set out the role and contractual arrangement for every party in the chain: cloud and compute providers, outsourced labelling vendors, vector stores and retrieval services, third-party model APIs you call, and evaluation or red-team vendors. For each, record: the legal role (processor or independent controller — frequently mis-classified when calling a third-party model API), whether a DPA is signed and when, the sub-processor authorisation and notification mechanism under Arts. 28(2) and (4), audit rights, and the vendor’s country. If EU user input is passed to a third-party model provider, state whether that provider uses the input for its own training, whether that can be switched off, and what the default is — the single most-asked question in EU enterprise due diligence. Where your own company acts as processor for some customers, record the corresponding limits on instructions here too.

   Evidence to attach

   • · Supply-chain inventory (role, DPA status, country, data categories)
   • · Executed DPAs, sub-processor lists and change-notification records
   • · Screenshots of the third-party model API’s training-use setting, with the contract clause cited
   • · Vendor security assessments (questionnaires, certificates, penetration-test summaries)
   • · Records of audit rights exercised, or the alternative assurance relied on

   Common pitfalls

   • · Labelling every third-party model provider a "processor" when its terms reserve the right to use inputs for itself — making it an independent controller;
   • · A sub-processor list supplied once at signature, with no notification record for vendors added later;
   • · Omitting outsourced labelling altogether, though it usually has the widest exposure to raw personal data;
   • · A signed DPA with no audit or alternative assurance evidence, so the Art. 28(3)(h) verification duty goes unmet.

7. 7. 7. Security of processing and data protection by design and by default

   Under Art. 32, describe technical and organisational measures at a verifiable granularity: encryption (in transit and at rest, and who holds the keys), access control (who can reach training clusters, corpus stores, logs and inference records respectively), the specific pseudonymisation or de-identification method plus a re-identification risk assessment, availability and recovery (RTO/RPO, restore-drill records), and the mechanism for "regularly testing, assessing and evaluating the effectiveness" of the measures together with the latest result. Answer Art. 25 by design and by default separately: under default settings, how much is collected, how long it is kept, and whether training feedback is on by default. Address AI-specific risks explicitly: personal data leaking through memorisation and prompt injection, model inversion and membership inference, user input unintentionally retained in logs, and over-broad retrieval from a RAG index. For each, give the mitigation and how it is verified — avoid unverifiable statements like "it is encrypted".

   Evidence to attach

   • · Measure inventory in three columns: measure, risk addressed, verification method
   • · Access-control matrix and access-review records
   • · Pseudonymisation method description and re-identification test results
   • · Test reports on memorisation, membership inference and prompt injection
   • · Latest security or penetration test with remediation closure records
   • · Backup-restore drill records

   Common pitfalls

   • · A measure list copied from ISO 27001 controls, none of it tied to a risk in this system;
   • · Access rights to logs and inference records left out, although these hold the rawest user input;
   • · "Regular testing" with no date or outcome for the latest round, so the mechanism cannot be shown to run;
   • · Equating model security testing with content-safety red-teaming, leaving personal-data leakage vectors untested.

8. 8. 8. International transfers and third-country legal environment

   List every outbound flow in this system, including remote access and support access — the two most often missed — and for each record: recipient and country, transfer purpose and data categories, the Chapter V mechanism relied on (adequacy decision, standard contractual clauses, binding corporate rules, Art. 49 derogation), and whether a transfer impact assessment has been completed. Flows to China get their own paragraph: this is the section EU customers scrutinise most closely for Chinese AI vendors, and it should set out the government-access framework under Chinese law, the contractual and technical supplementary measures available, and the process for handling an access request. The transfer impact assessment itself lives in a separate document (see the TIA template); reference it here and summarise the conclusion, so the two documents do not carry competing findings.

   Evidence to attach

   • · Inventory of outbound flows, including remote and support access
   • · Executed standard contractual clauses with Annexes I–III
   • · Index and conclusion summary of the transfer impact assessment
   • · Supplementary-measures list and evidence of their effectiveness
   • · Process for handling government access requests, and a transparency report if published

   Common pitfalls

   • · Counting only flows where data is copied abroad, missing data stored locally but remotely queryable or retrievable from outside;
   • · SCCs signed on the template with Annexes I–III blank or boilerplate, so they do not reflect the real data flow;
   • · The DPIA saying "risk assessed as acceptable" while the standalone TIA reaches a different conclusion;
   • · Saying nothing about the access framework under Chinese law, which stalls customer diligence for longer, not less.

9. 9. 9. Risk identification, rating and mitigation

   Arts. 35(7)(c) and (d) require the risks to be assessed from the data subject’s perspective — not the company’s — and the measures envisaged to be determined. Annex 2 of wp248rev.01 sets the method: take risk sources into account; identify the potential impacts on rights and freedoms from illegitimate access, undesired modification and disappearance of data; identify the threats that could lead to those events; and estimate likelihood and severity. Build it as a risk register: risk id / scenario written as a consequence for an individual (e.g. "an applicant is systematically screened out because of training-data bias") / risk source / likelihood / severity / inherent rating / mitigation / owner and deadline / residual rating / whether the residual risk is acceptable and who decided. For AI, cover at least: discrimination from training-data bias; data leakage through memorisation; reputational harm or wrong decisions from hallucinated output; incorrect entity linking that attributes behaviour to the wrong person; use of the model beyond its intended purpose; and failure of one link in the supply chain.

   Evidence to attach

   • · Risk register with both inherent and residual ratings
   • · Bias and fairness test results, with subgroup metrics and sample sizes
   • · Implementation evidence and sign-off for each mitigation
   • · Signed acceptance of residual risk, naming the signatory and their role
   • · Mitigations considered and rejected, with the reasons

   Common pitfalls

   • · Risks written as risks to the company ("fines", "reputational damage") rather than impacts on individuals;
   • · Every risk dropping to "low" after mitigation with no residual risk at all — reviewers read this as a dishonest assessment;
   • · Mitigations that say "will be strengthened", with no owner, no deadline and no acceptance criterion;
   • · Fairness testing reported only as overall accuracy, with no subgroup metrics to support a no-discrimination conclusion.

10. 10. 10. Consultation, prior consultation and sign-off

    Art. 35(2) requires the DPO’s advice where one is designated, and Art. 35(9) requires the views of data subjects or their representatives where appropriate. Leave a trace of both: the DPO’s advice verbatim including any reservations, and the method and outcome of seeking data subjects’ views — or the specific reason for not doing so, such as commercial or security interests. Then decide whether Art. 36(1) prior consultation is triggered: if the risk remains high after mitigation, the supervisory authority must be consulted before processing begins. Art. 36(2) gives the authority up to eight weeks to give written advice, extendable by six weeks for complex cases, with the clock suspended while it waits for information you have been asked to supply — plan on that order of magnitude, not a two-week turnaround. Close with the approval: who signed, in what role, on what date, and which system version the approval covers.

    Evidence to attach

    • · The DPO’s written advice and a record of how it was addressed
    • · How data subjects’ views were sought and what came back, or the specific reason for not seeking them
    • · Determination of whether prior consultation is triggered (does high risk survive mitigation)
    • · Where submitted: the Art. 36(3) document pack and the authority’s response
    • · Approval record naming signatory, role, date and the version covered

    Common pitfalls

    • · DPO advice reading only "no objection", which shows no actual involvement and fails the Art. 38(1) duty to involve the DPO properly and in a timely manner;
    • · Identifying high residual risk yet neither consulting nor recording why consultation was thought unnecessary;
    • · Budgeting two weeks for what Art. 36(2) sets at up to eight weeks, extendable by six, and having to delay launch;
    • · The signatory being a project manager rather than management with authority to accept the risk.

11. 11. 11. Review triggers and version control

    Art. 35(11) requires a review where necessary, at least when the risk represented by the processing changes. Define "changes" as detectable triggers rather than "periodic review": a major model version or a change of base model; a new training-data source or collection method; a new purpose or a new country of launch; adding or replacing a processor or sub-processor; a personal data breach or a significant complaint; and a change in applicable law (for example the EU AI Act high-risk rules becoming applicable, or an updated national list). Each review records: what triggered it, what changed, whether the risk level moved, and whether the DPO’s advice or prior consultation must be sought again. Version-control the document itself and state on the front page which system versions this edition covers, so a reader can tell whether the copy in hand is still current.

    Evidence to attach

    • · List of review triggers and how each is monitored
    • · Version history table (version, date, trigger, change summary, approver)
    • · The most recent review record and its conclusion
    • · How this hooks into change management and release process (which release gate checks DPIA currency)

    Common pitfalls

    • · Committing to an annual review while the model ships a dozen versions a year, so the DPIA has long since drifted from the running system;
    • · No version history, so it cannot be shown the assessment was completed before processing began;
    • · A review process not wired into the release pipeline, and therefore never actually triggered;
    • · Regulatory change — such as high-risk rules becoming applicable — missing from the trigger list.