An automation can retire before its decision record is needed
The Uber enforcement action concerns earlier account-deactivation practices. Preserve enough versioned workflow evidence to explain consequential automated decisions after the system changes.
The Dutch data-protection authority's €824.99 million Uber fine concerns automated decisions about drivers' accounts. CNIL's August 24 statement describes its cooperation in the case and the regulator's conclusion that the decisions lacked human intervention and significantly affected drivers' ability to earn.
Associated Press reports that the conduct examined ran from 2018 to 2022. Uber disputed the decision and said it would appeal.
The immediate engineering lesson is the distance between operating a system and later having to explain it. A workflow can be replaced while decisions made under its earlier version remain consequential.
Retiring the system does not answer the historical question
My rule for a consequential automation is to define its decision record before rollout, including what must remain intelligible after the implementation changes. Retention needs a lawful purpose, access limits and an appropriate schedule; this is not an instruction to keep all personal data forever.
As an illustration, suppose I am reviewing a hypothetical account-restriction workflow. A model flags an event, a policy maps the flag to an action, and an authorised person may intervene. Six months later, the model and policy are both updated.
If a decision is challenged, a screenshot of today's interface will not establish how the earlier version worked. I would want the permitted record to identify the relevant input, model or rule version, resulting action and any meaningful intervention. The organisation also needs to know who can interpret that record.
The exercise should include the appeal path. Can the reviewer retrieve the evidence needed to reconsider the decision? Can that person change the outcome? A nominal review step that cannot influence the result is a different control from one with genuine authority.
Apply the existing rule to the actual decision
The European Data Protection Board's guide explains the GDPR right concerning decisions based solely on automated processing that have legal or similarly significant effects. It also describes exceptions and conditions. Article 22 is not a blanket prohibition on every automated workflow.
That scope matters when the lesson is carried into agent design. An agent's name, architecture or benchmark score does not determine the legal analysis. The relevant team must assess the processing, the decision's effects, the role of human intervention and any applicable exception or safeguard.
I would bring a concrete workflow map to that assessment. Show where a recommendation becomes an action, who can prevent or reverse it, what the affected person is told and what evidence a later review can access. That is something engineering, operations and legal can evaluate together.
A larger model or a more accurate classifier does not remove the need to understand those boundaries. Conversely, attaching a human approval button does not establish compliance by itself. The control needs to work in the actual process and under the conditions being assessed.
Before retiring a consequential automation, run a retrieval exercise on a lawful sample of historical decisions. Ask whether an authorised reviewer can still explain what happened without relying on the original developer's memory. Fix the evidence gap while the people and systems needed to interpret it are still available.
The fine remains a contested regulatory action. Its amount should not become a universal price for omitting a review gate. Its chronology is already a useful reason to make decision records survive system changes.
Design the decision record for the day the workflow must be explained, including after that workflow has been replaced.
