GDPR Automated Decision-Making: What Article 22 Means for Your AI System

TL;DR:

• GDPR Article 22 restricts solely automated decisions that produce legal or similarly significant effects on individuals.
• If all three conditions apply, organizations must implement genuine human review or provide safeguards including explanation, contestation, and decision logging.
• This guide explains when Article 22 applies and what engineers need to build.

Most AI systems that process personal data don’t trigger Article 22 — a recommendation engine, a fraud alert, a churn prediction model all fall outside its scope, provided a human makes the final call. Engineering teams usually assume that “meaningful” human involvement means someone clicked “approve”. It doesn’t.

Across the compliance assessments that Corpsoft Solutions has conducted for European AI deployments, a consistent pattern emerges: engineering teams add a human reviewer to the decision flow and conclude that they have satisfied Article 22. When we examine the reviewer interface, it typically surfaces only the model’s output score. The input features that produced it — the 40, 60, or 100 variables the model actually evaluated — are not accessible to the reviewer. That architecture is unlikely to satisfy the standard reflected in the CJEU’s reasoning in SCHUFA Holding.

Understanding the full scope of GDPR algorithmic decision-making obligations starts with what Article 22 actually says — and what it does not. If your system also needs to meet GDPR requirements at the infrastructure level — logging, tracing, and model versioning — GDPR-Compliant AI: What Engineers Need to Log, Trace, and Explain covers those requirements in depth.

What Article 22 of GDPR actually says

Article 22(1) of GDPR gives data subjects a right: the right not to be subject to a decision based solely on automated processing — including profiling — which produces legal effects concerning them or similarly significantly affects them. The full text is available on EUR-Lex.

Three conditions must all be present for GDPR Article 22 automated decisions obligations to apply.

The three conditions that trigger Article 22

1. Solely automated processing — no genuine human involvement in the decision itself, not in the interface around it.
2. Significant effect — the decision produces a legal or similarly significant outcome for the individual.
3. Natural person as subject — the decision concerns a living individual, not a legal entity.

All three must be true simultaneously. If your model recommends a loan decision and a trained officer independently evaluates each case using the full feature breakdown, Article 22 may not apply. If the officer clicks “decline” without reading the rationale behind the score, it likely does.

What Article 22 does not require

Article 22 is frequently read as broader than it is. Before examining what it requires, it is worth stating what it does not:

• Disclosure of model weights, architecture, or training data to data subjects
• Explanation of every mathematical operation in the decision process
• Human review of every automated workflow — only those where all three conditions are simultaneously met
• A prohibition on AI in decision processes — a restriction on specific configurations of automated processing
• A DPIA specifically for Article 22 (though one may be required separately under Article 35 where high-risk processing is involved)
• Open-sourcing the model or abandoning automation entirely

Article 22 targets a specific risk: decisions that significantly affect real people, made by systems that no human is genuinely in a position to evaluate or override. Systems outside that scope are not affected.

When Article 22 applies — the decision matrix

The table below maps common AI deployment scenarios against the three conditions:

Several of the scenarios above involve GDPR profiling — automated evaluation of personal characteristics that feeds into the decision. What counts as significant effects GDPR recognizes? Recital 71 names two specific examples: automatic refusal of an online credit application and e-recruiting practices without human intervention. The EDPB/WP29 Guidelines on Automated Individual Decision-Making and Profiling extend the scope to denial of service, unreliable credit scoring, insurance pricing decisions, and access to healthcare and education. 

Healthcare AI systems that trigger Article 22 in the EU and also operate in the US typically need to satisfy GDPR automated decision making requirements alongside HIPAA Compliance Development safeguards simultaneously.  The “depends” rows are where most enforcement risk lives: systems that route to a human queue are not automatically exempt — the quality of review determines whether the processing is “solely automated.”

Gray-area systems

Several AI use cases sit at the boundary of Article 22 scope and generate the most compliance questions in practice:

Dynamic and personalized pricing. Where pricing is based on profiling of the individual — creditworthiness, location, purchase history — and the resulting price is significantly higher than a baseline, the “significant effect” condition may be met. Generic promotional pricing applied uniformly to a customer segment typically falls outside scope.

AI content moderation. Automated removal of a single post is unlikely to constitute a significant effect. Automated account suspension or permanent bans affecting access to a service may cross the threshold, particularly where the individual relies on the platform commercially.

Internal HR scheduling and performance tools. AI systems used for shift allocation or performance scoring can trigger Article 22 where outcomes influence pay, promotion, or disciplinary action. The EDPB identifies employment as a high-risk category for automated processing.

Insurance fraud scoring. Where an automated fraud score directly determines whether a claim is paid or investigated, Article 22 applies. Where it adds a risk flag to a file that a human adjuster genuinely evaluates with full access to the underlying evidence, the “solely automated” condition may not be met.

