GDPR Article 22 gives individuals the right not to be subject to a decision based solely on automated processing, including profiling, when that decision produces a legal effect or similarly significant impact, which covers many AI-driven decisions such as credit approval, insurance pricing, or hiring screens. A genuinely human-in-the-loop review satisfies this requirement only when the reviewer has real authority to change the outcome; a person who simply approves whatever the model recommends, without meaningful ability to override it, does not meet the standard regulators and courts have applied. Article 22 allows exceptions when the automated decision is necessary for a contract, based on explicit consent, or authorized by law with suitable safeguards, but even under those exceptions the individual retains the right to obtain human intervention and contest the decision. Organizations deploying AI for decisions under Article 22 should design the human review step into the workflow deliberately, with documented criteria for when a reviewer can deviate from the model's output. Many of these same use cases also qualify as high-risk under the EU AI Act, layering a second set of oversight obligations on top. This is general information, not a legal opinion on a specific system. Nanobase AI, a Silicon Valley AI engineering company, designs human review checkpoints into automated decision workflows from the start.
The legal test hides an operational question
GDPR Article 22 gives individuals the right not to be subject to a decision based solely on automated processing when it produces a legal or similarly significant effect, and organizations often assume adding any human step into the workflow satisfies it. The operational question that actually determines compliance is whether the human reviewer has real authority and real opportunity to change the outcome, since a reviewer who rubber-stamps whatever the model recommends does not meet the standard regulators and courts have applied. This is general information about a common compliance question, not a legal opinion on any specific workflow.
Meaningful review versus a rubber stamp
| Signal | Meaningful review | Rubber stamp |
|---|---|---|
| Reviewer's information | Sees full case context, not just the model's recommendation | Sees only an approve or deny button next to the model's output |
| Time per decision | Enough time allotted to actually evaluate the case | Volume and pace make genuine evaluation impossible |
| Override rate | Reviewers deviate from the model's recommendation at some measurable rate | Reviewers approve the model's output essentially every time |
| Documented authority | Written policy confirms the reviewer can override the model's recommendation | No documented path exists for a reviewer to disagree with the system |
| Accountability | Reviewer's decision, not the model's output, is the recorded basis for action | The model's score is treated as the de facto final answer |
An override rate near zero is not necessarily proof of a rubber stamp, since a well-calibrated model might genuinely be right most of the time, but it is the kind of pattern that invites scrutiny and should prompt an honest internal check on whether reviewers actually have the context and authority the policy claims they do.
Designing the override path
Each step below turns "a human looked at it" into a review a regulator would actually recognize as meaningful oversight.
- Give the reviewer the underlying case data and evidence, not just the model's score or recommendation, so an override decision can be genuinely informed.
- Set a realistic caseload that leaves time for actual review, since a queue sized for pure approval throughput signals the review step is procedural rather than substantive.
- Document specific criteria for when a reviewer should deviate from the model's recommendation, giving them a defensible basis for overriding rather than relying on individual judgment alone.
- Log both the model's original recommendation and the reviewer's final decision separately, since this record is exactly what an individual exercising their Article 22 right to contest a decision, or a regulator investigating a complaint, will ask to see.
- Track the override rate over time as an internal signal of whether the review step is functioning as designed.
Where this overlaps the EU AI Act
Many use cases governed by Article 22, such as credit decisions, insurance pricing, and hiring, also qualify as high-risk under the EU AI Act, which layers its own human oversight and explainability requirements on top of GDPR's. Article 22 does allow exceptions for decisions necessary for a contract, based on explicit consent, or authorized by law with suitable safeguards, but even under those exceptions the individual retains a right to obtain human intervention and contest the outcome, which means the review workflow described here typically still needs to exist in some form regardless of which legal basis applies.
Frequently asked questions
Does Article 22 apply to every AI-assisted decision?
It applies specifically to decisions based solely on automated processing that produce a legal effect or similarly significant impact on the individual, which covers cases like credit approval or hiring screens but generally not lower-stakes automated assistance such as a spell-check or a product recommendation.
Can a company rely on an Article 22 exception to skip human review entirely?
The exceptions permit fully automated processing under specific conditions, but the individual still retains the right to request human intervention and contest the decision under most of those exceptions, so a review path typically needs to exist even when the exception applies.
How is a rubber-stamp review detected internally?
Tracking the override rate, the time reviewers actually spend per case, and whether reviewers have access to full case context beyond the model's score are the clearest internal signals; a very low override rate combined with a high-volume queue is the pattern worth investigating first.
How Nanobase AI helps
Nanobase AI, a Silicon Valley AI engineering company, designs human review checkpoints into automated decision workflows from the start, building the case-context interfaces and override logging that make the review step genuinely meaningful rather than procedural.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.