Uber's €825M GDPR Fine Isn't About Data Transfers This Time — It's About What 'Human Review' Has to Actually Mean

On 21 August 2026, the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) fined Uber B.V. and Uber Technologies Inc. €824,990,000 — a joint action detailed in CNIL's own published statement, the French regulator that worked the case alongside the AP. It's the second-largest GDPR fine ever issued, behind only Meta's €1.2 billion transfer penalty from 2023. Unlike Uber's previous two GDPR fines — €10 million in December 2023 for failing to inform drivers, and €290 million in July 2024 for unlawful US data transfers — this one has nothing to do with where the data lived. It's about a single mechanism: software that decided, on its own, when a driver stopped being able to earn money.

That distinction matters for anyone building on EU infrastructure who assumed "we're not doing anything with US servers" meant they were in the clear. This fine is a pure Article 22 case — the GDPR provision governing decisions "based solely on automated processing" — and it lands on a mechanism that shows up constantly outside the gig economy: fraud scoring, trust-and-safety bans, credit and risk engines, HR screening. If your platform has a deactivate_account() function that a scoring model can call without a person in the loop, this ruling is about you.

What the regulators found

According to the AP's investigation, which CNIL participated in under GDPR's one-stop-shop mechanism because Uber's EU headquarters sits in the Netherlands, between 2018 and 2022 Uber's software:

• Temporarily suspended driver accounts when its systems flagged suspected fraud.
• Temporarily or permanently deactivated accounts based on consistently low customer ratings.
• Did both without a human evaluating the individual case, and without giving drivers adequate information that an automated system — rather than a person — had made the call.

The case traces back to a 2020 collective complaint filed with CNIL by La Ligue des droits de l'Homme on behalf of more than 170 French Uber drivers (supplemented in 2021), covering three separate issues: information duties, cross-border data transfers, and automated disconnection decisions. The first two produced the earlier €10M and €290M fines. This €824.99M fine resolves the third. AP deputy chair Monique Verdier's framing, reported by ppc.land: "A computer should not make decisions on its own that have major consequences for you." Uber disputes the ruling and has filed an appeal, calling the fine disproportionate and pointing to its existing human-review and appeal mechanisms.

That last part — Uber's claim that human review already existed — is the part worth taking seriously as a developer, because it's exactly where most "we have a human in the loop" compliance stories fall apart.

What Article 22 actually says

The full text, verified directly against gdpr-info.eu and cross-checked against the GDPR's official article index:

Article 22(1): "The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her."

Losing the ability to earn income on a platform is about as clean an example of "similarly significantly affects" as exists — the same logic the Court of Justice of the EU applied in December 2023 (Case C-634/21, SCHUFA Holding), ruling that an automated credit-scoring probability value counts as an Article 22 decision when a third party relies on it heavily to decide whether to enter into or terminate a contract with someone.

Article 22(2) provides three narrow exemptions — the decision is (a) necessary for a contract, (b) authorized by EU or member state law with safeguards, or (c) based on explicit consent. Uber could plausibly invoke (a) for at least some of its account-management logic. But invoking an exemption doesn't get you out of the obligation that actually mattered here — Article 22(3):

"The data controller shall 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 his or her point of view and to contest the decision."

Three concrete rights, not a vague "have a process": human intervention, the ability to state your case, and the ability to contest the outcome. On top of that, Article 13(2)(f) requires telling people up front — at the point of data collection — that automated decision-making under Article 22 exists, and giving them "meaningful information about the logic involved, as well as the significance and the envisaged consequences." The AP's finding wasn't just "no human intervention" — it was also "insufficient information about the automated decision," which is this exact transparency duty.

The test that decides whether your "human review" counts

This is the part most engineering teams get wrong, and it's not a new interpretation invented for this case. The Article 29 Working Party's 2018 guidelines on automated decision-making (WP251, still the operative EU-wide guidance) and national DPA commentary built on it — Spain's AEPD published a direct restatement in 2026 — draw a hard line between real oversight and what amounts to a rubber stamp. Per WP251, as summarized by AEPD:

"The controller cannot avoid the Article 22 provisions by fabricating human involvement... if someone routinely applies automatically generated profiles to individuals without any actual influence on the result, this would still be a decision based solely on automated processing."

Three criteria determine which side of that line a system falls on:

A "human review" step that a person cannot realistically perform at the volume your system pushes through it is not a safeguard — it's a liability, because you now have documented evidence that no meaningful intervention was possible even when it looked like it existed on paper. That's a worse position than having no human-review UI at all, because it demonstrates the controller knew the checkbox existed and didn't make it real.

A self-audit: does your platform have an Article 22 exposure?

