GDPR and AI: Automated Decision-Making Obligations
The thing nobody tells you when you stand up an AI project in Europe is that the regulator most likely to come knocking is not the new AI regulator. It is the privacy regulator. They have a decade of enforcement muscle, a working complaint pipeline, and a law (the GDPR) that has been quietly governing AI since 2018, before most people called it AI. Privacy law is AI law by another name, and Article 22 is the door you walk through first.
In the conversation I follow across the professional AI rooms, data privacy and regulatory compliance co-occur more than any other pair of concepts. That is not noise. It is the field telling you which two obligations move together in practice, and which authority will be on the phone first.
What Article 22 actually says (and what it does not)
Article 22 of the GDPR gives an individual the right not to be subject to a decision based solely on automated processing, including profiling, that produces a legal effect or similarly significant effect on them. Three words in that sentence do almost all the work, and most teams misread at least one of them.
Solely means no meaningful human involvement. A recruiter who rubber-stamps the model’s reject list is not meaningful involvement; a human who reviews, has the authority to overturn, and routinely does so, is. The bar is real participation in the decision, not a name in an audit log.
Legal effect is straightforward: the decision changes your legal rights or status. Denied a visa. Denied a contract. Refused entry.
Similarly significant is where the surprise lives. It catches decisions that do not change your legal status but materially affect your life: a refused loan, a refused insurance policy, a rejected job application, a denied tenancy, a price you are quoted that others are not, an account suspension that cuts off your livelihood. Behavioural advertising of trivial products is usually out; consequential commercial decisions are usually in. The European Data Protection Board’s guidelines on automated decision-making and profiling are the canonical read.
What Article 22 does not do is ban these systems. It restricts them to specific legal bases, and it attaches rights the data subject can exercise once a decision lands.
The three legal bases that make a solely-automated decision permissible
If your AI decision is solely automated and significant, you cannot just run it. You need one of three grounds:
- Necessary for entering into or performing a contract between you and the data subject. A bank scoring a loan application the applicant just submitted often fits here; the customer asked for the service and automated processing is genuinely necessary to deliver it at scale.
- Authorised by Union or Member State law that also lays down suitable measures to safeguard rights. Some fraud screening and tax-risk scoring sits here, where a specific statute permits the practice and prescribes safeguards.
- Explicit consent from the data subject. The high bar word is explicit. A pre-ticked checkbox in a terms-of-service flow is not explicit; a separate, clearly worded opt-in is.
Even when one of the three grounds applies, the GDPR requires safeguards: at minimum, the right to obtain human intervention, the right to express a point of view, and the right to contest the decision. These are not optional add-ons. They are the conditions on which the legal basis stands.
The right-to-explanation question
There is a long argument about whether GDPR creates a right to an explanation of an individual automated decision, or only a right to information about the logic involved before the fact. Articles 13, 14, and 15, plus Recital 71, together require meaningful information about the logic, significance, and envisaged consequences of automated processing. Most regulators and the EDPB read this as obliging genuine, intelligible transparency: not the model weights, but a description a normal person can understand of what the system considers and how.
In practice, the safe operating posture is straightforward: assume you owe the data subject an explanation they can act on. Tell them what categories of data fed the decision, what the main drivers were in their specific case, and what they can do about it (correct data, provide more, request human review). A team that can produce that on demand is a team that has built explainability into the system, not bolted it on at complaint time.
The DPIA trigger and what it forces you to do
A Data Protection Impact Assessment is not a paperwork ritual; it is the forcing function that pulls AI risk thinking forward to the design phase. For AI, the DPIA trigger almost always fires: systematic and extensive evaluation of personal aspects based on automated processing, large-scale processing of special-category data, and systematic monitoring of publicly accessible areas all sit on most national supervisory authorities’ mandatory-DPIA lists.
A DPIA done well asks four practical questions before a line of production code ships: what personal data does this system use and why, what could go wrong for the people in the data, what controls reduce that risk, and what residual risk remains and who signs it off. If you cannot answer those four, you do not have a DPIA, you have a memo. If the residual risk stays high after controls, you owe a prior consultation with the supervisory authority before going live. Most teams skip that last step; it is not optional.
Controls that satisfy GDPR and the EU AI Act at the same time
The good news for any team building under both regimes is that the controls overlap heavily. The EU AI Act human-oversight, data-governance, logging, and transparency duties for high-risk systems are largely the same controls the GDPR has been asking for since 2018, just expressed in AI-specific language. If you design once for the privacy regime, you cover most of the AI-Act ask for free.
Five controls do the heavy lifting on both sides:
- A meaningful human checkpoint in the decision workflow, with the authority to override and a measurable override rate. Empty checkpoints fail both regimes.
- Purpose-limited training data with documented lineage. Where did it come from, what was the lawful basis, what was excluded and why.
- Logging by default, retaining inputs, outputs, decisions, overrides, and the version of the model that ran. Logging-on-request is not logging.
- An explanation surface the data subject can reach, not a model card buried on a developer portal. The recruiter, the loan officer, the customer service agent: they need a one-screen view they can read back.
- Data subject rights plumbing: access, rectification, erasure, and the Article 22 specifics (human intervention, contest, point of view). The bug to avoid is treating these as a ticketing problem; build them into the product.
A worked test for “does Article 22 catch this”
Three questions, in order. Is the decision solely automated in practice (no meaningful human review)? Does it produce a legal or similarly significant effect (loan, job, insurance, tenancy, price, account access)? Do you process personal data about an identified or identifiable person to make it? Three yeses and you are inside Article 22. Pick a legal basis, build the safeguards, run the DPIA, write the explanation surface. The order is not optional, but the work is finite, and the teams that do it once stop being afraid of the next product review.
