Article 22 GDPR automated decisions: requirements, evidence

What Article 22 GDPR requires when a system decides about people

If your team runs scoring, eligibility, fraud or account-blocking logic that acts on people without a person in the loop, Article 22 GDPR applies to you. It gives people the right not to be subject to a decision based solely on automated processing, including profiling, where the decision produces legal effects or similarly significantly affects them. The prohibition has three exceptions: the decision is necessary for a contract, it is authorised by EU or Member State law with suitable safeguards, or the person has given explicit consent. Where the first or third exception applies, the controller must still provide, at minimum, the right to obtain human intervention, to express a point of view and to contest the decision.

The risk sits in real effects on people: a locked account, a refused loan, a rejected job application or a blocked payment can change someone's finances or access to services without anyone reviewing the case. Human review that only approves what the model output is not enough. The Article 29 Working Party guidelines (WP251 rev.01, endorsed by the EDPB) say oversight must be meaningful, carried out by someone with the authority and competence to change the decision, and that staged or fabricated involvement does not take a system outside Article 22. The hard part is the line between decision support and decision. Confirm, for each automated step, whether a reviewer can actually reverse the outcome, whether they see the inputs and reasons, and whether their override rate is tracked as evidence.

Enforcement is not theoretical. The Dutch DPA fined Uber EUR 824,990,000 for fully automated temporary and permanent deactivation of drivers' accounts in breach of Article 22, and for insufficient information under Article 13. Uber has appealed, so the fine is not final, but the decision signals how supervisory authorities read the exceptions. Before you release or change an automated decision, check whether it is solely automated, which exception you rely on, and what the person can do to express a view or contest the outcome. Your legal and privacy teams should confirm these points, since the answers depend on your sector and the legal basis for each decision.

Which decisions, systems and teams fall under Article 22 GDPR

Article 22 applies only when several tests are met at once, so the first job is to map each automated output against them. The cards below walk through those tests and the teams and vendors that touch the logic, because the answers decide which exception applies and how much human involvement the system must support.

Decision or decision support

Start by asking whether the output actually decides anything. A score that a case handler reviews before acting is decision support, while an output that triggers the outcome directly is a decision. Record which field, threshold or status change is the final act, and who can see the output before it takes effect. Regulators look at what happens in practice, not at the label in the design document.

Solely automated processing

Check whether any person with authority reviews the outcome before it applies. A human who clicks through a queue without reading the inputs does not remove the solely automated character of the decision. Map every step between the model output and the effect, including manual overrides, appeal queues and batch approvals, and note where those steps are real and where they are nominal.

Legal or similarly significant effects

Ask whether the outcome changes a legal position or significantly affects the person, such as access to credit, employment, insurance, housing, essential services or account suspension. The effect is assessed from the person's point of view and their circumstances. Document the reasoning for each decision type, because a borderline effect can become significant when it is applied at scale or to vulnerable people.

Profiling inside the pipeline

Profiling means automated processing that evaluates personal aspects to predict or assess behavior, reliability, preferences or similar traits. Scoring, ranking, fraud indicators and risk tiers usually qualify even when the final decision is made elsewhere. Inventory every feature, derived attribute and model input, since a feature that seems neutral can reveal a protected characteristic or act as a proxy for one.

Lawful basis for the decision

If Article 22 applies, the decision must rest on contract necessity, an authorization in Union or Member State law with suitable safeguards, or explicit consent. Each basis changes the build. Contract and consent decisions need a route to human intervention, a way to express a point of view and a way to contest the outcome, while the statutory route depends on the safeguards written into that law. Confirm the basis before the model goes live.

Teams and third parties touching the logic

Map everyone who changes the logic, data or outputs. This includes data science, product owners who set thresholds, operations staff who handle appeals, scoring vendors, AI model providers and outsourced operations centers. The controller stays responsible for the decision even when a vendor builds or hosts the model, so contracts, access rights and change records must show who can alter the logic and who approved it.

How an assessor tests Article 22 GDPR human review

This table sets out the questions a supervisory authority or assessor asks about Article 22 human review, how each question is tested and the evidence to prepare. Read it as a checklist: a weak answer to any row is a likely finding, and the evidence column shows what would settle the question.

