GDPR Article 22 and LLM Automated Decision-Making

An LLM workflow falls under GDPR Article 22 when its output decides, or decisively shapes, an outcome with legal or similarly significant effects on a person, and no human with genuine authority, time and information reviews it. Such decisions are banned unless contract necessity, EU or national law, or explicit consent applies, each with mandatory safeguards.

The exposure is no longer theoretical. On 21 August 2026 the Dutch data protection authority fined Uber €824,990,000 for deactivating drivers with no human review (Pearl Cohen). The CJEU has ruled twice on Article 22 and its explanation right since December 2023, and the AI Act’s high-risk duties for hiring and credit systems start on 2 December 2027.

What Article 22 requires, and whose guidance counts

Article 22(1) gives the data subject “the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.” The CJEU reads that as three cumulative conditions: a decision, based solely on automated processing, with legal or similarly significant effects (SCHUFA, para. 43). It is a prohibition in principle, which applies whether or not the person invokes it (Matheson on EDPB-EDPS Joint Opinion 2/2026).

Article 22(2) lifts the prohibition where the decision is necessary for entering into or performing a contract, authorised by EU or member-state law with suitable safeguards, or based on explicit consent. On the contract and consent routes, Article 22(3) requires at least the rights to obtain human intervention, to express a point of view and to contest the decision. Article 22(4) bars decisions based on special-category data unless Article 9(2)(a) or (g) applies and suitable safeguards are in place (Article 22).

The standard guidance is not an EDPB text. It is the Article 29 Working Party’s WP251rev.01 guidelines, which the EDPB endorsed at its first plenary on 25 May 2018. As the Spanish DPA quotes them, “The controller cannot avoid the Article 22 provisions by fabricating human involvement.” Oversight must be “meaningful, rather than just a token gesture”, carried out by “someone who has the authority and competence to change the decision”, who should “consider all the relevant data”.

None of this has changed yet. The Commission’s GDPR Digital Omnibus proposal, COM(2025) 837 (Law and Technology), would recast Article 22 as an exhaustive list of permitted cases, which the EDPB and EDPS pushed back on. As of 24 September 2026 the Council had no negotiating mandate and trilogues had not begun (Acompli).

Rulings and fines that define “solely automated” and meaningful review

Four working rules follow for LLM pipelines:

• A recommendation can be the decision. In SCHUFA, “an insufficient probability value leads, in almost all cases, to the refusal” of the loan (para. 48). An advance/reject label that staff nearly always follow sits in the same place.
• The controller must prove the review. Uber had a risk team; the court still found the intervention unproven.
• Review before the consequence. “These decisions should have been looked at first by a human being,” said the AP’s deputy chair, Monique Verdier (Pearl Cohen).
• Explain factors and weights. The Amsterdam court ordered them disclosed at an aggregated level; a formula is not an explanation.

Breaches of Articles 12 to 22 carry fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher (Article 83(5)). The two CJEU judgments were preliminary rulings, not fines.

A yes/no checklist to run per decision class

Run it for each decision class (a screening rejection, a fraud hold, a price quote), not per system; one LLM pipeline often produces several.

