Automated decisions under GDPR: when a human review changes the result (2026)

A recruitment vendor scores every applicant. A hiring manager sees only the score, and the system rejects anyone below a threshold before the manager can reopen the application.

The manager may still appear somewhere in the workflow. The important question is whether the manager can make a real, informed decision before the rejection takes effect.

GDPR Article 22 gives people the right not to be subject to a decision based solely on automated processing, including profiling, when that decision produces legal effects or similarly significantly affects them. The rule covers the path from personal data to consequential decision, not the presence of an AI model by itself. 1

Start with the decision, not the model

Three ideas often appear together in product reviews: automated processing, profiling, and automated decision-making. The ideas overlap, but they answer different questions.

Automated processing describes how personal data is handled. A fixed rule, a statistical score, or a machine-learning model can all process data automatically.

Profiling is automated processing that evaluates personal aspects of a person. The GDPR gives examples such as analysing or predicting work performance, economic situation, health, preferences, reliability, behaviour, location, or movements. Profiling remains subject to the GDPR's legal bases and data-protection principles even when it does not produce an Article 22 decision. 1

Automated decision-making concerns the outcome. Article 22 becomes the relevant decision boundary when all three conditions line up:

A decision affects the person.
The decision is based solely on automated processing, including profiling.
The decision produces legal effects or similarly significantly affects the person.

A recommendation can therefore be automated without being an Article 22 decision. A customer-segmentation model may place people into groups for analysis. A fraud score may send a transaction to manual review. Those uses still require a lawful basis, fairness, transparency, accuracy, security, and other GDPR controls, but the Article 22 route depends on what decision follows and how the decision affects the person. The ICO describes the same boundary in its UK GDPR guidance: solely automated processing means that no meaningful human involvement affects the outcome, while a significant effect can change a person's legal position or materially affect circumstances, behaviour, or opportunities. 2

The starting rule and its three routes

Article 22(1) sets the starting rule. A person has the right not to be subject to a qualifying solely automated decision.

Article 22(2) identifies three routes in which that starting rule does not apply:

Route	What the organisation must establish	Safeguard that still matters
Contract	The decision is necessary for entering into or performing a contract with the person. 1	The controller must provide the Article 22(3) safeguards, including human intervention, the opportunity to express a point of view, and the ability to contest the decision. 1
Law	Union or Member State law authorises the decision and lays down suitable measures to protect the person's rights, freedoms, and legitimate interests. 1	The organisation must follow the safeguards required by the authorising law and the applicable GDPR protections.
Explicit consent	The decision is based on the person's explicit consent. 1	Human intervention, the person's point of view, and the ability to contest the decision remain required under Article 22(3). 1

A contract or consent label does not complete the analysis. The organisation must connect the selected route to the actual decision, show why the decision is necessary or explicitly consented to, and implement the safeguards in the live workflow.

Article 22(4) adds a separate boundary for special category data. A decision under Article 22(2) cannot be based on special category personal data unless the Article 9(2)(a) or 9(2)(g) condition applies and suitable measures protect the person's rights and interests. 1

When a human review is meaningful

A button labelled "human review" does not answer the Article 22 question. The reviewer needs a real opportunity to evaluate the case and change the result before the automated output takes effect.

The European Data Protection Supervisor defines human oversight as the active involvement of at least one trained operator who monitors the system, evaluates its decisions, and can intervene. The EDPS describes meaningful oversight as active involvement that improves the decision rather than a procedural formality. The operator also needs enough authority to override the system's decisions. 3

That definition creates four practical tests:

Timing: Can the person review the output before the rejection, price, suspension, or allocation takes effect? A review after the person has already suffered the consequence may provide a remedy, but it does not turn the earlier decision into a human decision.
Information: Does the reviewer receive the facts needed to assess the individual case, including relevant context and known uncertainty? A score without the underlying factors can make independent review impossible.
Authority: Can the reviewer depart from the model, and can the organisation measure whether reviewers actually do so? A reviewer who must approve every output or lacks permission to reopen a case has formal involvement without decision authority.
Competence and capacity: Does the reviewer understand the task, know when the model may fail, have time to assess the case, and have a usable override path? A queue that gives a reviewer seconds to approve thousands of decisions makes the review performative.