Run this over every automated system that can change a user's access, money, or status without a person explicitly signing off:

1. Does the decision happen without a person in the loop today? Account suspensions, fraud/chargeback holds, dynamic risk scores that gate features, automated content-moderation strikes, algorithmic candidate screening, benefit/eligibility calculations. If yes, continue.
2. Does it produce a legal effect or something "similarly significant"? Losing income, losing account access, losing eligibility for a service, being denied a contract. Minor UX personalization (which product recommendation you see) generally doesn't qualify; anything that gates money or access usually does.
3. Is there an applicable Article 22(2) basis (contract necessity, law with safeguards, or explicit consent)? If not, the decision needs to not be solely automated at all — not just have a safeguard bolted on.
4. If a basis applies, can a specific, identifiable person actually overturn the outcome — with the authority, time, and information to do so — not just acknowledge it?
5. Do affected users know, before the fact, that a decision like this can be automated, and what the "significance and envisaged consequences" are (Article 13/14)?
6. Is there a working contest path with a defined response time, not a support queue that silently resolves to "decision upheld" after enough time passes?

If the honest answer to #4 is "a person clicks approve on 200 of these an hour," you have exactly the exposure Uber had — regardless of whether a human technically touches the case.

Building the safeguard instead of the checkbox

The cheapest fix that actually holds up is architectural, not procedural: gate irreversible or high-severity automated actions behind a queue a human has the bandwidth and authority to actually work, and make the automated system's reasoning visible to that reviewer rather than just its conclusion.

// Decision gate: automated systems propose, they don't execute
// irreversible/high-severity actions directly.

type AutomatedDecision = {
  subjectId: string;
  action: "suspend" | "deactivate" | "hold_payout" | "flag_fraud";
  severity: "reversible" | "irreversible";
  modelScore: number;
  modelReasonCodes: string[];   // NOT just a score — the "why"
  proposedAt: string;
};

async function routeDecision(d: AutomatedDecision) {
  if (d.severity === "reversible" && d.modelScore < AUTO_EXECUTE_THRESHOLD) {
    // Low-stakes, reversible actions can auto-execute —
    // but still get logged and stay contestable after the fact.
    await execute(d);
    await logForAudit(d, { autoExecuted: true });
    await notifySubject(d, { contestWindowHours: 72 });
    return;
  }

  // Anything irreversible or high-severity blocks on a human
  // who sees the reasoning, not just the score, and has
  // explicit authority + a workload cap to actually decide.
  await enqueueForReview(d, {
    requiredReviewerCompetence: reviewerCompetenceFor(d.action),
    maxQueueDepthPerReviewer: MAX_MEANINGFUL_REVIEW_LOAD,
    slaHours: 24,
  });
}

The two details that make this different from most "human-in-the-loop" implementations teams already have: the queue carries modelReasonCodes, not just a score, so a reviewer can actually evaluate the case instead of ratifying a number; and maxQueueDepthPerReviewer is an enforced capacity limit, not an aspiration — if your review queue routinely exceeds what a person can meaningfully process, that's a signal to slow the auto-flagging rate or add reviewers, not a metric to quietly let slide. Pair this with an audit log that captures the reasoning behind every automated proposal (useful for both a DPIA and for responding to a contested decision) and a contest endpoint with a real SLA, not a ticket that ages out.

Who else should be reading this

Uber is a gig platform, but the mechanism generalizes to any product with an automated-consequence engine: marketplaces and payment processors auto-freezing seller/merchant accounts on fraud scores, fintech risk engines auto-declining transactions or closing accounts, content platforms auto-striking creators, HR tech auto-rejecting candidates via resume/ATS screening, insurtech auto-denying claims. None of those verticals are exempt from Article 22 just because they're not ride-hailing — the AP's ruling is a mechanism finding, not an industry-specific one. If you're also tracking the parallel UK story, note that the UK replaced Article 22 with a materially different framework via DUAA Section 80 in February 2026 — EU Article 22 is untouched, so a platform serving both jurisdictions needs two separate gating logics, not one.

The running total

This is Uber's third GDPR fine from a single 2020 complaint, and the pattern across all three is consistent: each one traces to a system design decision made years before enforcement caught up with it. €10M for not telling drivers what was happening to their data. €290M for where the data physically lived. €824.99M for a decision engine with no real human backstop. None of the three required a novel legal theory — all three were existing GDPR obligations (Article 13/14, Article 44-49, Article 22) applied to infrastructure built before anyone checked whether it complied. If your platform makes automated calls about people's access, income, or status, the AP just published the market rate for finding out the hard way that "we have human review" and "a human can actually change this outcome" are not the same sentence.