AI systems classified as high-risk under the EU AI Act frequently overlap with Article 22 scope — both frameworks impose obligations that reinforce each other in practice. Our AI Governance in Practice guide covers how to design a single architectural review that satisfies both. 

Organizations operating critical infrastructure in the EU face a similar overlap — Article 22 obligations for automated operational decisions frequently intersect with NIS2 Compliance Development requirements for the same systems. 

Is Article 22 triggered? Four questions to ask

Before assessing compliance requirements, confirm whether Article 22 GDPR applies to your system: 

1. Does the decision concern a natural person? If not — Article 22 does not apply.
2. Is the processing solely automated? Apply the SCHUFA functional test: could the human reviewer, with the information available to them, genuinely deviate from the model’s output? If yes, the processing is not solely automated. If no, it likely is.
3. Does the decision produce legal or similarly significant effects? When in doubt, apply the conservative reading: if the outcome materially affects the person’s financial, professional, or physical circumstances, assume the condition is met.
4. Does a valid exemption under Article 22(2) apply? If all three conditions are met: is the processing necessary for a contract, authorized by law, or based on explicit consent? If a valid basis exists, Article 22(3) safeguards are mandatory. If no valid basis exists, solely automated decision-making with significant effects is prohibited.

Exemptions under Article 22(2)

Article 22 does not apply where the automated decision is:

• Necessary for a contract — e.g., a bank’s automated credit check required to issue a loan
• Authorized by EU or member state law — with appropriate safeguards in place
• Based on explicit consent — the data subject has explicitly agreed to the processing

Even where an exemption applies, Article 22(3) requires the controller to implement “suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests” — at minimum, the right to obtain human intervention, to express a point of view, and to contest the decision. The exemption removes the prohibition; it does not remove the obligations.

The fintech review queue — a case from a deployment we reviewed

In one fintech deployment we reviewed, a European lending platform scored loan applications and routed them into three queues: auto-approve, auto-decline, and human review. Auto-approved applications were processed and funded without a reviewer. Auto-declined applicants received a rejection email with a reference number — no explanation of the logic, no indication that a review was available.

The human review queue processed a high volume of cases per day, handled by a small team of reviewers. Each reviewer saw the applicant’s name, the risk score, and a brief summary. The full feature breakdown — the dozens of variables the model had weighted — was not surfaced in the review tool. In practice, reviewers approved or declined based on the score, because there was no other basis for independent evaluation.

Article 22 applied to both the auto-approve and auto-decline flows without question. To bring the auto-decline path into compliance, the platform needed to log input features at inference time, generate a per-decision explanation, surface it in the rejection communication, and build a documented contestation path. None of those were in place.

The human approval misconception

The most common Article 22 misread in engineering teams: “We have a human who approves each decision, so we’re exempt.”

The human in the loop GDPR standard is not a checkbox. It is a functional test.

Article 22(3) requires safeguards that include “at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision.” The operative word is intervention — the human must be capable of actually changing the outcome based on independent evaluation.

The Court of Justice of the European Union addressed this directly in SCHUFA Holding (Case C-634/21, CJEU, 7 December 2023). SCHUFA is a German credit reference agency whose automated credit scores feed directly into bank lending decisions. Banks argued they were exempt from Article 22 because a human loan officer technically made the final credit determination. The CJEU rejected the argument.

Where an automated score effectively determines or strongly influences the outcome of a subsequent human decision, Article 22 applies to that score — regardless of who formally signs the approval. A human step does not break the “solely automated” chain where the human lacks the practical ability or information to deviate from the automated output. The full judgment is available at curia.europa.eu.

In the review queues we have assessed across financial services deployments, a consistent picture emerges: the reviewer is given a name, an ID, and a score. The underlying evidence — the feature values, their relative weights, the confidence distribution — is either absent from the interface or buried in a separate system that reviewers do not open under time pressure. An interface that obscures the evidence does not produce substantive review, regardless of what the log records.

Human review fails the Article 22 functional test when:

• The reviewer has access only to the output score — not the input features.
• The review queue exceeds what one person can genuinely evaluate per day.
• The interface defaults to “approve,” requiring active override to reject.
• The system logs reviewer name and timestamp but not what was assessed.
• The reviewer has no documented authority or mechanism to override the model.

Not sure whether your review process qualifies as genuine under Article 22? Corpsoft Solutions assesses your workflow against the CJEU’s functional test and identifies what needs to change. Assess your review process →

What data subjects get under Article 22

Where Article 22 applies, data subjects have three active rights that create direct engineering requirements.

#1 The opt-out right — and how to build for it

As Article 22(1) establishes, the right not to be subject to automated decision-making is the default position for data subjects, not a preference to register — a baseline protection that applies unless a valid exemption under Article 22(2) exists. 

