Responsible AI
GDPR, DPIAs, and Automated Decision-Making
Apply GDPR principles, controller and processor roles, DPIAs, data-subject rights, Article 22, and AI-model privacy analysis.
By the end you can
- Explain why GDPR AI governance connects processing principles, lawful basis, roles, DPIA risk, rights, profiling, and meaningful safeguards for automated decisions
- Distinguish Human-in-the-loop formality, Meaningful human involvement, and Decision support without significant effect
- Identify evidence that connects processing facts to safeguards and evidence
- Design a review that moves from map processing and roles to operate data-subject rights
A vendor that decides purposes is not a processor
Every GDPR question about an AI system starts with the same three facts: what is processed, for what purpose, by whom. The processing has to be lawful, fair, transparent, purpose-limited, necessary, accurate, secure and accountable. High-risk processing may require a DPIA. A solely automated decision with legal or similarly significant effects gets its own analysis and its own safeguards under Article 22.
A DPIA is not a form. It is a living assessment: of the processing operations, of their necessity and proportionality, of the risks to people's rights and freedoms, and of the measures that address those risks.
A team that builds and deploys a model has more to settle than that. Personal-data status. Anonymization claims. Legitimate interests. Special-category data. Then data-subject rights, retention, security, controller–processor roles and international transfers.
The lender's story breaks at roles. A vendor that decides the purposes is not a processor, whatever noun the contract uses.
Settle who decides the purposes first. Get the controller question wrong and every duty that follows it is misassigned — DPIA, Article 22, transfers, rights handling.
Predict first
Does the GDPR name credit profiling itself?
Article 35(1) GDPR requires a data protection impact assessment wherever a type of processing is likely to result in a high risk to people's rights and freedoms. A lender pre-screening credit applications with a model has to decide whether that test catches it.
Make a prediction before reading on. Does the regulation leave that judgment to each controller, or does it name this kind of automated profiling, with significant effects, as a case that always needs an assessment? If it names it, where?
Settle on an answer, then read on — the next section is the reveal
Case
Article 35(1), and the case it names outright
The assessment is owed before the processing starts, not after it goes wrong. Article 35(1) requires one wherever a type of processing "is likely to result in a high risk to the rights and freedoms of natural persons". Article 35(3)(a) names one such case outright: "a systematic and extensive evaluation of personal aspects ... based on automated processing, including profiling". The decisions have to produce legal or similarly significant effects.
Pre-screening credit applications with a model fits that description.
Case
Article 35(7) lists what it must contain
Article 35(7) then says what has to be inside the assessment. A systematic description of the processing and its purposes. An assessment of necessity and proportionality. An assessment of the risks to the rights and freedoms of data subjects. And the measures envisaged to address those risks.
Roles are settled the same way — by function, not by the noun in the contract. A vendor that determines purposes is a controller.
Visual
From the processing facts to the safeguards
Five things, in order. The processing facts. The basis and principles that must hold. The rights that attach. The assessment that weighs the risk. The safeguards that have to work in practice.
Get the first one wrong and the other four describe a system nobody is actually running.
- 1
Processing facts
Purposes, data categories, sources, people, actors, flows, retention, and recipients.
- 2
Lawfulness and principles
Legal basis, fairness, transparency, minimization, accuracy, purpose, and accountability.
- 3
Rights and decision effects
Access, correction, objection, deletion, restriction, portability, and automated-decision safeguards.
- 4
DPIA risk analysis
Necessity, proportionality, likelihood, severity, vulnerable people, and power.
- 5
Safeguards and evidence
Human review, recourse, security, testing, minimization, governance, and consultation.
Example
The click that was called human review
A lender pre-screens applications with a model. Staff usually accept its recommendation. Applicants receive no useful reason. The vendor calls itself a processor. And the company says Article 22 does not apply, because a human clicks "confirm".
- Role and purpose: Controller responsibilities follow the real purposes and means, not the contract label.
- Meaningful involvement: A formal click may not stop a decision from being effectively automated.
- Legal effect: A credit denial has significant consequences for the applicant.
- Information rights: Applicants need intelligible information and a usable route to challenge.
- DPIA scope: The risk comes from profiling, data sources, power asymmetry, effects and safeguards across the whole workflow.
Steps
The Article 22 analysis sits in the middle
Five steps, from the processing record to the rights workflow. The automation question is settled at step three, in the middle.
Everything after it depends on the answer you give there.
1. Map processing and roles
Document purposes, means, actors, data, sources, flows, decisions, and retention.
2. Test principles and lawful basis
Assess necessity, proportionality, fairness, minimization, accuracy, and transparency.
3. Analyze profiling and Article 22
Examine automation, human involvement, legal or similar effect, and safeguards.
4. Conduct and consult on the DPIA
Evaluate rights risks, measures, residual risk, and prior consultation where required.
5. Operate data-subject rights
Provide notice, access, correction, objection, challenge, review, and deletion workflows.
Example
The pre-screening lender, through the five steps
A lender uses a model to pre-screen applications, staff usually accept its recommendation, applicants get no useful reason, the vendor describes itself as a mere processor, and the company says Article 22 does not apply because a person clicks 'confirm'. The quiz below is built on this invented case. Here it is run through the five steps. Every figure is invented for the exercise.
- Map processing and roles: the vendor trains its model on the lender's applications together with other clients' data and decides how long to keep them. A party that decides purposes is not acting as a processor, whatever the contract calls it, so the roles are assessed on these facts.
- Test principles and lawful basis: the model reads 46 fields. For 9 of them, such as device type, nobody can document a link to creditworthiness; necessity is not shown, and they are removed.
- Analyze profiling and Article 22: an observation of 1,000 pre-screened applications finds 992 recommendations confirmed, an override rate of 0.8%, at a median of 90 seconds a case, with nothing in front of the reviewer but the score. The click is a formality, so the analysis proceeds as if the decision were solely automated, and counsel is asked to confirm.
- Conduct and consult on the DPIA: the assessment records the profiling, the 9 removed fields, the vendor's real role and the remaining risk. If the measures leave a high risk standing, the supervisory authority is consulted before the processing continues.
- Operate data-subject rights: refused applicants receive their main reasons and a route to a person who can change the result. In the first month 31 ask for review and 7 decisions change; all 7 trace to one field error, which is corrected for every applicant.
Analogy
A permit for an ongoing industrial process
A permit asks what a facility processes, why that is necessary, who is exposed and which safeguards operate. Granting one is not the same as the facility being safe for the next twenty years.
The analogy then breaks, in a useful place. A permitted plant emits where an inspector can stand. Personal data is copied, inferred from other data, joined to records the assessment never listed, and reused in a context nobody applied for. The plant stays where you left it. The data does not.
A DPIA should remain connected to the real processing and change when the system or risk changes.
Key idea
What evidence about GDPR and AI data governance cannot prove
Calling model data "anonymous" settles nothing. Nor does adding a nominal reviewer. The EDPB asks for case-specific assessment: of anonymity, of legitimate interests, of unlawfully processed training data, of deployment context. Reading the GDPR depends on facts, national law, regulator guidance and case law.
Case law moves the ground under a deployment. A credit reference agency that produces an automated probability score is itself carrying out an automated individual decision under Article 22(1), where the lender draws strongly on that score. The Court of Justice held that on 7 December 2023, in Case C-634/21. The duties do not sit with the lender alone.
So product and data teams should preserve the evidence that counsel and privacy officers will need. Encoding legal conclusions into generic templates is the opposite of that. Meanwhile the lender's vendor calls itself a processor and decides the purposes, and a member of staff clicks confirm inside ninety seconds.
A template that pre-fills the legal conclusion destroys the only thing counsel could later re-examine: the facts.
Comparison
Formality, Meaningful involvement, or No significant effect?
A person in the workflow, a person who can change the outcome, and a process without significant effect are three different legal positions. Only the middle one is meaningful involvement.
None of the three leaves GDPR behind.
Human-in-the-loop formality
A person appears in the workflow.
- May have no real discretion
- Can be anchored by the model
- May lack evidence or time
- Does not automatically avoid Article 22 analysis
Meaningful human involvement
A qualified person independently reviews and can change the outcome.
- Requires authority and competence
- Needs relevant information and time
- Should be monitored in practice
- May alter the legal characterization
Decision support without significant effect
AI informs a lower-consequence process.
- Still subject to GDPR principles
- May still require a DPIA depending on risk
- Needs transparency and rights support
- Not automatically outside all safeguards
Example
What reviewers do, against what the procedure says
Watch the reviewers first. Then read the procedure that claims to describe them.
- Human-review observation: Watch reviewers handle real cases and test whether they examine the evidence independently.
- DPIA risk table: Connect each processing operation to a specific rights harm and a concrete safeguard.
- Rights request drill: Trace an access, correction, objection and deletion request through models and derived records.
- Anonymity challenge: Document the realistic means by which a party could identify or single out a person.
Findings about operation, not statements in a policy
Lawfulness, necessity and the reality of human review are findings about operation. They are not statements in a policy.
So decide in advance what would change the deployment. Name the assessment outcome, the rights-request failure or the reidentification result that would force the provider to redesign, restrict, remedy or retire the system. A stop rule written afterwards is not a stop rule.
Key takeaways
- GDPR reaches an AI system through processing facts: purposes, data, actors, effects and safeguards.
- Contract labels do not settle who is the controller and who is the processor.
- A DPIA weighs necessity, proportionality, rights risks, safeguards and residual risk — and keeps doing it over time.
- Nominal human involvement may not stop a decision from being effectively automated.
- Anonymity and legitimate-interest claims need case-specific evidence, not a label.
- Data-subject rights need workflows that actually reach source, derived, model and decision records.