Test question	Test approach	Evidence requested
Is the decision solely automated in practice?	Trace a sample of decisions from input to outcome and record every point where a person acts on them, including reviews that happen in name only.	Decision logs showing the actor for each step, workflow configuration, and the sampling method used by the reviewer.
Are human overrides actually happening?	Compare the override rate and its trend over time, and check whether overrides cluster in particular outcomes or reviewers.	Override logs with timestamps, reviewer IDs and reasons, plus periodic reports showing override rates and the follow-up taken.
Is the exception relied on documented?	Confirm which Article 22(2) basis applies (contract necessity, Union or Member State law with safeguards, or explicit consent) and that the basis fits this decision type.	Written basis assessment per decision type, the contract clause or legal provision, or consent records with the withdrawal route.
Do reviewers hold authority to change the outcome?	Check whether the reviewer can reverse the decision without escalation, and whether the system lets them do so in practice.	Role descriptions, delegation records, and system permissions showing the reviewer can amend or reverse outcomes.
Are reviewers competent to assess the decision?	Interview reviewers on how they judge a case, what training they received and how they handle cases the model flags as uncertain.	Training records, review checklists, and examples of reviewer decisions with the reasoning recorded.
Do reviewers receive the information needed to decide?	Compare what the reviewer sees with what the decision relied on, including input data, score factors and the logic applied.	Reviewer screen or report samples, data mapping from inputs to the review view, and any gaps noted in testing.
Can people express a point of view and contest the decision?	Submit a test challenge through the published route and check that a person reviews it and that the outcome is recorded.	Contest intake records, response times, outcomes of contested cases, and the written reasons given to the person.
Do notices and access responses describe the logic and consequences?	Compare the privacy notice and a sample access response against the actual decision logic and its effects on the person.	Current privacy notice versions, access response templates, and a change record linking notice updates to model changes.
Do reviewers default to approval?	Look for very high approval rates, short review times and identical reasons across cases, which suggest rubber-stamping.	Review duration data, approval rates by reviewer, and records showing reviewers were asked to justify approvals.

Evidence that shows meaningful human involvement under Article 22

Article 22 is tested by looking at how decisions are actually made, not by reading policy text. The cards below cover the records that show a human with real authority reviewed, could change, and explained decisions, and they should be produced as the system runs rather than assembled before an audit.

Decision inventory and exception basis

Keep a register of every process where a decision with legal or similarly significant effects is made or supported by automated processing, including profiling. For each entry, record the purpose, the data used, whether a human reviews the outcome, and which exception applies: contract necessity, authorisation by Union or Member State law, or explicit consent. Review the register whenever a model, rule or data source changes, because an unlisted decision is the first gap a regulator looks for. Illustrative example: a credit line rule that declines applications automatically would appear here with its contract basis.

Reviewer authority and training records

Document who reviews automated outcomes, what authority they hold to change a decision, and what training shows they understand the inputs and the logic. Working Party guidance treats human oversight as meaningful only when the reviewer can change the outcome and is competent to do so. Keep role descriptions, delegation of authority, and dated training completion records, and check that reviewers are not measured solely on agreeing with the system.

Decision and override logs with reasons

Log each automated decision with its input references, output, model or rule version, and timestamp. Record every human override with the reviewer identity, the original outcome, the new outcome and the reason in the reviewer's own words. Write these entries at the moment of review. Reconstructing overrides weeks later weakens their credibility, and a sample of logged overrides shows whether reviewers actually change outcomes.

Contest and point-of-view intake records

Article 22(3) requires suitable measures, at minimum the right to obtain human intervention, to express a point of view and to contest the decision. Keep the intake channel, the time each request was received, the reviewer assigned, the reasoning applied to the contest, and the final outcome communicated to the person. Check that contests reach a reviewer with authority to reverse the decision and that outcomes are recorded, not only acknowledged.

Logic description for notices and access responses

