Does Article 22 GDPR ban automated decisions entirely?

No. Article 22 gives the data subject the right not to be subject to a decision based solely on automated processing — including profiling — which produces legal effects or similarly significantly affects them. The article then lists three exceptions: explicit consent, contractual necessity, and authorisation under Union or Member State law. When one of those exceptions applies, the controller still has to implement suitable safeguards including 'at least the right to obtain human intervention'.

What did the Schufa CJEU ruling (C-634/21, December 2023) change?

The Court ruled that the automated generation of a credit score is itself a 'decision' under Article 22, even if a human downstream uses that score to make the final call. This broadened the scope: scoring systems that materially influence the decision can fall under Article 22 even when there's nominally a human in the loop. The practical consequence: if your LLM produces a score or category that the downstream human almost always accepts, you're probably under Article 22.

What does 'meaningful human oversight' require, concretely?

The CJEU and the Article 29 / EDPB guidelines have converged on a substantive test: the human reviewer must have the authority and capacity to change the decision, must base their decision on relevant data, and must not be a rubber stamp. In engineering terms: the reviewer's actual override rate has to be non-zero, their queue time has to be long enough to permit real review, and there has to be an audit trail showing the reviewer engaged with the specific case. Promethean's reviewer gate logs the verdict (approved / rejected / amended) per entry, which gives you that audit trail.

What information does the data subject have a right to under Article 22?

Articles 13(2)(f), 14(2)(g), and 15(1)(h) all require 'meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing'. 'Meaningful' is doing a lot of work in that phrase. EDPB guidance and post-Schufa rulings have pushed toward more specific disclosures than 'we use a proprietary algorithm'. A common pragmatic line: disclose the closed-enum categories the system uses, the model identity at a generic level (e.g. 'large language model from vendor X'), the input fields, and the human review process.

What does Promethean help with vs. what the operator still owes?

Promethean's role is to make the per-decision evidence verifiable: spec hash, input hash, output hash, schema-validation result, reviewer verdict, fallback flag, timestamp, signing chain. That covers the technical proof of 'a human reviewed this' and 'this decision was made under this exact configuration'. What the operator still owes: the lawful basis assessment (Article 6), the Article 13/14/15 disclosures in plain language, the DPIA (Article 35), the legitimate interests balancing test where applicable, and the substantive design of the reviewer process. Promethean ships the GDPR handoff packet on Enterprise tier with each article's evidence kinds mapped out.

GDPR Article 22 — automated decisions, meaningful human oversight, and what the audit log proves

Article 22 GDPR is short. The text reads: "The data subject shall have 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." Then come three exceptions and a clause about safeguards.

That single article generates more compliance pain than any other GDPR provision in the AI context — because the words "solely", "decision", "legal effects", "similarly significantly", and "meaningful human intervention" each have an active body of case law that has substantially expanded what they mean since 2018. This post is about how to think about Article 22 in 2026, what the audit log has to prove, and where the substrate fits.

What Article 22 says, with the operative phrases highlighted

The data subject shall have 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.
— GDPR Article 22(1)

Article 22(2) carves out three exceptions:

(a) the decision is necessary for entering into, or performance of, a contract between the data subject and a data controller;
(b) authorised by Union or Member State law to which the controller is subject;
(c) based on the data subject's explicit consent.

Article 22(3) then says: even when an exception applies, the controller 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."

"Solely" — what the Schufa ruling changed

Before December 2023, many controllers held a narrow reading: if a human formally approved every decision, the processing was not "solely" automated and Article 22 did not apply. The CJEU's SCHUFA Holding ruling (Case C-634/21) blew that interpretation up.

The case concerned a credit reference agency that generated scores used by banks to make lending decisions. The bank nominally made the final call. The CJEU held that the score-generation itself constituted a "decision" under Article 22 where it materially determined the outcome — which it did, because banks almost always followed the score.

The operative test the court adopted: if the downstream human decision is materially determined or strongly influenced by the automated output, the automated step is itself a "decision" under Article 22.

In LLM terms: if your reviewer rubber-stamps the model's recommendation 95% of the time, the model's output is the decision. A regulator looking at the override rate in your reviewer-gate log can establish this empirically. This is one reason Promethean records reviewer verdicts as a closed enum (approved / rejected / amended) per entry — the override rate is computable directly from the chain.

"Legal effects" and "similarly significantly affects"

Legal effects: anything that changes the data subject's legal status — eligibility for a benefit, refusal of a service, admission to a programme, contract termination.

"Similarly significantly affects": the EDPB guidance lists examples — automatic refusal of an online credit application, e-recruiting practices without human intervention, behavioural advertising in some cases. The threshold is the impact, not the formal legal status of the decision.

For a regulated-AI deployment, two practical heuristics:

If the decision affects access to credit, employment, education, housing, healthcare, or essential services — it is in scope.
If the decision merely surfaces a recommendation or sorts results in an UI without operationally constraining what happens next — it is likely not in scope. But the operator should evidence why.

