GDPR Article 22 Automated Decisions: AI Workflows

Article 22 of the GDPR gives data subjects the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significant effects. AI and LLM-driven workflows that screen job candidates, approve or deny credit, set insurance prices, or trigger fraud or compliance holds fall inside the article when no meaningful human review breaks the chain between the model's output and the decision communicated to the data subject. The Court of Justice of the European Union's December 2023 *SCHUFA* judgment (C-634/21) confirmed that even producing a probability score that another party then relies on can itself be an Article 22 decision. The European Union's AI Act adds system-level obligations for relevant high-risk AI systems; it operates alongside the GDPR rather than replacing this individual-decision analysis.

The Article 22 text is short. The Working Party 29 guidance and the SCHUFA judgment are where the operational content lives. The audit-evidence question for any LLM-driven workflow is whether the record proves a human meaningfully reviewed the decision, or whether the model's output went straight through to the data subject without break.

I want to walk through the Article 22 text, the meaningful-human-review test, and the audit-record content that survives a Data Protection Authority review.

TL;DR

Article 22 applies when automated processing produces legal or similarly significant effects without meaningful human review. Retain the input, model output, reviewer authority and action, governing policy state, and communication timing so one decision can be reconstructed for the data subject or regulator.

What Article 22 actually says

Paragraph 1 grants the right, while paragraph 2 lists three exceptions: contractual necessity, Union or Member State law that authorizes the decision, and explicit consent of the data subject. Where an exception applies, paragraph 3 still requires suitable measures that safeguard the data subject's rights, including human intervention, a chance to express a point of view, and a way to contest the decision. Paragraph 4 restricts automated decisions based on Article 9 special-category data to narrow circumstances.

Recital 71 supplies the examples and interpretive detail. Credit applications, e-recruitment without human intervention, and pricing decisions appear in its list. Controllers are directed to use appropriate mathematical and statistical procedures, correct factors that could result in inaccurate personal data, and minimize the risk of errors. The recital also refers to an explanation of the decision reached.

The SCHUFA judgment expanded the article's reach. The Court held that an automated probability score, even when generated by a credit-reference agency rather than the lender, can itself constitute an Article 22 decision if the lender draws strongly on it. The producer of the score, not just the final decision-maker, bears Article 22 responsibility.

Article 22(3) and the right to explanation

Article 22(3) names three safeguards, while an explanation right appears elsewhere in the GDPR. The paragraph requires the controller to provide human intervention, an opportunity for the person to express a point of view, and a route to contest the decision. That exhaustive list is why searching the paragraph for an explanation right returns nothing.

The explanation obligation is real. It sits in four other places:

• Recital 71: it refers to obtaining an explanation of the decision reached after an assessment. The recital guides the reading of the articles without creating a standalone obligation.
• Article 13(2)(f): it requires meaningful information about the logic involved, plus the processing's significance and envisaged consequences, when the controller collects data from the subject.
• Article 14(2)(g): it requires the same information when the controller obtained the data elsewhere.
• Article 15(1)(h): it requires the same information on request through a subject-access request.

Article 15(1)(h) is the one that gets exercised in practice, because it applies after the decision rather than before it. A data subject who has been refused credit asks for the logic under Article 15(1)(h), then uses Article 22(3) to contest the outcome. Two provisions, two moments, one dispute.

The Court of Justice settled the content of that obligation on 27 February 2025 in CK v Dun & Bradstreet Austria (C-203/22), a case that began when an Austrian applicant was refused a mobile phone contract on the strength of an automated creditworthiness assessment. "Meaningful information about the logic involved" means an explanation of the procedure and principles actually applied to that person's data to reach that specific result. Handing over the algorithm, or a detailed description of every process step, fails that standard. The explanation must be concise and intelligible to the data subject. A trade secret permits no blanket refusal because the controller must disclose the protected material to the competent supervisory authority or court for a balancing exercise.

The operational consequence lands on the audit record. Reconstructing the procedure and principles applied to one person's data at one moment requires the input data, the policy version, the model called, the prompt, and the output, held together and retained for as long as the access right survives. A record that captures the outcome alone leaves the controller explaining, to a supervisory authority, why it cannot explain.

The meaningful-human-review test

The Working Party 29 guidance (now ratified by the EDPB) set out the test for whether human review is meaningful enough to remove a workflow from "solely automated" status. Three elements have to be present.

The reviewer has to have authority and competence to change the decision. Authority fails where the reviewer is instructed to approve the model's output unless a specific override condition fires, because the discretion has already been spent by whoever wrote the instruction. Competence fails where the output gets a rubber stamp without independent evaluation. Both fail together in the common case, where the reviewer has neither the time nor the information to engage with the substance of what they are approving.

The reviewer has to consider all relevant data. The reviewer has access to the input data, the model's output, the rationale or signals behind the output, and any additional context the data subject has provided. A reviewer who sees only the model's binary decision lacks the inputs needed for meaningful review.

The reviewer has to assess the decision substance rather than confirm that the process ran. A workflow that limits the human role to verifying that the model produced an output has not created human review.