1. Does the output set or feed an outcome for an identifiable person? Selecting, rejecting, ranking, pricing, flagging, suspending and routing all count. The CJEU reads “decision” broadly (SCHUFA, para. 45), and Recital 71 names “automatic refusal of an online credit application” and “e-recruiting practices without any human intervention”. Free-text rationales staff act on count, as do scores you supply to clients who draw strongly on them. No: Article 22 does not apply, though Articles 5, 6 and 13 to 15 do. Yes: go to 2.
2. Could it have a legal or similarly significant effect? WP251 asks whether it can “significantly affect the circumstances, behaviour or choices of the individuals concerned; have a prolonged or permanent impact on the data subject; or at its most extreme, lead to the exclusion or discrimination of individuals” (quoted by Jessie Levano). Pricing can qualify where “prohibitively high prices effectively bar someone from certain goods or services” (GDPR-Text). No: record why. Yes: go to 3.
3. Before the outcome takes effect, does a person with authority, competence, time and all relevant data review each case, and can you prove it? The AEPD adds training, independence from organisational pressure and “the necessary time” for each decision. Yes, with evidence: not solely automated; keep the evidence and read the AI Act section. No, or unprovable: go to 4.
4. Does an Article 22(2) exception apply? Contract necessity is read strictly: if equally effective, less intrusive means exist, the automated decision is not necessary. A law-based exception needs a law that itself lays down suitable safeguards (SCHUFA, para. 65). Explicit consent is the third route. None: add genuine review or stop. One applies: go to 5.
5. Could special-category data reach the decision? Article 22(4) then needs explicit consent under Article 9(2)(a) or a substantial-public-interest law under 9(2)(g), plus suitable measures (Article 9). Data that reveal sensitive information indirectly count (C-184/20), and a CV can mention a health-related gap, a union role or a religious organisation. Yes, without either basis: redact those data before the model, test that it does not infer them, or send the case to a person.
6. Record what follows. Contract and consent routes: the Article 22(3) rights. Every Article 22 decision: notice under Articles 13(2)(f) or 14(2)(g), explanation on request under 15(1)(h), answers within one month, and a DPIA that covers the whole chain, retrieval and tool calls included. Annex III uses: the AI Act duties below, whatever the answer at step 3.

Worked example: an LLM CV screen that fails, and one that holds up

An employer’s applicant-tracking system sends each CV and set of screening answers to an LLM along with the job’s requirements. The model returns “advance” or “reject” with a short rationale, and a recruiter works the queue.

Two elements are straightforward. A screening rejection is a decision, and losing a shot at a job meets the WP251 significance test. The system is also high-risk under Annex III point 4(a), which covers AI “to analyse and filter job applications, and to evaluate candidates”. Everything turns on the third: whether the decision is solely automated.

The review that fails (illustrative figures):

• One recruiter clears 400 CVs a day: 72 seconds each over an eight-hour shift.
• The queue shows the label and one line of rationale; the CV is a click away.
• Confirming takes one click; reversing a rejection needs a team lead’s sign-off.
• The recruiter’s target is throughput.
• The override rate is 0.3%, about one CV a day, and nobody can say whether that reflects accuracy or deference.

Each line matches a failure named above: no look at “all the relevant data”, no practical authority, pressure without time, and no evidence of real intervention.

The review that holds up:

• What the reviewer sees: the full CV and answers, the requirements, and the model’s finding on each requirement, tied to the CV passage it used and flagged where the CV is silent. The overall recommendation appears only after the findings are checked.
• Time per item: set from a timed pilot in which recruiters assess sample CVs without the model’s output; staff the queue to that time.
• Authority: any recruiter can advance a rejected candidate without sign-off, and every rejection needs the recruiter’s own reason code.
• Incentives: no target for agreeing with the model; throughput reported next to override and appeal results.
• Logging: the fields in the records table below, including time spent and what the reviewer opened.

A simpler variant lets the model only advance candidates and sends every would-be rejection to a person.

Keeping a fully automated first sift means relying on the contract exception, and WP251’s example of necessary automated shortlisting rests on “the exceptionally high volume of applications”. The notice and appeal below then become mandatory. Publish them for the reviewed design too, since a DPA or court may find your review was not meaningful, as the Amsterdam court found Uber’s.

Notice text (draft):

How we screen applications. An AI system (a large language model) compares your CV and screening answers with the published requirements for this role and recommends whether to move you forward. It does not receive your photo, date of birth or address. [Either: A recruiter checks your full application before any rejection.] [Or: Applications that do not meet [requirement] are rejected automatically because of the volume we receive.] Your rights: you can ask a person to review the decision, give us your view or information we missed, and contest the outcome at [appeal form link]. A recruiter who did not handle your application decides without re-running the AI and replies within one month. You can also ask which factors decided your case.

Appeal flow, routed around the model:

1. The rejection message links to an appeal form, and the request is logged against the decision ID.
2. A reviewer who did not handle the case, and who can reinstate without sign-off, takes it.
3. The reviewer decides on the full application plus the candidate’s statement. The model is not re-run.
4. Written reasons go out within one month; Article 12(3) allows two further months where complexity or volume requires, if you say why within the first.
5. Upheld appeals are logged as overrides with reason codes, and a cluster of them triggers a review of the prompt and requirements.

