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.
Case
Article 35(1) and 35(3)(a): when a DPIA is owed
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.
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.