Articles 13, 14 and 15 require meaningful information about the logic involved and the significance and envisaged consequences of automated decisions. Maintain a controlled description of the logic, its main factors and its consequences, and link each version to the notice and access response templates that used it. Confirm with legal counsel that the wording matches what the system does, because a notice that describes a different model is a transparency failure in its own right.

Version history of models and rules

Keep version control over every model, scoring rule, threshold and prompt that influences a decision, with a record of what changed, when, who approved it, and what evidence supported the change. Auditors compare past decisions with the rules in force at that time, so each decision log entry must point to an exact version. Tools such as XWiki can keep documentation history, and BookStack permissions can restrict who edits approved rule descriptions, but confirm each product's audit trail covers the artifacts you need.

How to implement Article 22 GDPR safeguards in sequence

This sequence turns the Article 22 right into working controls: every solely automated decision with significant effects is identified, justified, reviewable by a person with real authority, contestable by the individual, explained in notices, logged, and reviewed whenever the logic changes.

Inventory every automated decision
Start by listing each system, rule set, scoring model or workflow that makes or substantially drives a decision about a person, including profiling that feeds it. For each entry, record the decision, the data used, the outcome and whether the outcome produces legal effects or similarly significantly affects the person. Involve product owners, data science teams and the business function that acts on the output, since they often know where a score quietly becomes the decision. The output is a decision register with one row per decision and a documented significance judgment. Confirm the closing check with your DPO or privacy lead: every row has an owner and a yes or no answer on whether Article 22 applies.
Select and document the exception for each decision
For each decision that falls under Article 22(1), record which of the three exceptions applies: necessity for entering into or performing a contract, authorization by Union or Member State law with suitable safeguards, or explicit consent. Write the reasoning next to the register entry, including why the decision is necessary for the contract and why the chosen legal basis holds up. Where no exception fits, the decision cannot run solely automated and must be redesigned with a person in the loop. The output is an exception record per decision, reviewed by legal counsel, that a regulator or assessor can trace from the decision to its justification.
Design the human intervention path
Define who may review a contested or significant automated decision, what information that reviewer sees, and what authority they hold to change the outcome. Write a reviewer authority matrix that names roles, the decision types each role covers, and the escalation route when a reviewer disagrees with the system or cannot reach a conclusion. Guidance from the Article 29 Working Party treats oversight as meaningful only when the person has authority and competence to change the decision, and fabricated involvement does not avoid Article 22. Test this with a sample of past decisions: a reviewer who approves every system output without access to the underlying inputs fails the test. The output is the matrix plus a test record of reviews that actually changed outcomes or documented why they did not.
Build the point-of-view and contest channel
Where the exception relies on contract or consent, Article 22(3) requires at least the right to obtain human intervention, to express a point of view and to contest the decision. Build an intake path that an affected person can reach from the decision notice, a case record that captures their submission, and a route that sends the case to the reviewer defined in the previous step. Set internal tracking so no submission is lost between the customer service, product and review teams. Confirm the response obligations and any timelines against your own Article 12 process, since this page does not set them. The output is a working channel with test cases showing a submission reaches a reviewer and returns a documented outcome.
Write the logic and consequences into notices
Privacy notices must describe meaningful information about the logic involved and the significance and envisaged consequences of automated decisions (Articles 13(2)(f) and 14(2)(g)), and access responses must contain the same under Article 15(1)(h). Draft these descriptions from the actual model or rule behavior, not from marketing summaries, and have engineers verify each statement against the system. Keep a version of the wording tied to each system release so the notice a person received can be reconstructed later. The output is approved notice text for each register entry, a reconciliation record showing engineering sign-off, and a standard explanation template for access responses.
Instrument logging of decisions and overrides
Log each automated decision with its inputs, output, model or rule version, timestamp and any downstream action, so the decision can be reconstructed when a person contests it or a regulator asks. Log every human review as well, including who reviewed it, what they saw, whether they changed the outcome and the reason. Protect these logs with access controls and retention rules that match your records of processing. Self-hosted tracing tools such as Langfuse can capture operation-level traces for LLM-based workflows, and version control in a wiki or documentation platform such as XWiki or BookStack can hold the approved logic descriptions and reviewer matrices. Confirm each tool's capabilities against your environment before relying on it. The output is a log schema per decision type and a sample reconstruction of one decision from logs alone.
Set a review cycle tied to changes
Schedule reviews of the decision register, exception records, notice text and reviewer matrix, and trigger an out-of-cycle review whenever a model is retrained, a rule changes, a new data source is added or a complaint pattern emerges. Each review checks that the human intervention path still has authority and capacity, and that the logic description still matches the system. The Dutch DPA's 2026 fine against Uber, reported by the EDPB, concerned fully automated account deactivations and insufficient information, which shows how a gap in this chain becomes an enforcement issue. The output is a dated review record per decision, sign-off by the accountable owner, and a change log linking each system change to the review that followed.