Most enterprise AI workflows fail this test at production scale. Once review volume passes a certain throughput, the human-in-the-loop role degrades into a rubber stamp. The DPA's question on inspection is whether the records show meaningful review or whether they show throughput.

A three-step Article 22 test for an AI workflow

Begin by identifying the consequence for the person. A workflow belongs in the Article 22 assessment when its output determines, or materially shapes, a legal effect or a similarly significant effect for an identifiable person. Employment screening, credit approval, insurance pricing, and account holds are familiar examples because each can change that person's access to a service or opportunity.

Next, trace the decision path by capturing the model output, the person with authority to alter it, the evidence available to that reviewer, the time spent on review, and the communication sent to the data subject. A named reviewer who receives only a binary recommendation after the decision has been sent provides weak evidence of meaningful intervention.

Finally, document the Article 22(2) basis where the workflow relies on contractual necessity, a Union or Member State law authorization, or explicit consent. The safeguards in Article 22(3) still require a route for human intervention, the data subject's point of view, and a challenge to the decision. The three records belong together in the case file.

Four Article 22 examples that need different evidence

Credit scoring, employment screening, insurance pricing, and fraud holds can each produce legal or similarly significant effects. The decisive question is the same in all four: did an authorized person evaluate the individual case before the outcome reached the data subject?

For a credit score, retain the score inputs, the lender's reliance rule, reviewer identity, any override, and the communication timestamp. A recruitment workflow needs the candidate data used, model output, the hiring review, and the reason for any decision that moved the candidate out of consideration. Insurance evidence should connect the price or coverage decision to the applicable rule and review. A fraud hold needs a record of the triggering signals, review authority, release or escalation action, and customer communication. The Article 29 Working Party's automated-decision guidance remains the operational reference for this assessment.

Where current AI architectures fall short

The standard pattern in production has three failures against Article 22.

The first failure is the natural-person identity gap. The application calls the LLM with a static service credential. The audit log records the application's identity, not the human reviewer's identity. When the DPA asks "who reviewed this decision," the records cannot answer because the reviewer's identity was never propagated into the decision chain.

The second failure is the policy state gap. The audit log records that a request was made and a response returned. The policy version, the routing rule, the classification applied, and the model parameters at the moment of decision are not recorded. When the DPA asks "what policy state governed this decision," the records cannot answer.

The third failure is the rationale gap. LLM outputs are not always accompanied by structured explanations. When the data subject exercises the Article 15(1)(h) right to meaningful information about the logic involved, the controller has to produce the procedure and principles actually applied to that person's data, at the standard Dun & Bradstreet set. A workflow that records only the model's final output and not the prompt, the input data, or the policy that governed the call cannot reconstruct that after the fact. The gap is structural: the audit record has to be written outside the application that produced the decision, or the same system that made the call is the one attesting to how it was made.

The audit-record content that satisfies Article 22

The audit record at the AI request layer has to include four classes of field for Article 22 evidence.

Identity fields record the data subject's identifier, the natural-person reviewer when human review is part of the workflow, the controller's organizational identity, and any sub-processor or agent identities. Standard application logging routinely misses the natural-person fields.

Decision-substance fields record input-data classification, the selected model, the prompt or triggering input, its output, and the final decision communicated to the data subject. The records need to reconstruct the chain from input through outcome.

Policy-state fields retain the policy version in effect, the routing rule, the human-review checkpoint result where one applied, and any override decision. That state shows the regulator how the decision was governed.

Temporal fields retain when the model call occurred, when any human review occurred, and when the decision reached the data subject. The order matters because a review after the decision communication cannot function as human review.

Article 22 and the EU AI Act intersection

The EU AI Act's Article 26 obligations on deployers and the EU AI Act's Article 14 obligations on providers of high-risk AI systems extend Article 22 by codifying human oversight requirements at the system level. An AI system used in employment screening, credit decisioning, or insurance pricing falls under EU AI Act Annex III as a high-risk use case and inherits the Article 14 human-oversight obligations.

The two regimes' audit-evidence requirements converge. EU AI Act Article 12 requires automatic logging of system operation. GDPR Article 22 requires evidence of meaningful human review where the exceptions apply. The same per-decision audit record at the AI request layer satisfies both, when its content fields include the natural-person reviewer identity, the policy state, the classification, and the decision substance. The Article 12 logging implementation walks through the field-level build, and the screening assessment that precedes it is covered in the DPIA guide.

DeepInspect

DeepInspect intercepts the HTTP traffic between authenticated users or agents and any LLM endpoint. The interception point is where the identity, classification, policy state, and outcome are captured in a per-decision audit record. The record is written outside the application, so the application cannot alter or omit it. The natural-person identity of the data subject (where present in the request context) and the natural-person identity of the human reviewer (where the workflow includes one) are propagated into the record by design.

For Article 22 evidence, this means the records can answer the questions a Data Protection Authority asks: who reviewed this decision, what data did the model see, what policy version was in effect, and what was the outcome. The records satisfy the EU AI Act's Article 12 obligations and the GDPR's Article 22(3) safeguards at the same time.

Book a demo today.