An organization deploying an AI hiring tool in the European Union will, at some point, be asked for two different documents by two different reviewers. A data protection authority will ask for the Data Protection Impact Assessment required by GDPR Article 35. An AI Act conformity reviewer, if the tool falls into a high-risk category, will ask about human oversight, technical documentation, and risk management under the EU AI Act. These are not the same document, and treating them as if they were is one of the more expensive mistakes an organization can make while building an AI governance program.
This series has spent nineteen articles moving between two questions that turn out to be closely related but not identical: does this system's use of personal data create a privacy risk, and does this system's output distribute unfairly, or without recourse, across the people it decides about. The GDPR was built to answer the first question. The EU AI Act was built to answer the second. Where they overlap is exactly where most automated decision systems live.
What the GDPR Actually Requires
Article 22 of the GDPR restricts solely automated decisions that produce legal effects or similarly significantly affect a person. It is a narrower legal test than it sounds — it does not ban automated decision-making outright, and it applies specifically to decisions made without meaningful human involvement. Article 35 sits alongside it: a Data Protection Impact Assessment is mandatory for any processing "likely to result in a high risk" to rights and freedoms, and Article 35(7) specifies the minimum elements a DPIA must document — a description of the processing, an assessment of necessity and proportionality, a risk analysis, and the mitigation measures adopted.
The Court of Justice of the European Union has already tested how far Article 22 reaches. In the SCHUFA ruling of December 2023, the court held that a credit bureau generating a score is itself making an automated decision under Article 22 when a lender relies heavily on that score to grant or refuse a contract — neither the scorer nor the lender using it can hide behind the other. That is a privacy-law finding. It says nothing about whether the scoring model itself is fair, well-tested, or built on records that should have been trusted as training material in the first place.
What the EU AI Act Adds on Top
The AI Act works from a different starting point. Article 5 creates a category of practices that are not high-risk systems waiting for safeguards, but unacceptable systems that cannot be deployed at all — social scoring that produces unjustified detrimental treatment, untargeted scraping of facial images to build recognition databases, and certain uses of real-time remote biometric identification in public spaces for law enforcement, among others. The prohibitions became applicable in February 2025, after the Act entered into force in August 2024.
For systems that clear that bar and are classified as high-risk, Article 14 requires them to be designed so that real people can oversee them while they run — not people merely present near the system, but people able to understand its limits, resist automation bias, and disregard, override, reverse, or stop the system when intervention is required. Article 86 adds a narrower companion right: an affected person in a covered high-risk deployment can require a clear and meaningful explanation of the system's role and the main elements of the decision that concerned them.
Same Trigger, Two Different Obligations
The overlap becomes concrete the moment a single system trips both frameworks at once. The PIA Quick Check's third question — will an algorithm or automated system make decisions that affect people's lives — is exactly the trigger for a full Privacy Impact Assessment under the GDPR, the LGPD, and Quebec's Law 25 alike. But that same automated decision, if it operates in the EU and falls into a high-risk category, does not stop being a privacy question once the DPIA is filed. It also becomes an AI Act question: is there a named human with actual authority to reverse the output, not just review it? Can the affected person get a specific, actionable explanation, not a general description of the model? Is the system's decision chain documented well enough to survive an audit?
A DPIA that only asks whether personal data is being processed lawfully will not catch a MiDAS-style failure, where the explanation was never the missing piece — the missing authority was. And an AI Act conformity file that only documents technical risk management will not catch a SCHUFA-style failure, where the privacy question was who could challenge the scorer, not just the lender. Each framework asks a real question the other one misses.
The Practical Overlap Checklist
- Privacy trigger (GDPR Art. 35 / LGPD Art. 38 / Law 25 §3.3): does the system process personal data in a way likely to create high risk, or make a solely automated decision with significant effects? If yes, a DPIA or equivalent is mandatory.
- AI Act refusal check (Art. 5): does the system fall into a prohibited category — social scoring, untargeted biometric scraping, certain real-time public biometric identification? If yes, the answer is not mitigation. It is refusal.
- AI Act oversight check (Art. 14): if the system is high-risk but not prohibited, is there a named human with the time, access, and authority to actually reverse an output — not merely review one?
- AI Act explanation check (Art. 86): can the affected person get a specific, case-relevant explanation of the decision, not a generic model description?
- Recourse check (GDPR Art. 22 as read in SCHUFA): can the person challenge the party that generated the score, not only the party that relied on it?
One Governance Process, Not Two Silos
The instruments differ in design, scope, and enforcement theory, and this series has treated them separately for good reason — each deserved its own careful reading. But an organization running its privacy program and its AI governance program as two unconnected workstreams will end up documenting the same system twice, in two files that never speak to each other, and missing the questions that only appear at the seam between them. The practical fix mirrors the one this series proposed for PIA versus DPIA terminology: build one underlying risk-and-governance methodology, and generate the specific document each regulator or reviewer asks for from that single source of truth.
This closing article connects both halves of this series — the Privacy Impact Assessment discipline and the algorithmic accountability discipline — because in practice, for any consequential automated system, they were never really two separate questions. Building the single process that answers both is exactly what PIA Studio is being built to support.