"Meaningful human intervention" — the substantive test

Article 22(3) requires "at least the right to obtain human intervention" when an exception applies. The EDPB and subsequent CJEU rulings have converged on a substantive test: the human has to actually have the authority and capacity to change the decision.

Several specific failure modes have been called out:

Token review. A human who clicks "approve" without looking at the case is not providing meaningful intervention. The review queue's time-per-case is a measurable proxy.
No override authority. A human whose role is to validate the automated decision rather than reach their own conclusion does not satisfy the article.
No access to relevant data. The human has to be able to see what the model saw — at minimum the input fields. A reviewer who only sees the output cannot form their own judgment.
No data-subject input route. Article 22(3) explicitly mentions "to express his or her point of view and to contest the decision". The reviewer process has to provide a mechanism for the data subject to contribute.

What the Article 22 audit log has to prove

A DPA or court reviewing an Article 22 complaint will look for evidence on several specific points:

Was an exception under 22(2) genuinely available? The lawful basis recorded in the spec, the contract or consent record, the legal authorisation for the processing.
Did a human actually review the decision? The reviewer-gate firing record per entry, the verdict, the reviewer's identifier, the time spent.
Did the reviewer have authority? The override-rate aggregate across the chain. A reviewer that rejects 0% of cases is suspect.
What information did the data subject receive? The Article 13/14/15 disclosures the operator made and when. (Operator-owned, not in the chain.)
Can the decision be reproduced? Spec hash + input hash + model identity per entry. Same inputs under the same spec must reproduce the same output (or document why not).

What Promethean's L12 chain records, per decision

Field                       Purpose for Article 22
─────────────────────────────────────────────────────────────────
recordedAtIso               Decision timestamp (when the data
                            subject was affected)
specId, specHash            Which version of the AI made the
                            decision; spec changes are visible
modelIdentity               Provider/model/version (Schufa-style
                            disclosure to the data subject)
inputHash                   SHA-256 of the input — replay against
                            redacted source; never raw personal data
outputCanonicalHash         Same treatment for the output
schemaValid                 Did the output validate? Article 22
                            compliance assumes a working system
reviewerVerdict             approved / rejected / amended — closed
                            enum; override-rate computable directly
fallbackTriggered           Did the system fall back to a safe
                            default when the model failed?
attestation                 Ed25519 signature: this entry has not
                            been edited since signing time
prevHash                    Chain integrity: deletions detectable

Article 22 implies Article 35 (DPIA)

Decisions with legal or similarly significant effects almost always trigger Article 35 (Data Protection Impact Assessment). The DPIA itself is operator-owned; the substrate's spec and the L12 chain provide the "describe envisaged processing operations" + "measures envisaged to address the risks" sections of the DPIA template.

Promethean's GDPR handoff packet (Enterprise tier) explicitly enumerates the DPIA contribution under Article 35's evidence kinds.

Designing a substantive reviewer gate

The substrate's reviewer gate is a closed enum the spec author selects:

always-human — every decision queued for review. The strongest posture for Article 22 cases; high operational cost.
on-schema-violation — only when the model output fails the closed-enum schema. Suitable for systems where the model is reliable and humans handle the edge cases.
on-low-confidence — when the model's self-reported confidence is below the spec'slowConfidenceThreshold. Common pattern for credit scoring, fraud, and similar quantified-uncertainty contexts.
never — appropriate only where the decision does not produce legal or similarly significant effects. Document the reason in the spec's descriptionfield.

Choosing the right level is a substantive design choice; the substrate enforces whatever you pick, signs every decision the resulting policy produces, and lets the regulator verify the policy was actually applied.

Actionable summary

Decide whether your AI feature falls under Article 22. Post-Schufa, the bar is lower than most operators think.
If it does, identify which 22(2) exception applies (consent, contract, law) and document the lawful basis in the spec.
Design a substantive reviewer process. Token review fails the meaningful-intervention test.
Record per-decision evidence: spec hash, input hash, model identity, reviewer verdict, timestamp, signing chain. Make it verifiable independently of your observability stack.
Track the override rate. If it is 0% across thousands of decisions, the reviewer is not exercising authority — and a DPA looking at the chain can demonstrate this with one aggregate query.
Build your Article 13/14/15 disclosures using the same per-decision fields. Consistency between the disclosure and the audit trail is what convinces a regulator the disclosure is truthful.

Promethean covers the technical layer of all of the above. The free Dev tier produces real signed chains locally; paid tiers add hosted anchoring and the GDPR-specific framework handoff packet that maps the chain's contents to each article's evidence requirement. See /regulators for the framework template overview.

Sector-specific guidance

For your industry

Article 22 bites hardest in sectors where automated decisions carry legal or similarly significant effects — hiring, underwriting, scoring, eligibility. The per-sector pages map the Article 22 + 13/14/15 evidence into the decisions those products actually make.

All 12 industries →