How the EU AI Act layers on: Annex III, Article 14, Article 86

Annex III lists the uses where many Article 22 decisions sit: recruitment and screening (point 4(a)); promotion, termination, task allocation and performance monitoring (4(b)); public-benefit eligibility decided by or for public authorities (5(a)); creditworthiness and credit scoring, fraud detection excepted (5(b)); and risk assessment and pricing in life and health insurance (5(c)). An LLM that triages motor or property claims is not listed, so the high-risk regime does not reach it, though Article 22 still does. The Article 6(3) exemption for narrow or preparatory tasks never covers a system that profiles people (Article 6).

Meeting Article 14 does not settle Article 22: a well-designed system can still be run as a rubber stamp. Under Article 26, deployers must also keep the system’s logs for at least six months, inform workers’ representatives before workplace use and tell people they are subject to the system.

Article 86 gives a person affected by a deployer’s decision based on an Annex III high-risk system’s output, with legal or similarly significant adverse effects, a right to “clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken” (Article 86). The decision need not be solely automated, and the article applies only where Union law does not already provide the right. Meaningful review takes you out of Article 22, not out of explaining the AI’s role.

Dates. The AI Omnibus, Regulation (EU) 2026/1744, was published on 24 July 2026 and took effect on 27 July (NicFab). Chapter III Sections 1 to 3 (classification, requirements, and provider and deployer obligations) apply to Annex III systems from 2 December 2027 and to Annex I products from 2 August 2028 (FPF). Article 86 sits outside Chapter III but only attaches to Annex III systems (Article 86). The chatbot disclosure duty in Article 50 kept its 2 August 2026 start.

If the model comes from a third party, the documentation Article 53 requires GPAI providers to pass downstream is where your reviewers’ grasp of its limits begins; see the Articles 53 and 55 GPAI provider checklist. Platforms face a stricter rule: under Directive (EU) 2024/2831, the Platform Work Directive, decisions to restrict, suspend or terminate a platform worker’s account must be taken by a human being, with transposition due by 2 December 2026 (Mason Hayes Curran, Freshfields).

Explaining an LLM decision under Dun & Bradstreet

Articles 13(2)(f) and 14(2)(g) in the privacy notice, and 15(1)(h) on request, require “meaningful information about the logic involved, as well as the significance and the envisaged consequences” of Article 22 decisions. The CJEU’s reading in Dun & Bradstreet:

• explain “the procedure and principles actually applied” to the person’s data (para. 66), so they can give their view and contest (para. 55);
• “a complex mathematical formula, such as an algorithm”, or a description of every step is not enough (para. 59), and complexity is no excuse (para. 61);
• showing how far a change in their data would have changed the result may suffice (para. 62).

For an LLM pipeline that means five things: the criteria the prompt tells the model to apply and their relative weight; the person’s data that went in, retrieved documents included; how the output maps to the outcome; what the reviewer did; and the main factors in this case. A contestable version:

Your application for [role, reference] was not shortlisted on [date]. The AI system checked your CV against the four published requirements. It found two met (degree, Python) and two unmet: two years of production SQL experience (your CV shows a six-month internship) and Dutch at B2 level (not mentioned). A recruiter reviewed your full application on [date] and agreed. Evidence of either unmet requirement would have changed the result. We used your CV and screening answers, not your photo, age or address. If something was missed or misread, contest it at [link].

Test that counterfactual sentence before sending it: re-run the logged input with the one field changed and keep both runs. LLM outputs can vary between runs, so the explanation must describe the logged run, not a fresh one.

Trade secrets. A controller that believes an explanation would expose trade secrets or other people’s data cannot simply refuse. It must give the material to the DPA or court, which balances the interests and sets how much the person receives, and a national rule excluding access wholesale, like Austria’s, is precluded by the GDPR (paras. 74 to 76). The Amsterdam court likewise rejected Uber’s and Ola’s confidentiality objections. Never withhold the requirements applied, the data used, the main factors in the case or the reviewer’s role. Anything you do claim protection for, such as the verbatim prompt, rubric weights or vendor model internals, goes before the regulator.

