GDPR Article 22 Automated Decision-Making: What LLM-Driven Workflows Owe Data Subjects

TL;DR

• LLM workflows must not make solely automated decisions with legal or similarly significant effects unless an Article 22 exception applies.
• A review avoids solely automated status only when a competent person can change the outcome, sees all relevant data, and evaluates the decision itself rather than checking that the process ran.
• Probability scores can count as Article 22 decisions when another party relies on them, so responsibility may reach the score producer.
• Controllers must explain the procedure and principles applied to a person’s data, not merely disclose the algorithm or final result.

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 a Article 22 decision. The August 2026 EU AI Act enforcement window sits on top of this regime, not in place of it.

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.

What Article 22 actually says

Article 22(1) grants the right. Article 22(2) lists three exceptions: contractual necessity, Union or Member State law that authorizes the decision, and explicit consent of the data subject. Article 22(3) requires that where exceptions apply, the controller still has to implement suitable measures to safeguard the data subject's rights, including at minimum the right to obtain human intervention, to express a point of view, and to contest the decision. Article 22(4) prohibits Article 22 decisions based on the special categories of personal data under Article 9, except in narrow circumstances.

Recital 71 elaborates. It identifies decisions on credit applications, e-recruitment practices without human intervention, and pricing decisions as examples. It directs controllers to use appropriate mathematical and statistical procedures, to ensure factors that could result in inaccuracies in personal data are corrected, and to minimize the risk of errors. It explicitly references the right to 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 exactly three safeguards: human intervention, a point of view, and contestation. The paragraph requires the controller to implement suitable measures safeguarding "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," and that list is exhaustive. The explanation right people go looking for lives elsewhere, which is why the question keeps getting asked.

The explanation obligation is real and sits in four other places:

• Recital 71 grants "to obtain an explanation of the decision reached after such assessment." It is interpretive: recitals guide the reading of the articles without creating standalone obligations.
• Article 13(2)(f), binding, requires meaningful information about the logic involved, plus significance and envisaged consequences, at collection from the data subject.
• Article 14(2)(g), binding, requires the same information where the data came from elsewhere.
• Article 15(1)(h), binding, makes the same information available on request, at any time, 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. Three holdings matter for anyone running an LLM workflow:

• "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 satisfies nothing, and neither does a detailed description of every step in the process. The standard is concise and intelligible to the data subject.
• A trade secret permits no blanket refusal. The controller discloses the protected material to the competent supervisory authority or court, which then balances the interests.

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 review has to be more than a check that the process ran. A workflow where the human's role is to verify that the model produced an output is not human review. The human has to evaluate the decision substance.

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.

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. The data subject's identifier, the natural-person reviewer's identity (when human review is part of the workflow), the controller's organizational identity, and any sub-processor or agent identities involved. The natural-person fields are the ones standard application logging routinely misses.

Decision-substance fields. The input data classification, the model called, the prompt or input that triggered the model, the model's output, and the final decision communicated to the data subject. The chain from input to output to decision has to be reconstructable from the records.

Policy-state fields. The policy version in effect at the moment of decision, the routing rule that selected the model, the human-review checkpoint result if one applied, and any override decisions. The policy state is what shows the regulator that the decision was governed.

Temporal fields. The timestamp of the model call, the timestamp of the human review (if any), and the timestamp of the decision communication to the data subject. The temporal sequence matters because a human review that postdates the decision communication is not 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, written outside the application so the application cannot alter or omit it. The natural-person identity of the data subject and the identity of the human reviewer appear in the record when the application propagates them in the request context; that propagation is application work, and a workflow that omits it gets records at the application's own granularity.

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 record is the evidence layer. The Article 22(3) safeguards themselves, human intervention, a voiced point of view, contestation, are workflows the controller operates; the record proves they ran, and the same fields serve the EU AI Act's Article 12 logging obligations.

If you are running AI workflows that may produce legal effects or similarly significant effects on EU data subjects, the audit record is where the exposure shows first. Book a demo today.