Large language models are making consequential decisions about people at scale. They are screening job applications, triaging medical referrals, scoring loan eligibility and flagging insurance claims for denial. In 2026, the legal question is no longer whether GDPR Article 22 applies to LLM-driven pipelines. The question is how it applies and whether the engineering and governance structures companies have built can survive that scrutiny. The answer, in most organizations, is no.
This article provides a technical and legal analysis of GDPR Article 22 as applied to LLM-based decision systems. It examines what the regulation actually requires, where common implementation patterns fail, how the EU AI Act creates layered obligations on top of GDPR and what compliance-grade architectures look like in practice.
What Article 22 Actually Says
Article 22 of the General Data Protection Regulation gives data subjects the right not to be subject to a decision based solely on automated processing that produces legal effects or significantly affects them. The provision is not optional. It is a default prohibition with a narrow set of exceptions.
The three lawful bases that permit automated decision-making are: the decision is necessary for a contract between the controller and the data subject. The decision is authorized by EU or member state law that includes suitable safeguards. Or the data subject has given explicit consent. In all three cases, Article 22(3) requires controllers 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.
Special category data under Article 9 introduces a harder constraint. Automated decisions based solely on processing of special category data are prohibited unless the data subject has given explicit consent or the processing is necessary for reasons of substantial public interest. Most organizations building LLM pipelines that touch health information, inferred demographic data or behavioral proxies are operating in Article 9 territory whether they acknowledge it or not.
The European Data Protection Board's Guidelines 06/2022 on chatbots, and earlier Guidelines 2/2022 on data subjects' rights related to automated decision-making, remain the primary supervisory interpretive documents. The ICO's guidance on AI and data protection also provides practical framing aligned with EDPB positions.
What Counts as Solely Automated in an LLM Pipeline
The word "solely" in Article 22 is load-bearing. Controllers frequently argue that any human touchpoint in a workflow removes the solely automated character of a decision. Supervisory authorities and courts have consistently rejected that argument when the human involvement is nominal.
The EDPB has stated clearly in its guidelines that "human review" must be meaningful. A human who rubber-stamps an LLM output, who lacks the authority to override the system, or who reviews without access to the underlying logic is not providing the kind of intervention Article 22(3) envisions. The test is functional, not formal.
In an LLM pipeline, this creates specific technical problems.
A retrieval-augmented generation system that retrieves a candidate profile, passes it to a frontier model and outputs a hire or reject recommendation can be "solely automated" even if a recruiter clicks an approve button. If the recruiter sees only the model output and not the reasoning, if the recruiter processes hundreds of outputs per hour such that genuine review is structurally impossible, or if the recruiter has no documented authority to reject the model's recommendation, the pipeline is functionally automated.
Embedding-based similarity scoring for credit underwriting presents the same problem. The vector distance between an applicant's behavioral embedding and a "creditworthy" cluster is not human-readable. A loan officer reviewing a score derived from that distance is reviewing an opaque artifact of automated processing. That is not meaningful human review.
The "significant effect" threshold also deserves technical attention. Article 22 covers not only decisions with legal effects like contract formation or denial of a public benefit but also decisions that significantly affect a person in a comparable way. The EDPB has interpreted this to include decisions that affect access to services, employment opportunities or financial products. An LLM that personalizes what job listings a person sees, what credit offers are surfaced or what health information is returned in a search is arguably making decisions that significantly affect them, even if no single decision looks like a formal determination.
The Human-in-the-Loop Escape Hatch and Its Failure Modes
The human-in-the-loop design pattern is the most commonly deployed compliance strategy for Article 22. It is also the most commonly abused one.
Genuine human-in-the-loop architecture requires three things: the human reviewer has access to the source data and the model's reasoning, not just its output. The human reviewer has the authority and the practical capacity to override. And the override rate is monitored and is non-trivially above zero. If override rates approach zero across a large sample, that is evidence that the human is not actually reviewing.
Controller organizations often treat HITL as a checkbox rather than an architectural requirement. An LLM ranks 500 loan applications overnight. In the morning, a credit analyst reviews a dashboard showing green, yellow and red flags and approves or rejects batches. The analyst has 90 seconds per application. The LLM's feature attribution is not surfaced. This is not Article 22-compliant human intervention. It is automation with cosmetic human involvement.
The technical specification for meaningful intervention includes explainability tooling that is not post-hoc rationalization. SHAP values, attention attribution or structured chain-of-thought outputs can be part of a compliant design if they are surfaced to the reviewer in interpretable form at decision time. Post-hoc explainability tools that generate plausible-sounding reasons after the fact do not satisfy the requirement because they do not reveal what the model actually computed.
For LLMs specifically, the black-box character of autoregressive generation makes this especially difficult. A 70-billion parameter instruction-tuned model producing a creditworthiness narrative has no stable, auditable feature set. Its output is a function of training data, prompt structure and sampling parameters that are not legible to a human reviewer without substantial interpretability infrastructure. Controllers deploying these systems without that infrastructure are not building defensible HITL workflows.
LLM-Specific Technical Challenges for Article 22 Compliance
Several properties of large language models create compliance challenges that earlier automated decision-making frameworks did not anticipate.
First, LLMs are statistical correlators trained on internet-scale data. They will encode proxy discrimination. A model trained on historical hiring data that correlates writing style, vocabulary or name patterns with outcomes will embed those correlations into its scoring behavior. The model does not know it is discriminating. The controller cannot audit the mechanism by inspecting weights. This intersects with Article 22(3)'s requirement to safeguard the data subject's rights and with Article 9's prohibition on decisions based on special category data: the model may be making inferences about protected characteristics from non-protected inputs.
Second, LLMs are prompt-sensitive in ways that create inconsistency. Two identically situated applicants whose profiles are formatted differently may receive different recommendations from the same model. Inconsistency is not just a fairness problem. It is an Article 22 problem because the data subject has a right to contest a decision and to receive meaningful information about the logic involved. A system where the outcome depends on prompt formatting in ways that cannot be explained is not a system where that right can be meaningfully exercised.
Third, RAG pipelines introduce a data provenance problem. When a model retrieves context from a knowledge base to inform a decision about a data subject, the controller may be processing personal data from sources the data subject did not consent to and cannot identify. Article 13 and 14 transparency obligations interact here with Article 22 because the data subject's right to meaningful information about automated processing extends to the data sources that informed the decision.
Fourth, LLMs deployed via API create a responsibility allocation problem. If a controller uses a third-party model provider to make decisions about data subjects, the controller cannot audit the model's training data, cannot access its weights and cannot verify that the model has not been updated between decisions. Article 28 processor contracts do not resolve this problem because the model provider is not processing personal data in the same way a traditional data processor does. The EDPB has not yet issued definitive guidance on LLM-as-processor arrangements as of 2026. Controllers are operating in interpretive uncertainty.
How the EU AI Act Overlays Article 22 Obligations
The EU AI Act, fully applicable in 2026, creates obligations that run parallel to and deeper than GDPR Article 22 for high-risk AI systems.
Annex III of the AI Act designates several application areas as high-risk by default: AI used in employment decisions including recruitment and performance evaluation, AI used in credit scoring and access to financial services, AI used in education and vocational training and AI used in essential private and public services. An LLM deployed in any of these contexts is presumptively a high-risk AI system subject to the full requirements of Chapter 3 of the AI Act.
Those requirements include a conformity assessment prior to deployment, a risk management system maintained throughout the system lifecycle, technical documentation covering training data governance and performance evaluation, human oversight measures that are substantially more specific than GDPR's general requirement, and registration in the EU database for high-risk AI systems.
The human oversight requirement in Article 14 of the AI Act is worth reading against Article 22(3) GDPR. The AI Act requires that high-risk AI systems be designed to allow natural persons to effectively oversee the system, to interpret and understand its outputs and to override or intervene in its operation. This is the same functional standard that EDPB Guidelines apply to Article 22 human intervention. The two frameworks converge on meaningful oversight, not nominal oversight.
The AI Act also imposes transparency obligations on providers of general-purpose AI models that go to the question of data subject rights. Article 53 requires providers to make available technical documentation sufficient for downstream deployers to understand and comply with their obligations. That documentation must include information about training data, capabilities and limitations. A controller using an LLM from a provider that has not published Article 53-compliant documentation is in a structurally non-compliant position under both the AI Act and GDPR Article 22.
The intersection of the two frameworks also affects supervisory enforcement. Data protection authorities are coordinating with market surveillance authorities on AI Act compliance. A GDPR Article 22 investigation of an LLM-based decision system is now likely to involve parallel AI Act review. Controllers cannot treat these as separate compliance tracks.
Architectural Paths Toward Compliance
Compliance is achievable but requires architectural commitment, not policy documentation alone.
A decision record architecture is the foundation. Every automated decision affecting a data subject must generate a timestamped, immutable record that captures the input data used, the model version and configuration, the output and any confidence scores, the identity of the human reviewer if one was involved and the final decision and its basis. This record satisfies both the data subject's right to obtain meaningful information under Article 22(3) and the audit trail requirements of the AI Act.
Structured chain-of-thought outputs can make LLM reasoning legible to human reviewers without exposing the full complexity of the model's internal computation. If a model is asked to assess a loan application, prompting it to enumerate the factors it is considering and the direction and weight of each factor creates a human-readable reasoning trace. This is not a substitute for interpretability but it is an operationally useful proxy that improves the quality of human review.
Consent receipt architectures, as specified in the Kantara Initiative Consent Receipt Specification v1.1, can document the lawful basis for automated processing and bind it to the specific decision context. When the lawful basis is consent under Article 22(2)(c), the consent receipt creates an auditable record of what the data subject agreed to that can be presented if the decision is contested.
Fairness evaluation pipelines that run continuously in production, not only at development time, are a technical requirement for Article 22 compliance in high-stakes domains. Demographic parity, equalized odds and calibration metrics should be monitored as operational telemetry and divergence from baseline should trigger human review of the pipeline before additional decisions are made.
What Engineers and Policy Teams Must Do Now
The compliance gap between what most organizations have built and what Article 22 requires in the LLM context is substantial. Closing it requires joint action from engineering and policy functions.
Engineering teams need to instrument decision pipelines for full auditability from day one. Retrofitting audit infrastructure to an already-deployed LLM pipeline is expensive and often incomplete. The decision record architecture described above should be a deployment prerequisite, not an afterthought.
Policy and legal teams need to re-evaluate HITL workflows against the functional standard the EDPB has articulated. Reviewing the nominal structure of a workflow is not enough. The review must assess whether the human reviewers in the workflow have the information, authority and time to provide the kind of intervention Article 22 requires. That assessment should be documented and updated when the pipeline changes.
Data Protection Impact Assessments for LLM-based decision systems must address the specific risks outlined in this article: proxy discrimination, prompt sensitivity, RAG data provenance and model provider opacity. A generic DPIA template that was designed for rule-based automated decision systems does not capture these risks.
Organizations should also be actively tracking EDPB guidance on LLMs and AI Act guidance from the European AI Office, which has been issuing interpretive documents on general-purpose AI model obligations throughout 2026. The regulatory environment is evolving and compliance positions that were defensible last year may not be defensible today.
The stakes are high. GDPR fines under Article 83(4) for violations of Article 22 as a data subject rights provision can reach 20 million euros or four percent of global annual turnover. The AI Act's penalty regime runs in parallel. For large technology organizations operating at scale, the exposure from non-compliant LLM decision pipelines is not a theoretical risk. It is a quantifiable liability.
The work of building data-sovereign, rights-respecting AI systems is the work Own Your Data Inc exists to advance. The technical and policy frameworks exist. The question is whether organizations will build to them before enforcement makes the choice for them.