The records and metrics a DPA will ask for

Courts and DPAs have demanded evidence of the human review (Uber), the logic behind rejections (Hamburg) and periodic checks of algorithmic accuracy (Foodinho). Log these per decision:

Keep the logs at least six months if you are a high-risk deployer (Article 26(6)), and no longer than your appeal and audit windows need: they are personal data too. For the tracing layer, mlobserve.com’s tracing patterns cover the observability stack.

Is the review meaningful? No published guidance fixes a numeric floor for override rates, and a low rate alone cannot separate an accurate model from deferential reviewers. Run three measures monthly for each decision class:

1. Blind second review. Send a random sample, fixed in advance, to a second reviewer who never sees the model’s output. If sighted reviewers agree with the model far more often than blind ones, they are anchoring on it: the automation bias Article 14(4)(b) names.
2. Seeded cases. Insert synthetic known-answer items carrying a deliberately wrong recommendation and record each reviewer’s catch rate.
3. Override, time and appeal rates per reviewer (PostgreSQL):

SELECT reviewer_id,
       date_trunc('month', decided_at) AS month,
       count(*) AS reviewed,
       percentile_cont(0.5) WITHIN GROUP (ORDER BY decided_at - opened_at) AS median_time,
       avg((final_outcome <> llm_recommendation)::int) AS override_rate,
       avg((appeal_upheld IS TRUE)::int) AS upheld_appeal_rate
FROM decision_log
WHERE decision_class = 'cv_screen'
GROUP BY reviewer_id, month;

Differential impact. Compute each group’s selection rate at each stage (model, reviewer, appeal) and its ratio to the highest group’s rate:

SELECT stage, group_label, count(*) AS n,
       avg((outcome = 'advance')::int) AS selection_rate
FROM decision_outcomes
WHERE decision_class = 'cv_screen'
GROUP BY stage, group_label;

Nothing in the GDPR or the AI Act sets a numeric disparity threshold: record the ratios, investigate gaps and document what you changed. Grouping by ethnicity or disability is special-category processing; the AI Act’s new Article 4a, applicable since 27 July 2026, lets providers and deployers do it where strictly necessary for bias detection and correction, under conditions (FPF). When a decision goes wrong in public, aiincidents.org’s logging methodology shows how such events are tracked.

Related guides

For the rights people hold over training data and decision records, see training data privacy and GDPR data subject rights and the wider GDPR compliance guide for machine learning models. California’s ADMT rules impose their own pre-use notice, opt-out and appeal duties on much the same workflows; see CCPA, CPRA and the ADMT rules for LLM products.

FAQ

Does a human in the loop take an LLM decision out of Article 22?

Only if the review is meaningful and provable: before the decision takes effect, someone with authority and competence to change it must weigh all the relevant data. Uber’s review team failed that test at the Amsterdam Court of Appeal in 2023, and in 2026 the Dutch DPA fined Uber nearly €825 million over unreviewed deactivations.

Is AI CV screening legal under GDPR?

Yes, if a person meaningfully decides every rejection, or if an Article 22(2) exception applies with its safeguards. WP29’s guidance gives exceptionally high application volumes as its example of automated shortlisting that may be necessary for a contract. From 2 December 2027 the AI Act’s high-risk duties also apply to CV screening.

Do I have to show applicants the prompt that rejected them?

Not necessarily: the duty is to explain, not to hand over the prompt. You must explain the procedure and principles actually applied: the criteria, data used, main factors in their case and the human’s role. Anything you call a trade secret goes to the data protection authority or court to weigh; refusing outright is not allowed.

When does the AI Act right to explanation apply?

Article 86 covers decisions based on Annex III high-risk systems, such as hiring and credit scoring, even when a human takes the final decision. After the AI Omnibus it bites in practice from 2 December 2027, when the Annex III rules it depends on apply. For solely automated decisions, GDPR Article 15(1)(h) already requires an explanation.

What override rate shows meaningful human review?

None on its own. No published guidance fixes a threshold, and a low rate can mean an accurate model or deferential reviewers. Compare sighted reviewers with a blind second review of a random sample, plant known-wrong recommendations to see who catches them, and track time per item and appeal outcomes alongside overrides.