A driver opens the app before a shift and finds the account blocked. The system has already judged the case. There is no person in the decision path, yet the driver cannot work until someone changes the result.
That is the operational problem behind the Uber automated-decision fine announced this week. On August 21, 2026, the Dutch data-protection authority imposed a €824,990,000 penalty on Uber B.V. and Uber Technologies Inc. for automated individual decisions concerning drivers. France’s CNIL, which worked with the Dutch authority, published its English summary on August 24.
The amount will get the attention. Builders should study the reason. The regulator focused on account deactivations for suspected fraud and low customer ratings where it found a complete absence of human intervention. Those actions could stop a driver taking rides and earning income.
Uber says it will appeal, according to Reuters reporting republished by Euronext. The fine is a regulatory decision, not the final word from the courts. That distinction belongs in every headline and every product meeting about the case.
The complaint began with more than 170 drivers
In 2020, the French human-rights association Ligue des droits de l’Homme filed a collective complaint with the CNIL on behalf of more than 170 Uber drivers. The complaint was expanded in 2021. It covered information rights, international data transfers, and temporary or permanent disconnections from the platform.
Because Uber’s main European establishment is in the Netherlands, the Dutch authority led the GDPR investigation through the one-stop-shop process. The CNIL says it participated in the checks, evidence analysis, and review of the draft decision.
This case follows two earlier Uber penalties cited by the CNIL: €10 million in 2023 over information provided to drivers and €290 million in 2024 over transfers of personal data outside the European Union. The new decision addresses a different question. Who, or what, actually decided that a driver should lose access to work?
A person outside the workflow does not make the decision human
Article 22 of the GDPR concerns decisions based solely on automated processing when they produce legal effects or similarly significant effects. The CNIL’s summary says the Dutch authority considered the cited deactivations fully automated because there was no human intervention in the decision-making process.
That wording exposes a common product mistake. A company can employ reviewers, support staff, and trust-and-safety specialists while the consequential decision itself remains automated. If the account is blocked first and a person can only send a canned explanation later, the human may be handling the aftermath rather than reviewing the decision.
The issue is not that software helped screen fraud signals or ratings. It is whether a person with enough context and authority evaluated the individual case before, or through a legally sufficient exception after, a decision that significantly affected the driver. The exact legal analysis depends on the facts and jurisdiction, so teams should involve qualified counsel. The system design questions are much easier to see.
The human-review test has six moving parts
| Control | Weak implementation | Useful implementation |
|---|---|---|
| Evidence | Reviewer sees only the model score | Reviewer sees source events, uncertainty, contradictions, and relevant history |
| Authority | Reviewer can add a note | Reviewer can pause, reverse, or narrow the action |
| Timing | Review begins after an open-ended support queue | High-impact cases have a measured response window and interim protection |
| Independence | The same automated rule supplies the decision and explanation | Reviewer can challenge the rule and request new evidence |
| Explanation | Generic policy language | Specific reason, evidence category, next step, and contest route |
| Auditability | Only the final status is stored | Inputs, model/rule version, reviewer action, timestamps, and outcome are recorded |
I would add one more practical requirement: a human review queue needs capacity. A policy that promises review but routinely leaves people locked out for weeks is not a functioning control. Track the oldest unresolved case, median and 95th-percentile response time, reversal rate, repeat appeal rate, and the income or service access held during review.
Our article about a YouTube detector flagging original animation shows the same product failure at a different scale: a false positive becomes much more damaging when the affected person cannot reach a reviewer who can inspect the original evidence.
Ratings and fraud signals need different treatment
The CNIL summary identifies two kinds of triggers: suspected fraud and low customer ratings. They should not be collapsed into one risk score. Fraud evidence may involve identity, payment, location, or account-security signals. Ratings carry customer subjectivity, bias, retaliation, and context that a score cannot recover on its own.
A useful review interface should therefore show why each signal exists and what could contradict it. A low rating after a disputed fare is different from a sustained pattern. An unusual login after a phone replacement is different from an account takeover. Reviewers need the original events and the driver’s response, not a confidence number dressed up as a reason.
This is where closed-loop AI decisions become dangerous. In our earlier story, Claude’s forecast became an order because the organization fed the model’s output back into the decision without an independent reality check. Account enforcement can create the same loop when the score triggers a block, the block becomes evidence of risk, and the appeal system sees only the score.
Build the contest path before the model ships
- Inventory consequential outcomes. Include account closure, work suspension, credit, insurance, benefits, moderation, pricing, and access to essential services.
- Separate recommendation from enforcement. A risk score can route a case without automatically applying the final penalty.
- Define the reviewer role. Specify what evidence is visible, what actions are allowed, and when a second reviewer is required.
- Protect the person during review. Use narrower temporary restrictions when a complete lockout would create disproportionate harm.
- Give a reason that can be contested. Name the evidence category and the correction path without exposing security-sensitive detection details.
- Test reversals. Seed known false positives and confirm the reviewer can restore access, correct downstream records, and prevent the same stale flag from firing again.
The last step is routinely missed. Reversing the visible account status is not enough if the risk flag survives in another service and blocks the next transaction. An appeal must repair the decision’s effects, not merely close the support ticket.
My verdict: review is a product, not a policy sentence
The size of this fine will be argued through an appeal. The engineering lesson does not need to wait. When software can remove someone’s income or access, the human-review path deserves the same product work as the automated decision.
A named reviewer, a visible queue, authority to change the result, a response-time target, and a complete repair trail are concrete controls. “A human can be contacted” is not.
Read the official record
- Read the CNIL’s English summary of the Uber decision.
- Follow the Dutch data-protection authority’s news record.
- Review the GDPR text, including Article 22.
- Read the Reuters report on Uber’s planned appeal.
Could the person reviewing your automated decision see enough evidence to disagree with it?
Checked August 24, 2026. The fine, complaint history, deactivation triggers, and absence of human intervention come from the CNIL and Dutch authority record. Uber’s appeal plan is attributed to Reuters. This article explains product controls and is not legal advice.
