GDPR Article 22 and AI: What Automated Decision-Making Requires of Production Deployments
GDPR Article 22 limits decisions based solely on automated processing that produce legal or similarly significant effects on the data subject. AI deployments that produce loan approvals, credit decisions, hiring decisions, fraud-detection outcomes, or insurance underwriting fall inside the scope. The exemption pathways carry their own obligations: explicit consent, contract necessity, or Union or member state authorization. The Article 22(3) right to obtain human intervention and the transparency obligation require records that demonstrate the meaningful intervention happened and that the data subject received meaningful information. This piece walks through the article, the exemption pathways, the meaningful-intervention test, and the inspection-layer architecture that produces the evidence the supervisor will accept.

GDPR Article 22 limits decisions based solely on automated processing, including profiling, that produce legal or similarly significant effects on the data subject. The article reads narrowly on its face. Production AI deployments that produce loan approvals, credit decisions, hiring decisions, fraud-detection outcomes, or insurance underwriting fall inside the scope because the decisions meet the legal-or-similarly-significant-effect test. The European Data Protection Board guidance reads the "solely automated" qualifier expansively: a human in the loop who rubber-stamps the model output is solely automated for Article 22 purposes if the human review is not a meaningful intervention. The architecture that satisfies Article 22 is per-decision logging plus a contestability workflow that the inspection layer records support.
I want to walk through the Article 22 obligation, the exemption pathways and what they require, the meaningful-intervention test the supervisor applies, the transparency obligation under Article 22(3), and the inspection-layer architecture that produces the evidence the data protection authority will accept.
What Article 22 actually says
The data subject has the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning the data subject or similarly significantly affects the data subject. The right does not apply if the decision: (a) is necessary for entering into or performance of a contract between the data subject and the controller, (b) is authorized by Union or member state law, or (c) is based on the data subject's explicit consent.
Where exemption (a) or (c) applies, the controller has to 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 the controller's point of view and to contest the decision.
The Article 22(4) special-category restriction applies: decisions under (a), (b), or (c) shall not be based on special categories of personal data unless point (a) or (g) of Article 9(2) applies and suitable measures to safeguard the data subject's rights and freedoms and legitimate interests are in place.
The "legal or similarly significant effect" test
Legal effects cover decisions that affect the data subject's legal status, contracts, or eligibility. A loan denial is a legal effect. An insurance policy denial is a legal effect. A visa application outcome is a legal effect.
Similarly significant effects cover decisions that materially affect the data subject's circumstances even without changing legal status. Differential pricing that excludes the data subject from credit products is similarly significant. Hiring screening that rejects the application is similarly significant. Fraud-detection automation that freezes the data subject's account is similarly significant. The threshold is whether the effect is comparable to a legal effect in its impact on the data subject.
Marketing personalization is generally not similarly significant. Recommendation systems that suggest content are generally not similarly significant. The EDPB guidance treats targeted advertising as borderline depending on the intrusiveness of the targeting and the vulnerability of the targeted population.
The "solely automated" qualifier and the meaningful-intervention test
The Article 22 prohibition attaches to decisions based "solely" on automated processing. A decision with a human in the loop falls outside the prohibition. The EDPB guidance reads "solely" against the meaningful-intervention test: the human has to have actual authority to change the decision, has to consider relevant factors beyond the model's recommendation, and has to have the time and the information to exercise the authority.
A credit officer who approves AI recommendations at a 99.5% rate is solely automated for Article 22 purposes. The human review is a rubber stamp. The supervisor applies the test to the operational reality, not to the org-chart structure.
A credit officer who reviews the AI recommendation against the application file, requests additional documentation when the recommendation is borderline, and overrides the recommendation in a meaningful fraction of cases passes the test. The threshold is qualitative, not a fixed override rate.
The exemption pathways and what they require
Contract necessity (Article 22(2)(a)) covers automated decisions that are objectively necessary for the contract. The supervisor reads "necessary" against the strict necessity test: alternative ways of forming the contract that would not require the automated decision count against the exemption. A credit-card application that requires automated fraud screening at the moment of issuance falls inside the exemption. An automated loan approval that the lender could have made manually at the cost of a longer turnaround time may not.
Explicit consent (Article 22(2)(c)) covers automated decisions the data subject agreed to. Explicit consent requires a clear and specific opt-in, separate from any other consents the data subject provided, with full information about the consequences of the consent. A clickwrap agreement that buries the automated-decision consent in the terms of service does not meet the standard.
Union or member state law authorization (Article 22(2)(b)) covers decisions a specific law mandates or expressly permits. Anti-money-laundering automated screening under Directive (EU) 2015/849 falls inside this category. Country-level fraud reporting under the Italian Antimafia Code falls inside this category. Each member state's authorization scope differs.
Under (a) and (c), the controller has to provide the safeguards required by Article 22(3): the right to obtain human intervention, the right to express a point of view, and the right to contest the decision.
The transparency obligation under Article 13(2)(f), 14(2)(g), and 22(3)
Articles 13 and 14 require the controller to provide the data subject with meaningful information about the logic involved in the automated decision-making, as well as the significance and the envisaged consequences of such processing. The information has to be provided at the moment of data collection (Article 13) or within a reasonable period after obtaining the data (Article 14).
"Meaningful information about the logic" does not require disclosure of the model's training data, the model architecture, or the weights. The EDPB guidance reads the obligation as a clear, simple explanation of how the decision is reached in a form the data subject can understand. The disclosure has to support contestability: the data subject who reads the explanation has to be able to identify the factors that drove the decision and to formulate a challenge.
For AI deployments, the disclosure typically covers the categories of input data the system uses, the categories of output the system produces, the type of model and its general approach (classification, scoring, ranking), the human review process, and the consequences of the output for the data subject.
The contestability workflow
The Article 22(3) right to contest the decision requires a workflow the data subject can invoke. The workflow has to allow the data subject to present additional information, request human review of the decision, and receive a substantive response within a reasonable period.
The supervisor evaluating the workflow asks: does the data subject know the workflow exists? Is the workflow accessible without legal counsel? Does the controller respond substantively, or does the controller deny the contestation without engagement? The records the controller produces for the workflow review have to demonstrate the substantive engagement.
The audit record series the inspection layer commits feeds the contestability workflow. The record for the affected decision carries the inputs the model received, the model and version, the policy state at decision time, the outcome, and the human review status. The contestability response built on the record series presents the data subject with the relevant information in a form that supports contestability.
Where most AI deployments fail the Article 22 test
Three failure modes appear in the supervisor's enforcement actions.
The first is the rubber-stamp human review. The deployer claims a human is in the loop, but the human approves AI recommendations at a near-100% rate with no time or information to exercise meaningful judgment. The supervisor reads the override rate and the per-decision review time and concludes the review is not meaningful.
The second is the inadequate transparency. The privacy notice mentions automated decision-making in a generic clause but does not provide meaningful information about the logic, the significance, or the consequences. The data subject who reads the notice does not understand what the AI is doing or how the data subject's information is used.
The third is the missing audit record. The deployer cannot produce the per-decision evidence that demonstrates the inputs the model received, the policy state at decision time, the model and version, the human review status, or the outcome. The supervisor concludes that the controller cannot demonstrate compliance with the safeguards under Article 22(3).
The inspection-layer architecture that closes the gaps
The inspection layer sits between the calling application and the model endpoint. For each model call that feeds an Article 22 automated decision, the inspection layer captures the input fingerprint (the application's request payload that reached the model), the model and version, the policy bundle version, the routing decision (per-role policy that applied), the model response, the response classifier outcome, and the timestamp.
The human review workflow records the human reviewer's identity, the time the reviewer spent on the decision, the additional documentation requested, the override decision if any, and the reason text. The record links to the original inspection-layer record so the full decision provenance reconstructs from the linked records.
The contestability workflow API surfaces the linked records on the data subject's request. The controller's privacy team produces the Article 22(3) response with the substantive information built from the records.
The retention runs for the lifetime of the data subject's relationship with the controller plus the applicable limitation period for legal challenges, which typically exceeds the GDPR Article 5(1)(e) storage-limitation default for the underlying personal data.
DeepInspect
This is the gap DeepInspect closes for Article 22 automated decisions. DeepInspect sits inline between the calling application and any HTTP LLM endpoint that feeds an automated decision. For every model call, DeepInspect captures the input fingerprint, the model and version, the policy bundle version, the per-route policy that applied, the model response, and the response classifier outcome. The per-decision record carries the cryptographic integrity signature and the chain pointer that support the supervisor's evidence-integrity review.
The architecture supports the human review workflow by surfacing the record to the reviewer at decision time, capturing the override and the reason text, and linking the human-review record back to the original model-call record. The contestability workflow API surfaces the linked records on the data subject's request. The deployment integrates as a single HTTP hop with no application code change beyond the base URL.
If your AI deployment produces decisions inside the Article 22 scope and the supervisor is asking for the evidence, let's talk.
Frequently asked questions
- Does Article 22 apply to AI fraud-detection that freezes accounts without a human review?
Yes. A fraud-detection AI that produces an account freeze without meaningful human review meets the "solely automated" qualifier and the freeze produces a similarly significant effect on the data subject. The decision falls inside Article 22 and requires either an exemption pathway under Article 22(2) plus the Article 22(3) safeguards or a meaningful human intervention before the freeze takes effect. The contract-necessity pathway under (a) often applies to anti-fraud automation but does not eliminate the Article 22(3) safeguard obligation.
- What is the override rate the supervisor uses to apply the meaningful-intervention test?
There is no fixed threshold in the regulation or the EDPB guidance. The supervisor applies a qualitative test that considers the override rate, the per-decision review time, the information available to the reviewer, the reviewer's authority to override, and the operational reality of the workflow. A 99.5% approval rate with no review time is solely automated. A 70% approval rate with substantive review of the borderline cases is generally not solely automated. The threshold sits somewhere between these poles depending on the supervisor and the sector.
- How does the privacy notice satisfy the "meaningful information about the logic" requirement without disclosing the model weights?
The disclosure covers the categories of input data the system uses, the categories of output the system produces, the type of model and its general approach (classification, scoring, ranking), the human review process if applicable, and the consequences of the output for the data subject. The disclosure has to support contestability: the data subject reading the notice has to be able to identify the factors that drove the decision and formulate a challenge. The supervisor evaluates the disclosure against this functional test, not against a technical disclosure standard.
- Can the inspection layer support the contestability workflow without surfacing the model's full reasoning chain to the data subject?
Yes. The contestability response built from the audit record presents the data subject with the information needed to formulate a challenge: the categories of inputs the model received for the data subject's case, the policy state at decision time, the model and version, the outcome, and the human review status if applicable. The response does not need to include the full chain-of-thought or the model's internal token-level reasoning. The contestability standard is functional, not disclosure of the model internals.
- Does the same audit record series support both Article 22 contestability and the supervisor's enforcement audit?
The record series carries the field set both workflows read against. The contestability workflow pulls the records for a specific data subject's decision. The enforcement audit pulls the records across a population to assess the compliance posture (override rate, classifier performance, error rate). A single record series with the inspection-layer schema supports both workflows. The controller produces the Article 22(3) response for the data subject and the supervisor evidence from the same data.