Open-source tools that support Article 22 GDPR evidence

Article 22 is tested through evidence: what the system decided, who could override it, and how the safeguards were designed and checked. The four tools below can each generate or hold part of that evidence inside your own infrastructure. None of them makes a decision compliant on its own, and the controller remains responsible for the design.

Decision path tracing

Langfuse (MIT) records each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For Article 22, a trace can show the path from input data to a scoring or recommendation output and to the point where a human reviewer saw it. Check that traces capture the reviewer action and the final decision, not only the model output. Traces contain personal data, so confirm minimization, masking and retention before enabling them.

Versioned policies and procedures

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions or roll back. This suits the written reviewer procedure, escalation rules and criteria for overriding automated outcomes. An assessor will ask which version of the procedure applied on the date of a given decision, so confirm that approved versions are retained and dated.

Documented reviewer authority

BookStack (MIT) assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Use it to document which staff hold authority to change an automated decision and where that authority is recorded. Keep the role model aligned with the actual access rights in the decision system, since a reviewer listed in the wiki but unable to change an outcome does not show meaningful human involvement.

Testing AI-assisted decision components

garak (Apache-2.0) probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Where a language model contributes to a decision about a person, these results help show that the component was tested for failures that could mislead a reviewer. Treat the output as one test input, and confirm which probes match your use case.

What meeting Article 22 GDPR costs in money and effort

This table lists the cost components of running solely automated decisions lawfully under Article 22, who is paid for each, and what drives it up or down. Read it as a map for scoping a quote, since no prices or durations are supplied and the main cost is usually people's time rather than software licenses.

Cost component	Who is paid	One-time or recurring	What drives it and how to keep it down
Legal review of the exception basis	Internal counsel or outside privacy lawyers	One-time per decision type, then recurring on change	Choice between contract necessity, legal authorisation and explicit consent; narrow the scope of each automated decision so the basis is clear and documented.
Engineering time for review queues	Internal engineers or an implementation partner	One-time build, recurring maintenance	Number of decision types routed to humans and how cases are queued; keep routing rules in configuration so changes do not require code releases.
Logging and contest channels	Internal platform team or implementation partner	One-time build, recurring storage and upkeep	Volume of decisions, retention period and how much input data is captured; log the inputs, logic version and outcome, and minimise personal data in logs where possible.
Reviewer time for human intervention	Internal staff with authority to change the outcome	Recurring, scales with contest volume	Contest rate and reviewer training; clear decision criteria and reason templates shorten each review.
Model and rule change control	Internal risk, data science and engineering teams	Recurring with each change	Frequency of model or scoring rule updates; versioned approvals and documented testing make each change cheaper to review and defend.
Notice and access response updates	Internal privacy team, sometimes with counsel	One-time rewrite, recurring on each change	Number of automated decisions and how often logic changes; describe the logic and consequences in a maintained template so access responses can reuse it.
Independent review or testing	External auditors, assessors or testing firms	Recurring, typically per assessment cycle	Scope, system complexity and whether bias or accuracy testing is included; agree a written scope before work starts and ask for the methodology in writing.
Regulatory exposure	Not a purchase; borne by the controller	Contingent	Article 83 sets ceilings of EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, for infringements of data subject rights and principles. The Dutch DPA fine against Uber shows the exposure from automated deactivation without human involvement.

Who owns Article 22 GDPR: your team, a partner and the auditor

Your organization remains the controller and carries the legal duty for every decision the system makes about individuals. That starts with deciding whether a decision is solely automated, which lawful exception (contract, Union or Member State law, or explicit consent) you rely on, and what safeguards come with it. These choices belong to people who understand the business process and the legal basis, and no partner can make them on your behalf.

Decision basis: Document which exception applies to each automated decision, why the decision is necessary or consented to, and who approved that position.
Reviewer authority: Name the people who can override or reverse a decision, confirm they have the competence and time to do so, and record their authority in writing.
Final outcome: Keep the authority to change the result, so a reviewer's conclusion is not overridden by the score or model output without reasons on file.
Privacy notices and access responses: Write meaningful information about the logic, significance and envisaged consequences, and keep it consistent with what the system actually does.
Contest handling: Own the process that answers challenges, including timelines and who decides.

Check that every automated decision in your register has a named owner, a documented basis and a reviewer who can actually change the outcome.

Where organizations fall short on Article 22 GDPR and how to close it

Most Article 22 failures are not caused by a missing rule. They come from a decision process that looks human on paper but is automated in practice, and from documentation that falls behind the system. The cards below cover the gaps assessors and supervisory authorities most often find, with a check the reader can run for each.

Human review that approves by default

Reviewers are shown an automated outcome and asked to confirm it, with no realistic path to disagree. Review queues sized for throughput and default-accept buttons produce the same result as no review at all. Check how many automated outcomes reviewers actually reverse, and whether reviewers can see the inputs behind each score. The *human intervention* safeguard in Article 22(3) is only met if the review can change the result.

Reviewers without authority to change outcomes

Some review roles exist on the org chart but lack the permission, budget or escalation route to overturn a decision. Under the Article 29 Working Party guidance, oversight must be carried out by someone with authority and competence to change the decision. Confirm in writing who may reverse an outcome, what training they have on the model's limits, and whether overturning a decision carries any penalty for the reviewer.

Decision support that is final in practice

A system labeled as decision support often produces a score that staff accept without question, which makes it a decision in substance. Article 22 applies by reference to what the process does, not the label in a policy. Sample recent cases and measure how often the recorded final outcome matches the system output. Where they match almost every time, treat the system as automated and apply the Article 22 controls.

Overrides that leave no record

When a reviewer changes an automated outcome, the change is often made in a case tool with no structured reason, reviewer identity or timestamp. Without that record, you cannot show that human intervention happened, cannot review reviewer consistency, and cannot answer a contest under Article 22(3). Log each override with the original output, the new outcome, the reason and the reviewer, and keep those logs with the decision record.

Privacy notices that name the system but not the logic

Notices often state that automated tools are used, but say nothing about the logic, the factors considered, or what the outcome means for the person. Articles 13(2)(f), 14(2)(g) and 15(1)(h) require meaningful information about the logic involved and the envisaged consequences. Compare each notice against the actual input features and outcomes in the system, and have the wording reviewed by whoever owns the model.

Model and rule changes that outdate the documented basis

Scoring rules, model weights and thresholds change through routine releases, while the documented logic, DPIA and notice stay as first written. The decision basis then describes a system that no longer runs. Tie every change to a version record, assess whether it alters the logic or consequences described to people, and update the notice and DPIA before release. Keep old versions so past decisions can be explained.

Questions buyers ask about Article 22 GDPR cost, effort and outside help

Is a credit or fraud scoring tool covered by Article 22 GDPR?

It can be, and the test is what the output does, not what the tool is called. Article 22 applies when a decision is based solely on automated processing, including profiling, and produces legal effects or similarly significantly affects the person. A score that alone determines a loan refusal, a account suspension or a hiring rejection usually meets that test. A score that only ranks cases for a human reviewer, and where the reviewer has real authority and competence to change the outcome, usually does not. Map each scored decision to its consequence, then document who can override it and how often they do. Confirm the classification with your legal or privacy team, since the answer depends on the specific decision.

What does Article 22 compliance work cost, and what drives the price?

No supplied fact gives a price for this work, so the figure depends on your scope. The main cost components are internal staff time for decision mapping, legal review, engineering changes to add override and contest workflows, logging, and the privacy notice and access response updates required by Articles 13, 14 and 15. An outside partner is paid for the work it is scoped to do, such as technical design, implementation and evidence preparation. Costs rise with the number of automated decisions, the number of systems that feed them, the presence of AI models, and the need for explanation tooling. Ask any provider for a written scope listing deliverables, assumptions and what the client must supply before work starts.

How long does it take, and what does the team need to provide?

Duration depends on how many decision points exist and how far the logic is already documented. Teams usually need a complete inventory of automated decisions, the data inputs and model or rule logic behind each, a named owner with authority to overturn decisions, and access to the systems that record outcomes. Plan time for legal sign-off on the lawful basis (contract, law or explicit consent), for engineering work on review queues and audit logs, and for updating customer-facing information. Ask a partner to state its assumptions about client inputs and review cycles in the written timeline, because delays most often come from missing decision owners or undocumented logic.

Can our own team implement Article 22 safeguards without an outside partner?

Often yes, if the team has three things: privacy or legal capacity to classify decisions, engineers who can change decision workflows, and someone who can independently review outcomes. The GDPR requires no audit or certificate for this, so the decision to hire help is about capacity and independence, not a legal requirement. Outside help is most useful for technical design of review and contest workflows, logging, and evidence packs, or for an independent check of a system the internal team built. Whatever you choose, the controller remains responsible for compliance.

What should a partner deliver, and what will an assessor test?

A partner preparing systems should deliver a decision inventory, a classification record for each decision, the human review and contest workflow, override logs, updated privacy and access response text, and test results showing the workflow works. The GDPR requires no audit, and no certificate exists for Article 22 itself, so an independent auditor or supervisory authority would test the substance: whether the safeguards exist, whether reviewers have real authority and competence, and whether the information given to people is meaningful. A partner does not issue reports or attestations. Ask for the deliverables in writing and confirm with your auditor which evidence it expects.

Does a human clicking approve on every automated decision satisfy Article 22?

Not by itself. The Article 29 Working Party guidelines, endorsed by the EDPB, state that human oversight must be meaningful, carried out by someone with authority and competence to change the decision, and that fabricated human involvement does not avoid Article 22. A reviewer who approves every recommendation without reviewing the underlying data, or who lacks the power to overturn it, leaves the decision effectively automated. Look at override rates, reviewer training, time spent per case and whether reviewers can see the inputs that drove the score. Those signals show whether the human step is real.

What enforcement risk do we face if we get this wrong?

The risk is material. The Dutch DPA fined Uber EUR 824,990,000 for fully automated deactivation of driver accounts in breach of Article 22 and for insufficient information under Article 13, according to the EDPB national news item of 8 October 2026, and Uber has appealed. Article 83 allows fines of up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, for infringements of the rules covered by its highest tier. Treat the Uber case as an illustration of regulator focus, not a benchmark for your own exposure, and confirm the status of the appeal before citing it.

How DeployOpen works on this

DeployOpen works on Article 22 as an implementation partner. We scope the decision systems in your environment, build the logging, review and explanation controls those systems need, and hand over documented evidence. Your organization owns the decisions, the legal basis and the human reviewers, and only an independent auditor or certification body issues reports or certificates.

How we scope

We list every system that makes or supports decisions about individuals, including scoring, ranking, fraud and AI-assisted workflows.
We record which decisions could produce legal or similarly significant effects, and which exception your organization relies on.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We implement a route for people to request human intervention, express a point of view and contest a decision.
We configure traces and version history so each automated decision can be reconstructed and reviewed later.
We run security testing on AI components, including probes for data leakage and unsafe outputs, and record the results.

How we hand over

We document the decision logic summary, review roles and escalation steps in a form your privacy notices and access responses can draw on.
We deliver the evidence register that maps each safeguard to the system and owner that operates it.
We confirm with you which records, review logs and approvals your assessor will ask to see before the handover closes.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We review changes to models, scoring rules and data sources so the documented logic stays accurate.
We help you prepare for supervisory authority questions, but the legal position and any responses remain your organization's responsibility.