An automated system flags a driver's account for low ratings. Within seconds, the account locks. No human reviews the context, no one considers mitigating factors, and the driver's income stops. The Dutch supervisory authority and CNIL just fined Uber 824,990,000 euros for exactly this pattern.
If your team makes automated decisions affecting people's livelihoods, access to services, or legal standing, you're operating in Article 22 territory. This checklist guides you through compliance requirements before your next system goes live.
What This Checklist Covers
Article 22 GDPR prohibits solely automated decision-making with legal or similarly significant effects unless specific conditions apply. This checklist addresses the core requirements: identifying covered decisions, establishing human oversight, documenting your logic, and meeting transparency obligations. It doesn't cover every edge case, but it provides the essential steps you need before deployment.
Prerequisites
Before you start this checklist, confirm:
- You've mapped which systems make automated decisions about individuals.
- You've identified the data subjects affected (employees, customers, contractors, applicants).
- You have access to the technical documentation for these systems.
- You know which lawful basis you're relying on for the underlying processing.
If you're missing any of these, stop. Build that foundation first.
Checklist Items
1. Determine if Article 22 applies to your decision
Does the decision produce legal effects or similarly significant effects on the individual? Account deactivations that cut off income qualify. So do credit denials, employment terminations, insurance pricing that materially affects access, or automated fraud flags that block service access.
☐ Decision documented with specific impact on the individual
☐ Legal team has reviewed significance threshold
☐ You've considered cumulative effect if decision repeats
Good looks like: A written determination that explains why suspending a gig worker's account (cutting off their income source) constitutes a significantly affecting decision, referencing the Uber precedent and your organisation's specific context.
2. Identify your Article 22(2) exception
Solely automated decisions are prohibited unless they're necessary for contract performance, authorised by law, or based on explicit consent. You need one of these three.
☐ Contract necessity documented with explanation of why automation is required
☐ Legal authorisation identified with specific statute or regulation cited
☐ Explicit consent obtained (separate from general terms, freely given, specific to this decision type)
Good looks like: Documentation showing that automated fraud detection is necessary to perform your contract with legitimate users, explaining why manual review of every transaction isn't feasible at scale, but noting that account terminations still require human review.
3. Implement meaningful human intervention
Even with an exception, Article 22(3) requires you to implement safeguards, including the right to obtain human intervention. The Uber case shows that rubber-stamping an algorithm's output doesn't count.
☐ Designated human reviewers identified by role
☐ Reviewers have authority to override the automated decision
☐ Reviewers have access to full context, not just algorithm output
☐ Review happens before significant effect occurs (not just on appeal)
☐ Review process documented with decision-making criteria
Good looks like: A fraud analyst reviews flagged accounts with access to transaction history, user communication, and contextual data. The analyst can reinstate accounts immediately. The review happens within 24 hours of the flag, before the account deactivates.
4. Document the decision logic
Articles 13(2)(f) and 14(2)(g) require you to provide meaningful information about the logic involved, plus the significance and envisaged consequences.
☐ Non-technical explanation prepared of how the system reaches decisions
☐ Factors and weighting documented (what inputs matter most)
☐ Consequences clearly described
☐ Explanation reviewed for accuracy by technical team
Good looks like: "Our system evaluates ride completion rates, customer ratings over the past 90 days, and cancellation patterns. If your customer rating falls below [X] for [Y] consecutive weeks, the system flags your account for review. A human reviewer then examines your full history before any action."
5. Meet transparency obligations upfront
You must inform data subjects about automated decision-making before it happens, not after they're affected.
☐ Privacy notice updated with automated decision-making details
☐ Notice provided at data collection (not buried in later terms)
☐ Specific decisions listed by type
☐ Right to human intervention explained with contact method
Good looks like: Your driver onboarding materials include a dedicated section: "Automated Account Reviews" that explains rating thresholds, fraud detection, the human review process, and how to request intervention. It's in the same document as payment terms, not hidden in a linked policy.
6. Establish the right to contest
Article 22(3) includes the right to express one's point of view and contest the decision.
☐ Clear process for data subjects to submit context or objections
☐ Response timeline defined and communicated
☐ Process accessible (not requiring legal representation)
☐ Outcomes tracked and reviewed
Good looks like: A dedicated email address and in-app form where drivers can contest account flags within 48 hours, with guaranteed human response in five business days. All contests logged with outcomes for quarterly DPO review.
7. Conduct ongoing accuracy monitoring
You're required to implement appropriate technical and organisational measures. That includes monitoring for bias, errors, and drift.
☐ Regular accuracy testing scheduled (at minimum quarterly)
☐ Disparate impact analysis by protected characteristics where applicable
☐ Error rate thresholds defined with escalation process
☐ Model retraining or retirement criteria established
Good looks like: Monthly reports showing false positive rates for fraud detection, broken down by driver tenure and region, with automatic escalation if any segment exceeds 5% false positives. Model retrained or retired if accuracy falls below defined threshold.
Common Mistakes
Treating appeals as sufficient human intervention. The Uber case makes clear: human review after the damage is done doesn't satisfy Article 22. Build intervention into the process before significant effects occur.
Confusing lawful basis with Article 22 exceptions. You need both. Legitimate interests might justify collecting driver ratings, but it doesn't automatically exempt you from Article 22's prohibition on solely automated decisions.
Generic privacy notice language. "We may use automated decision-making" doesn't cut it. Name the specific decisions, explain the logic, describe the consequences.
No technical documentation trail. When a supervisory authority investigates, you need to show exactly how your system worked at the time of the contested decision. Version control and change logs aren't optional.
Next Steps
If any checklist item is incomplete, that's your priority. Don't wait for a complaint to surface the gap.
For decisions already in production: audit them against this checklist within 30 days. For new systems: complete this checklist before user acceptance testing.
The 824,990,000 euro fine represents years of decisions affecting drivers' livelihoods without meaningful human oversight. Your next quarterly review costs far less than your first enforcement action.
