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

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.

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. A reviewer who is told to approve the model's output unless a specific override condition fires is not exercising authority. A reviewer who reads the model's output and rubber-stamps it without independent evaluation is not exercising competence. A reviewer who has neither the time nor the information to engage with the substance of the decision is not exercising either.

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 22(3) right to obtain an explanation of the decision reached, the controller has to produce a meaningful explanation. 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 the explanation after the fact.

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.

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.

If you are running AI workflows that may produce legal effects or similarly significant effects on EU data subjects, book a demo today.