Uber fined 825 million euros for automatically banning drivers

Between 2018 and 2022, software at Uber watched how its drivers drove and what passengers rated them. When it read a pattern as fraud, or a rating as too low, it switched the driver's account off. Temporarily at first, and permanently once the low ratings persisted. No person looked at the case before the account went dark, and the driver's income through Uber stopped that day.

On 21 August 2026 the Dutch data protection authority, the Autoriteit Persoonsgegevens (AP), fined Uber 824,990,000 euros for it 1. The AP made two findings: that Uber had broken the GDPR's ban on fully automated decision-making, and, separately, that it had not told drivers enough about the automated decisions being made about them. Uber has stopped the practice and has appealed the fine 1.

It is an interesting case because the mechanism is so ordinary. A score crosses a threshold, a job runs, a flag flips on an account. Most products contain one already: a fraud score that freezes a payout, an abuse detector that suspends an account, a trust threshold that stops a seller from listing. Teams ship those as a few lines in a worker and never file them under law. If an app can take something away from a person without anyone approving it, the company behind it can be fined for not putting a human in the loop. Three exceptions exist, and they are narrow.

Which GDPR rule did Uber break?

Article 22 of the GDPR is written about decisions, not about industries. It gives every person 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" 2. Nothing in it is specific to drivers, platforms or employment.

Two conditions have to be true together.

The decision has to be solely automated, meaning no meaningful human involvement in reaching it. And it has to produce legal effects or similarly significant ones. A legal effect is something that changes a person's legal position, such as cancelling their contract or denying them a benefit they are entitled to 3. The second limb is broader and vaguer, and the guidance that fills it in is endorsed by the European Data Protection Board (EDPB), where the EU's national privacy regulators agree common positions. It sets the bar at effects "sufficiently great or important to be worthy of attention": decisions that significantly affect someone's circumstances, behaviour or choices, that have a prolonged or permanent impact, or that exclude them 3. Named examples include decisions affecting someone's financial circumstances or denying them an employment opportunity.

One more limit before the examples, and it decides which accounts the rule reaches. Article 22 gives the right to a data subject, a natural person 2. A decision about an account held by a company is a decision about a legal person, so the GDPR route into it is indirect at best.

That is a filter, not an exemption. Most products hold more accounts belonging to a person than the pitch deck suggests: self-serve signups under someone's own name, sole traders and one-person companies on paid plans, consultants invited into a customer's workspace. Suspension logic rarely tells them apart, so the worker that pauses a company account also switches off individuals. Those are the ones Article 22 reaches.

Here is where a normal product tends to land. The middle of this range is genuinely unsettled:

• Usually inside. Cutting off someone's income or their access to a service they depend on. Deactivating a driver, courier or freelancer. Freezing a seller's payouts. Locking a solo consultant out of the workspace their client work lives in. The sources' own examples run to credit, employment, health and education 2 3, so the question is whether a given decision sits alongside those.
• Usually outside. Declining one card payment. Rate-limiting an API key. Ranking a feed.
• Argue it properly. Suspending an ordinary paid account, downgrading a plan, withholding a single payout. Two questions move this one: can the person still earn and still get their data out while it lasts, and does it end by itself or only when someone at the company acts? A reversible restriction with a working export is a long way from a permanent lockout.

Whether the product calls it a restriction, a hold or a ban does not change the analysis, and neither does whether the account is free or paid.

When is a decision "solely" automated?

When no human with real authority weighed it. The guidance is direct about the standard: oversight has to be "meaningful, rather than just a token gesture", carried out by someone "who has the authority and competence to change the decision", who considers all the relevant data 3.

That rules out the pattern most teams actually build. A support agent who sees a flagged account in a queue, has no way to see why it was flagged, and whose only realistic option is to confirm the system's call is not human involvement in the sense Article 22 means. The Future of Privacy Forum's 2022 analysis of more than 70 automated-decision cases from courts and regulators found enforcers looking past the org chart at reporting lines and whether staff were trained to use the discretion they nominally had.

There is a second trap, and it catches teams who think they are safe because a person makes the final call. If a model outputs "high risk" and the reviewer approves 95% of what it flags, the model is deciding and the review is recording that. The Court of Justice of the European Union, whose reading of the GDPR binds every regulator in the EU, has said as much. In the SCHUFA case, about a German credit bureau selling scores to lenders, it held that the score is itself an automated individual decision, prohibited in principle, when the lenders receiving it give it "a determining role" in whether they grant credit 4.

What makes an automated decision lawful?

Article 22(1) is a prohibition rather than a right the person has to invoke, which is how both the guidance 3 and the Court 4 read it. So the question is never whether anyone complained. Three exceptions let a decision stay automated 2:

1. It is necessary for entering into or performing a contract with the person.
2. It is authorised by Union or Member State law that also lays down safeguards.
3. It is based on the person's explicit consent.

Route 2 is where fraud monitoring can land. Recital 71, part of the GDPR's explanatory preamble rather than its binding articles, names fraud and tax-evasion prevention as processing that law may expressly authorise 2. That needs a real legal basis in the company's jurisdiction, though, not a general sense that stopping fraud is a good idea.

Route 1 is the one most companies reach for, and necessity is read narrowly. The controller has to show the automation is necessary "taking into account whether a less privacy-intrusive method could be adopted", and if effective, less intrusive means exist to reach the same goal, it is not necessary 3. Volume is the argument that works: the guidance's own example is an employer with tens of thousands of applications who cannot practically sift them by hand 3. If the queue is forty flagged accounts a week, a person could work through it, and that argument is not available.

Clearing the exception does not end it. Under routes 1 and 3 the company still owes safeguards, and Article 22(3) names the minimum: the right to obtain human intervention, to express a point of view, and to contest the decision 2. In product terms, a route back to someone who can reverse the call, reachable by a user locked out of the account they would normally use to contact the company.

What has to be in the privacy policy?

Three specific things, and Article 13(2)(f) asks for all of them when the data is collected: that automated decision-making exists, "meaningful information about the logic involved", and "the significance and the envisaged consequences of such processing" for the person 2.

That is separate from what the company owes one individual who asks. Article 15(1)(h) repeats the same three items as a right of access 2, and the case law that fills in "meaningful" is access-side. In February 2025, in a case about an Austrian woman refused a 10 euro per month phone contract on an automated credit assessment, the Court of Justice held that the controller must describe the procedure and principles actually applied so the person can understand which of their data was used and how 5. The Court added a practical test: it may be appropriate to tell them how far a variation in their data would have led to a different result. Sending the algorithm does not count, because it is not a concise and intelligible explanation 5.

That counterfactual is a per-person answer, so it belongs in the reply to the person who asks. The policy carries the general version: which decisions are automated, what drives them, and what happens to the person as a result.

Either way, "we may use automated processing" tells the reader nothing about the logic, the significance or the consequences. The AP's second finding against Uber was that it "did not sufficiently inform drivers about automatic decision-making" 1. The press release names no provisions, so the mapping onto Articles 13(2)(f) and 15(1)(h) is mine, not the AP's. Transparency is also where enforcement attention is pointed: the EDPB's 2026 coordinated enforcement action put 25 national regulators onto the transparency duties for 2026, contacting controllers to check what they tell people.

What should you check in your own product?

If you build or run a product that can do this, here is what you can do. Start from the code. Your published policy is downstream of what the software does, so rewriting it before you have read the software produces a better-worded guess.

1. Find every path that can take something away from a user without a person approving it. Grep for the suspension, ban, freeze, hold, reject and downgrade calls, then follow what triggers them. Include the ones your vendors run for you: Stripe Radar's risk controls block the payments it scores as highest-risk and send elevated ones to review, and your own thresholds sit on top.
2. For each one, answer the two Article 22 questions. Is a person meaningfully in the loop, with the authority and the context to overturn it? And what does the user lose, for how long? Concluding that an automation falls outside Article 22 is a legitimate outcome, and like a decision that a feature needs no DPIA, worth writing down while you still remember why.
3. For the ones inside, name the exception before you touch the policy. If you cannot point to one of the three, the automation stops or gets a person in it. If you can, build the safeguards: somebody who can reverse the call, reachable by a user who is locked out.
4. Then write what the policy owes. The decision, the logic in terms a user can follow, and what happens to them as a result.

This decays because step 1 changes every sprint. Somebody tightens a fraud threshold, adds an auto-ban for a new abuse pattern, or lets a model score signups, and the published document quietly stops describing the product, the same way it does when an LLM starts making calls inside a feature. Nobody files those as legal work, because at the time they are a pull request with a sensible title.

Lawcel is the tool we built to close that loop. It reads the pull requests and tickets your team already writes, works out which of your published legal documents each change affects, and proposes the edit for your team to approve and publish. Automated decisions are one of the cases it checks for by name: when a change introduces one and your policy covers the subject nowhere, it proposes a whole new section rather than a corrected sentence. So the threshold that starts suspending accounts on its own reaches you while it is still a code review.