Where the lawful basis is consent under Article 22(2)(c), data subjects can withdraw that consent at any time under Article 7(3). The withdrawal mechanism must be as straightforward as giving consent, and the system must respect it immediately — meaning the opt-out must propagate to the decision pipeline, not just to a preference field in a user profile.

Where the basis is contract or law, the opt-out right is more constrained, but the controller must still document the necessity of automated processing and provide an alternative path for data subjects who object. Engineering implications: your system needs a preference flag at the subject level, routing logic that bypasses automated processing where that flag is set, and an audit trail showing the opt-out was respected. Corpsoft Solutions’ GDPR-compliant software development practice builds these controls into the data layer from the start, not as a retrofit.

If your system has no opt-out pathway and no documentation of why none is needed, that is a compliance gap regardless of which exemption basis you rely on.

#2 The right to explanation — what it means for engineers

GDPR requires providing “meaningful information about the logic involved” in an automated decision (Articles 13 and 14), which is commonly known as the right to explanation GDPR grants to data subjects. This is not a full disclosure of model weights or architecture. It covers:

• The main factors that influenced the specific decision
• The relative weight of those factors
• The likely impact of different factor values on the outcome

The explanation must reflect the specific decision made — not a general description of how the model works. Post-hoc explanations generated from a different model run may not satisfy this requirement. A defensible implementation is one that generates and stores a per-decision feature importance output at inference time, tied to the specific inference record.

#3 The right to contest — this is an engineering requirement

The data subject can contest the automated decision and request that a human re-evaluate it. Your system must have:

• A documented intake mechanism for contestation requests
• Routing logic that assigns the request to a qualified reviewer
• Reviewer tooling that surfaces the original decision record and feature breakdown
• A response process that communicates the outcome and its specific basis — not generic language

This is not a customer service process you can handle with a contact form and an email template. The intake, routing, reviewer tooling, and response audit trail all need to be built and maintained as part of the system.

Engineering requirements for Article 22 compliance

The controls below map to Corpsoft Solutions’ AI Compliance Stack — our framework for structuring technical compliance across decision logging, audit trail architecture, explainability, and rights infrastructure. Article 22 touches all four layers. A gap at any layer creates enforcement exposure 

Decision logging

Every automated decision that may fall under Article 22 must be logged at the point of execution — not reconstructed later. Each log record should include:

• Decision ID and timestamp
• Subject identifier (pseudonymized where possible)
• Model version and configuration hash
• Input feature values as received by the model
• Output: score, class, or decision flag
• Confidence or probability distribution where available
• Routing outcome: approved / declined / flagged for review
• Opt-out status at the time of processing

During architecture reviews, we consistently find decision logs that record only the prediction output — the score or class label. The input feature values the model actually processed are absent. When a data subject later requests an explanation, the team can confirm the decision was made but cannot reconstruct why. At that point, a missing log entry becomes a rights violation.

Audit trail architecture

A dedicated GDPR AI audit trail is distinct from application logs. Key differences:

GDPR does not specify a retention period directly. Many organizations in financial services, insurance, and HR set a minimum of three years for Article 22 audit records — though the appropriate period depends on the legal context and the ongoing effects of the decision, and should be determined as part of a broader records management review.

Would your current audit trail survive a regulatory investigation? Corpsoft Solutions reviews your decision logging architecture against Article 22 requirements  Check your logging architecture → .

Explainability at the decision level

GDPR explainable AI requirements are per-decision, not per-model. A documentation page describing how your model works in general does not provide a data subject with substantive information about their specific case.

In practice, generating and storing per-decision feature importance at inference time is one of the most defensible approaches to GDPR AI compliance. SHAP values, LIME outputs, or attention weights can all serve this function — the requirement is functional, not technical. What matters is that the explanation is tied to the specific inference and stored with the decision record.

A pattern we consistently see in compliance reviews: a team implements SHAP values but runs the explainability pipeline as a batch job the following morning. When the model is retrained months later, reconstructing explanations from the earlier version becomes impractical. The infrastructure is in place; the implementation detail is what makes it non-compliant. Generating explanations at inference time is the most robust pattern — later reconstruction may no longer reflect the model or input data as they existed at the point of decision.

For deep learning architectures where per-decision explainability is technically complex, the compliance burden shifts toward system design: either limit automated decision-making to model types that support per-decision interpretability, or implement genuine human review that can substitute for it.

5 common Article 22 implementation mistakes

The following gaps appear consistently across Article 22 compliance reviews:

