Large language models now sit inside credit pipelines, hiring filters, insurance underwriting flows, medical triage tools and parole risk engines. The legal exposure that follows is not theoretical. GDPR Article 22 has existed since 2018 but was drafted in a world of rule-based decisioning trees, not probabilistic token prediction. The question practitioners must answer in 2026 is precise: does an LLM output that shapes a consequential outcome trigger Article 22, and if so, what does compliant architecture actually look like?
This analysis examines the statutory text, regulatory guidance from the European Data Protection Board (EDPB) and the UK Information Commissioner's Office (ICO), and the structural constraints that LLM architectures impose on compliance strategies. It also maps how the EU AI Act's high-risk classification interacts with, but does not replace, Article 22 obligations.
What Article 22 Actually Prohibits
Article 22(1) of the GDPR gives data subjects 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. Three elements must be present simultaneously: sole automation, profiling or automated processing, and a legal or similarly significant effect.
The EDPB's Guidelines 03/2022 on dark patterns and the earlier Guidelines on Automated Individual Decision-Making (05/2017) clarify that 'legal effects' include voting rights, contractual formation, tax liability and freedom of movement. 'Similarly significant effects' cover outcomes that substantially affect circumstances, behavior or choices, including denial of credit, rejection of employment applications and differential pricing of insurance products.
The right under Article 22(1) is not an opt-in right that data subjects must invoke. The EDPB's position, restated clearly in 2022, is that Article 22(1) operates as a general prohibition. Controllers must have a lawful basis under Article 22(2) before deploying a qualifying automated decision system, not after a subject complains.
That framing matters enormously for LLM deployments. A system cannot be built first and made compliant on request. The prohibition is structural.
The 'Solely Automated' Threshold and Where LLMs Land
The word 'solely' is doing significant legal work in Article 22. If a human meaningfully participates in reaching the decision, the prohibition does not apply. Controllers have leaned heavily on this word to argue that any human in the chain breaks the chain of automation. That argument is weaker than it looks when applied to LLM outputs.
Consider a hiring workflow where an LLM scores and ranks 2,000 CVs, surfacing the top 40 for human review. A recruiter then schedules interviews. The controller argues a human made the hiring decision. The EDPB's Guidelines 05/2017 anticipated exactly this structure. Human involvement must be more than a token gesture. A reviewer who lacks the data, the time or the genuine authority to override the automated output does not break the automation chain for Article 22 purposes.
LLMs intensify this problem in a specific way that prior decision systems did not. A logistic regression score is at least numerically interpretable by a trained analyst. An LLM recommendation derived from billions of parameters is not. When a human reviewer cannot interrogate the basis of a recommendation, the EDPB's 'meaningful human review' standard is structurally unachievable, not merely inconvenient.
The ICO's guidance on AI and data protection, updated in its 2023 framework and still operative in 2026, frames it similarly: the human must have authority and capability to reach a different conclusion based on the data available. Capability is the operative word. A model that is correct 94% of the time creates social and organizational pressure that makes genuine override behavior rare regardless of formal policy.
The Human-in-the-Loop Escape Hatch and Its Technical Limits
Controllers seeking to rely on human review as an Article 22 safeguard face a set of engineering constraints that must be addressed at the system design level, not the compliance policy level.
First, explainability requirements. Article 22(3) mandates that when automated decisions are permitted under Article 22(2), controllers must implement 'suitable measures to safeguard the data subject's rights and freedoms and legitimate interests, 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.' That right to contest is meaningless if neither the subject nor the reviewing human can understand why the LLM produced its output.
NIST's AI Risk Management Framework (AI RMF 1.0) defines 'explainability' and 'interpretability' as distinct properties, where interpretability concerns the degree to which a human can understand the mechanism of a model. For current decoder-only transformer architectures running at scale, interpretability at the individual-prediction level remains an active research problem, not a solved engineering problem. Mechanistic interpretability work from groups including Anthropic's research team (published on arXiv under identifiers such as 2209.11895 and subsequent papers) shows partial progress on circuit-level attribution, but production deployment at the fidelity Article 22 requires is not yet standardized.
Second, audit trail requirements. For automated decisions that are permitted, Article 22 read alongside Article 5(2) (accountability) and Article 25 (data protection by design) demands that controllers demonstrate the human review actually happened and was substantive. A logging architecture that records only the final decision and not the reviewer's engagement with underlying data is insufficient for demonstrating meaningful review.
Third, the override rate problem. If internal audit data shows that human reviewers override LLM recommendations at a rate below, say, 2%, a supervisory authority examining that log has reasonable grounds to conclude that the 'human in the loop' is nominal. Controllers should track override rates not just as a compliance metric but as a canary for whether the process remains genuinely human-directed.
Legal Bases That Permit Automated Decisions
Article 22(2) carves out three pathways through which solely automated decisions producing significant effects are lawful: the decision is necessary for the performance of a contract between the data subject and the controller. The decision is authorized by EU or member state law with appropriate safeguards. Or the decision is based on the data subject's explicit consent.
Contractual necessity under Article 22(2)(a) is narrower than it sounds. 'Necessary' means the automated decision must be objectively required to perform the contract, not merely convenient or efficient. An LLM-driven credit scoring model applied to a loan application may meet this test if alternative non-automated underwriting would make the product commercially undeliverable, though that argument invites scrutiny. Using an LLM to personalize marketing communications almost certainly does not meet the necessity threshold.
Explicit consent under Article 22(2)(c) is the most flexible basis but the hardest to execute correctly. Consent must be specific to the automated decision-making activity, freely given, informed and unambiguous under Article 4(11). Where a power imbalance exists between controller and data subject, such as employer and employee, free consent is structurally doubtful. The EDPB has repeatedly flagged employment contexts as high-risk for consent validity under both Articles 6 and 22.
Member state law under Article 22(2)(b) has produced uneven implementation across the EU. France, Germany and the Netherlands have each enacted specific provisions. Controllers operating across multiple member states cannot assume uniform legal coverage and must map the applicable national provisions for each deployment geography.
How the EU AI Act Overlays Article 22
The EU AI Act, which entered into force in 2024 and whose high-risk provisions apply fully in 2026, creates a parallel compliance obligation that intersects with but does not subsume Article 22. Understanding the relationship between the two frameworks is critical for any engineering team building consequential AI systems in the EU market.
Annex III of the EU AI Act designates several categories of AI systems as high-risk, including AI used in employment and worker management, credit scoring, essential public services, and law enforcement. These categories map almost exactly onto the domains where Article 22 is triggered. A single LLM deployment in, for example, automated CV screening faces both Article 22's prohibition-by-default structure and the AI Act's conformity assessment, technical documentation, human oversight and transparency requirements.
The AI Act's human oversight requirement under Article 14 requires that high-risk AI systems be designed to allow natural persons to understand the system's capacities and limitations, monitor operation and intervene or override. This requirement is not identical to Article 22's 'meaningful human review' standard but substantially reinforces it. A human oversight architecture built to satisfy AI Act Article 14 will likely, though not automatically, satisfy the Article 22 safeguard for human involvement.
Where the frameworks diverge is in their remedial logic. GDPR Article 22 operates as a rights-based prohibition with data subject remedies, including the right to erasure, restriction and compensation under Article 82. The AI Act operates primarily as a product safety and market access regime, with conformity assessments, notified bodies and provider obligations. A data subject harmed by an automated decision has Article 82 GDPR remedies available. They do not have a direct private right of action under the AI Act as currently structured.
Controllers should not treat AI Act compliance as a substitute for GDPR Article 22 compliance. They are additive obligations. The EDPB and the European AI Office have both signaled that joint enforcement actions examining both frameworks simultaneously are an active operational priority in 2026.
Engineering for Compliance: Practical Architecture Choices
Given the legal landscape, what does a defensible LLM deployment architecture actually look like for consequential decisions?
Start with decision classification. Not every LLM output is a decision under Article 22. An LLM that drafts a letter for a human to edit is not producing a decision. An LLM that generates a risk score that determines credit eligibility without further substantive review is producing a decision. Mapping outputs to Article 22 trigger criteria before system design begins is a prerequisite, not an afterthought.
For triggered decisions, build explainability infrastructure from the ground up. Techniques including LIME (Local Interpretable Model-agnostic Explanations), SHAP (SHapley Additive exPlanations) and attention-based attribution can produce partial explanations for transformer outputs, but controllers should document the limitations of these explanations honestly in their Article 25 data protection by design records. An explanation that cannot be understood by the reviewing human is not an explanation that satisfies the Article 22(3) contestation right.
Log reviewer engagement. A compliant audit trail records not just the LLM output and the final decision, but evidence that the reviewing human accessed and considered the underlying data. Timestamp sequences, data access logs and explicit override rationale fields are the minimum viable evidentiary record.
Calibrate workload to enable genuine review. If a reviewer is processing 200 LLM-recommended decisions per hour, the override rate data will tell the story. System design must allocate sufficient time per review to make override behaviorally plausible, not just formally permissible.
Conduct and document Data Protection Impact Assessments (DPIAs) under Article 35. Automated decision-making using new technologies with significant effects is a mandatory DPIA trigger. The DPIA for an LLM-based decision system should address the specific explainability limitations of the model, not just generic automated profiling risks.
Open Questions That Remain Unsettled in 2026
Several legal and technical questions remain genuinely unresolved as of 2026, and practitioners should not assume settled answers exist.
First, does retrieval-augmented generation change the 'solely automated' analysis? An LLM that retrieves and cites source documents might be argued to incorporate human-authored content in a way that disrupts pure automation. No supervisory authority has issued guidance on this specific architecture. The safer assumption is that citation does not equal human participation.
Second, what is the Article 22 status of decisions made by AI agents operating across multi-step tool-use pipelines? When an LLM orchestrates a sequence of tool calls, database queries and conditional logic that culminates in a consequential action, the automation chain may be longer and less visible than a single model call. The EDPB's forthcoming guidelines on agentic AI systems, anticipated in 2026, will address this but have not yet been finalized.
Third, how does Article 22 interact with LLMs used in public sector decisioning, where Article 22(2)(b) applies? Member state implementation has been inconsistent and several national supervisory authorities have reached different conclusions on what counts as adequate safeguards under the national law exemption.
These open questions are the reason data protection counsel and privacy engineers need to work together at the architecture stage, not the post-deployment audit stage. The Personal Data Asset Origination System (PDAOS) framework explored at MyDataKey.org offers one structural approach to encoding consent and decision-trail provenance at the data layer, which addresses some of these audit infrastructure challenges regardless of how the legal questions resolve.
The core principle in Dr. Patrick Fisher's work published through The Invisible Series holds here: data subjects cannot exercise rights they cannot see, and controllers cannot demonstrate accountability they have not architected. Article 22 compliance in the LLM era is an engineering problem that requires legal precision, not a legal problem that can be solved with a policy document.