The EDPS discusses the risk that operators defer to automated outputs because the system appears more expert, because managers discourage overrides, or because the interface makes the output difficult to question. Formal authority therefore needs operational support: training, clear escalation rules, an interface that exposes relevant information, time for review, and a recorded way to change the result. 3

Consider the recruitment example again. The manager receives the low score only after the system has rejected the candidate. The manager cannot reopen the application and has no access to the factors that produced the score. The manager's presence does not change the classification: the rejection was based solely on automated processing.

What counts as a significant effect

Article 22 uses two related thresholds: a legal effect and a similarly significant effect.

A legal effect changes a person's legal position or rights. A similarly significant effect can materially affect the person's circumstances, behaviour, or opportunities. The GDPR's Recital 71 gives automatic refusal of an online credit application and e-recruiting without human intervention as examples. 1

The action that follows the score usually matters more than the technical sophistication of the scoring method. A simple eligibility rule can produce a significant effect. A complex model can produce a less significant output when the output only helps a person prioritise ordinary service work and a human makes the consequential decision.

Ask what the person loses, receives, or becomes unable to do because of the output:

Does the output approve or deny access to credit, employment, insurance, housing, or another important opportunity?
Does the output change a legal entitlement, contractual position, payment, benefit, or account status?
Does the output impose a suspension, restriction, investigation, or other consequence that materially changes the person's situation?
Does a person have a genuine chance to correct the decision before the consequence takes effect?

The last question affects the workflow analysis. A later complaint channel may be valuable, but a post-decision appeal is different from a meaningful human intervention before the decision takes effect. The organisation should record both paths instead of treating the appeal process as proof that the original automated decision had human involvement.

A decision screen for product and procurement reviews

A DPO or product reviewer can test a proposed workflow in this order.

Name the decision and the action it triggers. Write the output in operational terms: reject an application, pause a payment, set a price, rank a candidate, limit an account, or route a case. "The model evaluates risk" is too vague to test.
Identify the data and the purpose. List the personal data, inferred attributes, scoring features, and purpose for each output. Separate a recommendation used by an employee from an automated action that changes the person's position.
Classify the effect. Record the legal effect or the concrete circumstance, behaviour, or opportunity that changes. Use the action and its practical consequence rather than the vendor's label for the model.
Test the human role before deployment. Identify the person who reviews the output, the point in time when the review occurs, the information available, the authority to override, and the time allowed. Test the workflow with an edge case that the model is likely to handle poorly.
Select the Article 22 route. If the workflow is a qualifying solely automated decision, record whether the organisation relies on contractual necessity, authorising law, or explicit consent. Explain why the selected route fits this decision rather than another processing activity.
Build the safeguards into the user journey. Give the person information about the automated decision and its significance. Provide a route to obtain human intervention, express a point of view, and contest the decision. The route needs an owner, a response path, and enough information to make the challenge useful. Article 22(3) supplies the minimum safeguards for the contract and consent routes, and Recital 71 describes information, explanation, human intervention, the person's point of view, and contesting the decision. 1 1
Check special category data and DPIA triggers. If the decision uses special category data, apply Article 22(4) and Article 9 separately. A DPIA is required for processing that involves systematic and extensive evaluation of personal aspects based on profiling when decisions produce legal or similarly significant effects; the GDPR identifies that activity as a high-risk example. 1
Test the deployed workflow. Review override rates, reasons for overrides, error patterns, complaints, correction requests, and cases in which the system's output reached the person before a reviewer could act. Reopen the assessment when the purpose, data, threshold, vendor, reviewer role, or consequence changes.

The ICO's March 2026 recruitment work gives this screen a concrete operational shape. The regulator told businesses to review automated recruitment decisions, monitor for bias, tell jobseekers when automated decision-making is used, and explain how people can challenge a decision or request human review. The ICO's material is UK GDPR guidance and reflects UK legal developments; it is operational corroboration for a workflow, while the EU GDPR remains the governing text for an EU GDPR assessment. 4

Common shortcuts and their repairs

Shortcut	What remains unresolved	Repair
"A person is in the loop, so Article 22 does not apply."	Can the person change the result before it takes effect?	Record timing, information, authority, competence, and the actual override path.
"The model only ranks candidates; the business makes the decision."	Does the ranking automatically exclude candidates or determine who receives an opportunity?	Trace the output into the next action and assess the effect of that action.
"The vendor says the tool is an assistant."	Does the deployed configuration automatically reject, suspend, price, or restrict people?	Review the configured workflow, thresholds, integrations, and permissions rather than the product description.
"Consent covers the automated decision."	Has the person given explicit consent, and are Article 22(3) safeguards live?	Preserve the consent wording and build human intervention, expression of a point of view, and contesting into the process. 1
"The model explanation is enough."	Can the person understand the decision's significance, express a view, and contest the outcome?	Explain the relevant logic, consequences, decision path, and route for human review in terms the person can use. 2
"A later appeal makes the original decision human."	Did the automated outcome already take effect?	Separate a pre-decision human intervention from a post-decision remedy and record both.
"A DPIA is the approval."	Has the live system implemented the safeguards and kept evidence of review?	Treat the DPIA as a risk and design record, then test the deployed workflow and update the record when the workflow changes.

The reviewer record

A reviewer should be able to reconstruct the route from input to outcome without relying on the vendor's marketing description. Keep these fields for each significant automated decision:

Decision: the action, threshold, output, and consequence for the person.
Processing: the purpose, data fields, inferred attributes, model or rule version, and relevant vendor or subprocessor.
Article 22 analysis: whether the decision is solely automated, why the effect is legal or similarly significant, and which Article 22(2) route applies.
Human involvement: reviewer identity or role, review timing, information supplied, training, authority to override, time available, override action, and escalation path.
Safeguards: notice of automated decision-making, meaningful information about the logic involved, significance and envisaged consequences, human-intervention route, opportunity to express a point of view, contest route, and response record. The GDPR requires information about the existence of relevant automated decision-making and meaningful information about the logic, significance, and envisaged consequences in Articles 13, 14, and 15. 1
Data and risk controls: special-category-data analysis, accuracy checks, bias monitoring, security controls, DPIA reference, complaints, corrections, and review triggers.
Outcome: the final decision, any change made by a human, the person's response, and the evidence that the organisation communicated the result.

The decisive record is the link between authority and action. A workflow that logs only "review completed" leaves open whether the reviewer saw the case in time, understood the output, and could change it. A workflow that records those facts gives the organisation a basis for examining both the legal route and the real experience of the person affected.

When a model, rule, or score leads directly to a significant decision, the organisation should begin with the Article 22 question. A human name in the workflow is insufficient. The review must happen before the consequence, with enough information, authority, competence, and time to change the outcome, and the affected person needs a usable way to understand, challenge, and contest the decision.

References

1
Regulation (EU) 2016/679 (GDPR), Article 22
data.europa.eu
2
Legal framework | ICO
ico.org.uk
3
TechDispatch on human oversight of automated decision-making | European Data Protection Supervisor
edps.europa.eu
4
Automated decisions can streamline the hiring process – with the right safeguards in place | ICO
ico.org.uk

A recruitment vendor scores every applicant. A hiring manager sees only the score, and the system rejects anyone below a threshold before the manager can reopen the application.

The manager may still appear somewhere in the workflow. The important question is whether the manager can make a real, informed decision before the rejection takes effect.

Start with the decision, not the model

Three ideas often appear together in product reviews: automated processing, profiling, and automated decision-making. The ideas overlap, but they answer different questions.

Automated processing describes how personal data is handled. A fixed rule, a statistical score, or a machine-learning model can all process data automatically.

Automated decision-making concerns the outcome. Article 22 becomes the relevant decision boundary when all three conditions line up:

A decision affects the person.
The decision is based solely on automated processing, including profiling.
The decision produces legal effects or similarly significantly affects the person.

The starting rule and its three routes

Article 22(1) sets the starting rule. A person has the right not to be subject to a qualifying solely automated decision.

Article 22(2) identifies three routes in which that starting rule does not apply:

Route	What the organisation must establish	Safeguard that still matters
Contract	The decision is necessary for entering into or performing a contract with the person. 1	The controller must provide the Article 22(3) safeguards, including human intervention, the opportunity to express a point of view, and the ability to contest the decision. 1
Law	Union or Member State law authorises the decision and lays down suitable measures to protect the person's rights, freedoms, and legitimate interests. 1	The organisation must follow the safeguards required by the authorising law and the applicable GDPR protections.
Explicit consent	The decision is based on the person's explicit consent. 1	Human intervention, the person's point of view, and the ability to contest the decision remain required under Article 22(3). 1

When a human review is meaningful

A button labelled "human review" does not answer the Article 22 question. The reviewer needs a real opportunity to evaluate the case and change the result before the automated output takes effect.

That definition creates four practical tests:

Timing: Can the person review the output before the rejection, price, suspension, or allocation takes effect? A review after the person has already suffered the consequence may provide a remedy, but it does not turn the earlier decision into a human decision.
Information: Does the reviewer receive the facts needed to assess the individual case, including relevant context and known uncertainty? A score without the underlying factors can make independent review impossible.
Authority: Can the reviewer depart from the model, and can the organisation measure whether reviewers actually do so? A reviewer who must approve every output or lacks permission to reopen a case has formal involvement without decision authority.
Competence and capacity: Does the reviewer understand the task, know when the model may fail, have time to assess the case, and have a usable override path? A queue that gives a reviewer seconds to approve thousands of decisions makes the review performative.

What counts as a significant effect

Article 22 uses two related thresholds: a legal effect and a similarly significant effect.

Ask what the person loses, receives, or becomes unable to do because of the output:

Does the output approve or deny access to credit, employment, insurance, housing, or another important opportunity?
Does the output change a legal entitlement, contractual position, payment, benefit, or account status?
Does the output impose a suspension, restriction, investigation, or other consequence that materially changes the person's situation?
Does a person have a genuine chance to correct the decision before the consequence takes effect?

A decision screen for product and procurement reviews

A DPO or product reviewer can test a proposed workflow in this order.

Name the decision and the action it triggers. Write the output in operational terms: reject an application, pause a payment, set a price, rank a candidate, limit an account, or route a case. "The model evaluates risk" is too vague to test.
Identify the data and the purpose. List the personal data, inferred attributes, scoring features, and purpose for each output. Separate a recommendation used by an employee from an automated action that changes the person's position.
Classify the effect. Record the legal effect or the concrete circumstance, behaviour, or opportunity that changes. Use the action and its practical consequence rather than the vendor's label for the model.
Test the human role before deployment. Identify the person who reviews the output, the point in time when the review occurs, the information available, the authority to override, and the time allowed. Test the workflow with an edge case that the model is likely to handle poorly.
Select the Article 22 route. If the workflow is a qualifying solely automated decision, record whether the organisation relies on contractual necessity, authorising law, or explicit consent. Explain why the selected route fits this decision rather than another processing activity.
Build the safeguards into the user journey. Give the person information about the automated decision and its significance. Provide a route to obtain human intervention, express a point of view, and contest the decision. The route needs an owner, a response path, and enough information to make the challenge useful. Article 22(3) supplies the minimum safeguards for the contract and consent routes, and Recital 71 describes information, explanation, human intervention, the person's point of view, and contesting the decision. 1 1
Check special category data and DPIA triggers. If the decision uses special category data, apply Article 22(4) and Article 9 separately. A DPIA is required for processing that involves systematic and extensive evaluation of personal aspects based on profiling when decisions produce legal or similarly significant effects; the GDPR identifies that activity as a high-risk example. 1
Test the deployed workflow. Review override rates, reasons for overrides, error patterns, complaints, correction requests, and cases in which the system's output reached the person before a reviewer could act. Reopen the assessment when the purpose, data, threshold, vendor, reviewer role, or consequence changes.

Common shortcuts and their repairs

Shortcut	What remains unresolved	Repair
"A person is in the loop, so Article 22 does not apply."	Can the person change the result before it takes effect?	Record timing, information, authority, competence, and the actual override path.
"The model only ranks candidates; the business makes the decision."	Does the ranking automatically exclude candidates or determine who receives an opportunity?	Trace the output into the next action and assess the effect of that action.
"The vendor says the tool is an assistant."	Does the deployed configuration automatically reject, suspend, price, or restrict people?	Review the configured workflow, thresholds, integrations, and permissions rather than the product description.
"Consent covers the automated decision."	Has the person given explicit consent, and are Article 22(3) safeguards live?	Preserve the consent wording and build human intervention, expression of a point of view, and contesting into the process. 1
"The model explanation is enough."	Can the person understand the decision's significance, express a view, and contest the outcome?	Explain the relevant logic, consequences, decision path, and route for human review in terms the person can use. 2
"A later appeal makes the original decision human."	Did the automated outcome already take effect?	Separate a pre-decision human intervention from a post-decision remedy and record both.
"A DPIA is the approval."	Has the live system implemented the safeguards and kept evidence of review?	Treat the DPIA as a risk and design record, then test the deployed workflow and update the record when the workflow changes.

The reviewer record

A reviewer should be able to reconstruct the route from input to outcome without relying on the vendor's marketing description. Keep these fields for each significant automated decision:

Decision: the action, threshold, output, and consequence for the person.
Processing: the purpose, data fields, inferred attributes, model or rule version, and relevant vendor or subprocessor.
Article 22 analysis: whether the decision is solely automated, why the effect is legal or similarly significant, and which Article 22(2) route applies.
Human involvement: reviewer identity or role, review timing, information supplied, training, authority to override, time available, override action, and escalation path.
Safeguards: notice of automated decision-making, meaningful information about the logic involved, significance and envisaged consequences, human-intervention route, opportunity to express a point of view, contest route, and response record. The GDPR requires information about the existence of relevant automated decision-making and meaningful information about the logic, significance, and envisaged consequences in Articles 13, 14, and 15. 1
Data and risk controls: special-category-data analysis, accuracy checks, bias monitoring, security controls, DPIA reference, complaints, corrections, and review triggers.
Outcome: the final decision, any change made by a human, the person's response, and the evidence that the organisation communicated the result.

References

1
Regulation (EU) 2016/679 (GDPR), Article 22
data.europa.eu
2
Legal framework | ICO
ico.org.uk
3
TechDispatch on human oversight of automated decision-making | European Data Protection Supervisor
edps.europa.eu
4
Automated decisions can streamline the hiring process – with the right safeguards in place | ICO
ico.org.uk

Automated decisions under GDPR: when a human review changes the result

Start with the decision, not the model

The starting rule and its three routes

When a human review is meaningful

What counts as a significant effect

A decision screen for product and procurement reviews

Common shortcuts and their repairs

The reviewer record

References

Related content

Automated decisions under GDPR: when a human review changes the result

Start with the decision, not the model

The starting rule and its three routes

When a human review is meaningful

What counts as a significant effect

A decision screen for product and procurement reviews

Common shortcuts and their repairs

The reviewer record

References

Related content