1. Logging only the prediction. Output score or class label stored; input feature values not. Makes per-decision explanation impossible and leaves the organization unable to respond to a right-to-explanation request.
2. Deleting model versions after retraining. If the model version active at the time of a decision cannot be produced, the decision cannot be verified or reconstructed. Regulatory investigations routinely request model version records.
3. Human review interfaces that show only the score. Structurally prevents genuine review. No matter how qualified the reviewer, they cannot exercise independent judgment without access to the underlying evidence.
4. Post-hoc explanation generation. Running explainability code after the fact — the next morning, on request, or after a complaint — does not satisfy the right to explanation if the model has since been retrained or the input data cannot be recovered.
5. Opt-out flag stored only in a CRM or marketing platform. The opt-out must propagate to the decision pipeline. A preference stored in a customer-facing system that is not read by the model inference layer does not protect the data subject.

What regulators ask for when investigating an Article 22 complaint

When a supervisory authority investigates a complaint under Article 22, they typically request:

• The decision record: decision ID, timestamp, and subject identifier
• The model version active at the time of the decision — not the current version
• The input data as processed by the model — not a reconstruction
• Reviewer notes, if human review was claimed as the basis for the “solely automated” exemption
• The explanation provided to the data subject at the time of the decision, or the mechanism through which it could have been requested
• Evidence of the contestation mechanism and its outcome, if the decision was contested

Teams that have not maintained a separate audit trail — distinct from application logs, retained beyond the standard log rotation window — consistently find themselves unable to produce items two, three, or four. Teams that relied on post-hoc explanation generation cannot produce item five. Both situations convert a manageable complaint into an investigation that is difficult to close without an enforcement outcome.

How enforcement plays out

Italian Garante vs. OpenAI (March 2023) 

In March 2023, Italy’s data protection authority (Garante) temporarily blocked ChatGPT in Italy. Among the issues identified: lack of a clear lawful basis for collecting and processing personal data for training, insufficient transparency about data collection purposes, and inadequate mechanisms for users to exercise their rights — including rectification and objection. While not limited to Article 22, the case highlighted broader failures in rights infrastructure relevant to automated processing. OpenAI restored access only after committing to specific disclosure and rights-management changes.

Engineering lesson: The rights infrastructure — opt-out mechanisms, explanation tooling, and contestation paths — must exist and function before deployment. Regulators do not wait for a complaint to confirm they are missing.

Berlin Commissioner for Data Protection — €300,000 fine (May 2023)

In May 2023, the Berlin Commissioner for Data Protection and Freedom of Information issued a €300,000 fine against a bank for automatically rejecting a credit card application without adequate transparency — citing violations of Article 22(3), among other provisions. The case demonstrated that Article 22(3) obligations are independently enforceable: a valid exemption basis under Article 22(2) does not close Article 22 exposure — it opens a specific set of safeguard obligations that must be documented and functional, not stated in a privacy notice.

Engineering lesson: Claiming a valid exemption under Article 22(2) without implementing the Article 22(3) safeguards is an independently enforceable violation. The exemption and the obligations are inseparable.

SCHUFA Holding (Case C-634/21, CJEU, 7 December 2023)

As covered above, the CJEU’s ruling in SCHUFA Holding is the most significant Article 22 precedent to date. The court confirmed that automated credit scoring can constitute solely automated decision-making under Article 22(1) even where a human formally makes the final credit decision — provided that decision is predominantly determined by the automated score. This ruling directly affects any AI system whose output is used as a primary input to a downstream decision made by a third party, whether a business partner, a financial institution, or an internal team with no access to the model’s feature breakdown.

Engineering lesson: Formal human sign-off carries no weight under the CJEU’s test if the human cannot practically deviate from the model’s output — because of interface design, time pressure, or missing evidence. 

CNIL AI compliance guidance (France, 2023–2024)

France’s CNIL published guidance in 2023–2024 addressing automated processing GDPR requirements, including recommendations on: 

• Ensuring purpose limitation and data minimization in model training and deployment
• Implementing effective human oversight, including clear documentation of reviewer roles and capabilities
• Providing meaningful information about automated decisions in line with GDPR transparency requirements
• Conducting DPIAs for high-risk processing involving automated decision-making

CNIL also emphasizes the need to assess risks to individuals, particularly in systems affecting employment, credit, or access to services.

Engineering lesson: Purpose limitation at the model level means documenting not only what the model does, but what it is authorized to decide, in what context, and to what standard. Using a general-purpose model without that documentation is a gap regulators are beginning to examine specifically.

Is your AI system already subject to Article 22?

If your AI system makes decisions about individuals — in credit, hiring, insurance, healthcare, or compliance — automated decision-making obligations under GDPR apply from the moment you process personal data. Corpsoft Solutions maps your decision flows against Article 22 conditions, identifies gaps in your logging, opt-out, and rights infrastructure, and helps your engineering team build systems that hold up under regulatory scrutiny.

For teams scoping a broader compliance framework — beyond Article 22 alone — GDPR-Compliant Software: Regulation Requirements and How to Ensure Them covers the full process, from initial DPIA to audit-ready documentation.

Share this post: