From Activity Signal to Account State
The question here is not what Uber called its software, but how information about a driver moved through the platform until access to work changed. The Dutch Data Protection Authority’s account describes a lifecycle with distinct inputs, triggers, and outcomes: software tracked driving behaviour and customer reviews; suspected fraud or low ratings could lead to temporary deactivation; persistent low ratings could lead to permanent deactivation. Tracing those transitions makes the missing human checkpoint visible and gives us a precise basis for judging the significance of the account block.
A useful way to read the process is to separate an observation from the action that follows it. A customer review is an observation. A suspicion of fraud is a trigger identified by software. Deactivation is an account-state change. These are related, but they are not the same event. The legal and practical importance rises sharply at the point where the platform moves from evaluating information to deciding whether the driver can continue to accept rides.
The inputs were observations, not decisions
The AP says that Uber used software to track drivers’ driving behaviour and customer reviews between 2018 and 2022. The releases do not specify every data field or metric involved. They do not tell us how driving behaviour was measured, which review patterns counted as low, how a suspicion of fraud was generated, or whether a fixed rule, a statistical model, or a combination of tools produced the signal. We should not fill those gaps with assumptions about artificial intelligence or machine learning.
What the evidence does establish is the role assigned to the information. Driving behaviour and customer reviews were not retained as passive records only. They entered a process that could produce an account action. That distinction matters because the same piece of information can play different roles in different systems. A review may be one input into a dashboard, a prompt for a person to investigate, or a direct condition for suspending access. The reported Uber process belongs to the last, more consequential category at the point of deactivation: the software detected a stated condition and the account was automatically deactivated.
The two trigger categories also carry different meanings. A suspicion of fraud is not the same as a low customer rating. The first is a suspicion about possible misconduct; the second is an evaluation supplied through customer feedback. Neither phrase, standing alone, proves that a driver committed fraud or performed poorly. They describe the information or classification that the software used. The action that followed is a separate question: whether the platform allowed that classification to change the driver’s access without a person checking the individual circumstances.
The AP describes three relevant outcomes. A suspected fraud signal could lead to temporary deactivation. Low customer reviews could also lead to temporary deactivation. If low reviews persisted, the result could become permanent deactivation. “Temporary” and “permanent” therefore describe different account states, not merely different labels for the same event. The first interrupts platform access for a period whose length is not stated in the available release. The second ends the driver’s access on the terms described by the authority.
A state is useful because it captures what remains true after the triggering event has passed. A review may have been submitted once, and a fraud suspicion may have been generated at one moment, but a deactivated account continues to restrict access until some later transition occurs. The available evidence does not tell us what event restored a temporary account, whether restoration was automatic, or whether a driver had to ask for it. It does tell us that the account outcome persisted long enough to matter: during deactivation, the regulators say, the driver could not make rides or generate income through Uber.
The pathways must also be kept separate. The AP expressly links persistent low customer reviews to permanent deactivation, but the releases do not say that a suspected-fraud block followed the same progression. It would be an unsupported shortcut to draw one universal state machine from the existence of several triggers. A careful model keeps the branches distinct and shows only the transitions that the authority reports. That discipline matters later, because legal significance can depend on the duration, reversibility, and practical reach of a particular action.
The word “could” is important here. The sources establish the pathways the AP identified, but they do not provide a denominator: we do not know how many drivers were monitored, how many received each trigger, how many temporary blocks occurred, or how often a temporary block became permanent. We also do not know whether all deactivations followed one uniform rule. The evidence is strong about the existence and direction of the reported transitions, but not about their frequency or accuracy.
This is why a lifecycle model is more informative than a list of inputs. It shows that the same broad category of information can sit at the beginning of a chain whose endpoint is an exclusion from work. It also shows where a human decision could have entered: after the signal was produced but before the account state changed. The AP’s case-specific statement is that no human assessment occurred before these account actions.
The lifecycle contains two kinds of movement. Information moves toward a classification: behaviour and reviews are processed, and the software identifies a suspected condition. Control moves toward an account consequence: the classification is connected to whether the driver can use the platform. The first movement may be useful for detecting patterns. The second movement determines the driver’s position in the marketplace. Confusing those movements is one way a consequential decision can be made to look like ordinary analytics.
The missing checkpoint is therefore not an imagined employee who might have looked at the result in some general sense. It is a specific place in the process where a person could have examined the individual case before access changed. If no such point existed, then the software’s classification was not simply advisory. It was functionally connected to the account state. The releases do not tell us whether Uber had a later complaint or restoration process, so that later process must not be silently treated as a substitute for the missing pre-action assessment.
The diagram is deliberately modest. It does not claim that every driver began in the same state, that a temporary account was always restored, or that permanent deactivation could never be challenged. Those outcomes are not described in the available evidence. It represents only the reported direction of the process: platform access, software-detected condition, automated account action, and the possibility that persistent low ratings led to a more durable exclusion.
The diagram also makes clear why “the algorithm found something” is an incomplete description. The software may have produced a classification, but the platform attached a consequence to that classification. The driver did not merely receive a different risk value. The driver’s ability to continue using the platform changed. The state transition is the mechanism through which an internal signal became an external condition.
A trigger changed access to work
An account state is not just a technical record when access to the platform is the means by which a driver obtains rides. The CNIL says that a driver whose account is blocked can no longer make rides or generate revenue. The AP likewise says that income through Uber was lost during deactivation and describes the effect as immediate. This is the point at which the process acquires a practical dimension that cannot be captured by naming the underlying input.
Consider the difference between three possible events. First, a system might collect a low rating and store it for later review. Second, it might alert a human who decides whether the rating is reliable and whether any action is justified. Third, it might automatically deactivate the account as soon as the software detects a relevant pattern. All three involve customer-review data, but they distribute decision power differently. The AP’s description places the reported Uber deactivations in the third category because it says there was no human assessment before the account action.
A hypothetical example shows why the distinction matters. Suppose two drivers receive the same broad kind of low-rating signal. In a storage-only system, both records wait for a decision. In a review system, an assessor might examine the relevant circumstances before deciding whether access should change. In the reported automated path, the signal can move directly to temporary deactivation. If one driver later accumulates persistent low ratings, the described consequence can become permanent. The point is not to invent what happened to either driver; it is to show how the same input category can support different levels of platform control depending on where the transition is placed.
That absence is a process fact, not a claim that no employee anywhere at Uber ever interacted with a driver. The evidence does not describe the company’s entire support organization, its later complaints process, or any review that might have happened after a block. It says that the account actions themselves were made without human assessment. Keeping that timing precise matters. A later response can offer a remedy, but it does not automatically mean that a person participated in making the initial decision.
The difference between temporary and permanent deactivation reinforces the importance of timing. A temporary block can interrupt a driver’s ability to work and may create immediate financial pressure. A permanent block can alter the driver’s relationship with the platform more deeply. The source material does not give the length of temporary blocks or explain the criteria for permanence beyond the reference to persistent low ratings. Even so, the direction of the transition is clear enough to support a severity analysis: the consequence can become more durable while the initiating information remains a software-produced classification.
This is also why labels such as “flag,” “hold,” or “account status” can mislead. A flag sounds like information awaiting a decision. A hold sounds provisional. An account status sounds administrative. But a label cannot determine what the process does. If the status removes the ability to accept rides, the platform has exercised control over a material opportunity. The name may describe the interface; it does not erase the effect.
The same distinction helps us avoid the opposite error. It would be too strong to infer from the releases alone that every rating was wrong, every fraud suspicion was baseless, or every deactivation caused the same loss. The evidence does not establish those propositions. Nor does it establish the software’s precision, the rate of false positives, or the distribution of consequences among different groups of drivers. We know the mechanism as the regulators describe it, not the full performance record of the mechanism.
What additional evidence would change the analysis? System documentation could show the exact trigger conditions and whether the process used simple rules, statistical scoring, or several stages. Operational logs could show how often signals produced temporary or permanent deactivation. Error analysis could reveal whether the system frequently confused unusual but legitimate behaviour with fraud. Driver notices could show what people were told and when. Records of challenges and reversals could show whether any later process corrected the initial action. Evidence about the timing and authority of review would clarify whether human intervention was preventive, remedial, or absent altogether.
Those are not requests for technical detail for its own sake. Each would answer a different question about the lifecycle. Trigger documentation would clarify how the system classified information. Logs would establish frequency rather than leaving us with a few named pathways. Error records would test accuracy and fairness. Notices would illuminate transparency. Review records would show whether drivers had a meaningful route to contest the state change. Without them, it is important to distinguish “the sources do not tell us” from “the system did not have this feature.”
There is also a time boundary in the evidence. The AP describes the relevant use of software as occurring between 2018 and 2022, while its public announcement came in 2026. The announcement says Uber has stopped the violations, but it does not provide a technical account of any current system. We can therefore describe the reported historical lifecycle and the authority’s present procedural statement; we should not assume that the same triggers, states, or review arrangements still operate today.
The strongest conclusion available at this stage is therefore about the location of power. Uber’s software was reported to monitor driver-related information and to produce conditions that automatically changed account access. The AP says no human assessment occurred before the relevant account actions. The CNIL and AP connect those actions to the loss of rides and platform income. That is enough to treat the transition from signal to account state as the central event, even while the internal thresholds and error patterns remain unknown.
Once the lifecycle is visible, the next question can be stated without ambiguity. Does this automated state change satisfy the legal conditions for an Article 22 decision? Answering that requires more than repeating that an algorithm was used. It requires testing whether there was a decision, whether automation was exclusive, and whether the consequence legally or significantly affected the driver. The account-state model supplies the facts that those questions must be applied to.