Platform Account Suspensions in the EU: Why a Human Now Has to Make the Call

Somewhere in Europe tonight, someone will open an app and find their Platform account gone. A rating slipped under a threshold, or a cancellation rate crossed a line, and a rule fired. There is no name on the decision, because no person made it. There is no one to ask, because there is no one to ask.

On 2 December, that becomes unlawful across the EU. The Platform Work Directive says any decision to restrict, suspend or terminate someone's account or anything with the same effect has to be made by a human being. One sentence. And unlike almost everything else in the Directive, you cannot satisfy it with a policy document. It lives in your deactivation logic, which means it is a build ticket, and there are roughly fifteen weeks left to close it.

The European Commission's own summary of the rules puts it in three words: no robo-firing.

Most companies have this filed under legal. It belongs in the product backlog.

What exactly counts as a deactivation?

More than you would think, which is where this gets uncomfortable.

The rule covers restricting, suspending or terminating the account or the contractual relationship and then adds a catch-all: any other decision of equivalent detriment. That phrase carries a lot of weight.

Think about what it reaches. A shadow-throttle that quietly stops surfacing jobs to someone. A tier demotion that locks them out of the better-paying work. An indefinite hold "pending review" that never quite resolves. A refusal to pay for work already delivered, which the Directive singles out for its own explanation duty.

None of those say "suspended" anywhere in the interface. All of them stop the money.

The test is what happens to the person, not what your admin panel calls it. If a system action materially cuts off someone's ability to earn, relabelling it a pause does not move it outside the rule. It is worth walking your own product with that lens, because most platforms have three or four of these paths and think of them as separate features rather than as one category.

Three things the rule does not do, since the scope cuts both ways.

It does not push automation out of the process. Systems can still detect, score, rank, queue and recommend. What they cannot do is make the final call.

It does not require the human to get it right. It requires a human to decide. Accuracy is handled elsewhere.

It does not override national dismissal law. The Directive says so explicitly. Where you are dismissing an employee, local procedure still applies on top of this not instead of it.

Doesn't GDPR already cover this?

Many platforms think so, and that assumption is the most expensive one in this article.

GDPR Article 22 restricts decisions made solely by automated processing where they significantly affect someone. But it comes with an exception: the restriction falls away where the decision is necessary to enter into or perform a contract between the person and the platform.

That exception has been quietly holding up a lot of platform architecture. If deactivation is necessary to run the service, the argument goes, the automation is permitted. It is not an unreasonable reading, and plenty of privacy teams signed off on it.

The Platform Work Directive contains no equivalent exception for this decision. Which produces a specific and awkward result: a deactivation flow that your legal team correctly cleared under the GDPR can be unlawful under the Directive, with nothing about the flow having changed.

This was deliberate. The gap between the two instruments is the point of the provision. So a prior GDPR assessment is not a defence, and it is not a shortcut the work has to be redone against a different standard.

Does this apply to self-employed contractors?

Yes, and the shorthand circulating on this is wrong in a way that could cost someone their compliance position.

There is one carve-out nearby. The explanation, contact-person and review duties do not apply to people performing platform work who are also business users as defined in the platform-to-business regulation. Some commentary has compressed this into "contractors are excluded."

Two problems with that.

First, business user is a defined legal category, not a loose synonym for self-employed. Someone invoicing you as a freelancer is not automatically inside it.

Second, and more decisive: the carve-out attaches only to the explanation duties. The requirement that a human make the decision has no exclusion at all. So even where the explanation obligations drop away, the deactivation itself still has to be decided by a person.

If someone on your team is designing a rule that routes contractors down an automated path while employees go to a review queue, that is the design most likely to fail an inspection. The human-decision rule does not sort by contract type.

What has to happen after a human makes the call?

The decision is the requirement. Four obligations surround it, and between them they set the clocks your process has to run on.

A written statement of reasons. For any decision to restrict, suspend or terminate an account and for refusing payment for completed work the person is entitled to written reasons, without undue delay and no later than the day the decision takes effect. Read that last part carefully. The reasoning has to exist at the moment the switch flips, not be assembled later if someone pushes back.

A contact person, not an inbox. They must be able to reach a designated person to discuss the facts, circumstances and reasoning behind the decision someone with the competence, training and authority to actually do that. A support queue replying from a saved macro does not clear this bar.

A substantiated reply within two weeks. If the explanation does not satisfy them, or they believe their rights were infringed, they can request a review. Your reply must be sufficiently precise and adequately substantiated, and it must arrive within two weeks of the request.

Rectification within two weeks of the decision. Where a decision infringed someone's rights, you fix it without delay and in any case within two weeks of the decision being taken. Where fixing it is no longer possible, you owe adequate compensation. And you must take steps to stop it recurring the Directive names modifying or discontinuing the system as options.

Now put the last two side by side, because this is the detail that breaks service-level agreements.

The reply clock starts when the person asks. The rectification clock started when you made the decision. Someone who requests a review on day twelve can still be owed rectification on day fourteen. If your process treats "two weeks" as a single window running from the complaint, you will miss the deadline that actually matters.

What makes a reviewer's authority real?

There is a requirement here that is trivially easy to satisfy on paper and genuinely hard to satisfy in practice.

Staff doing oversight must have the competence, training and authority to exercise the function, expressly including authority to override automated decisions. And they cannot be dismissed or disciplined for using it.

That protection is not decorative. It exists because the failure mode is so predictable. Give a reviewer a long queue, a handling-time target, and no real power to reverse the system, and you will get rubber-stamping a human in the workflow, but not a human decision.

Here is the useful test, and you can run it on yourself: what is your override rate? If reviewers approve the system's recommendation essentially every time, that is not evidence of good automation. It is evidence that the review is ceremonial. Worth knowing that number before a regulator asks for it.

Where do you start?

Four steps, in this order.

Map every automated path to a bad outcome. Not just the deactivation endpoint. Rating thresholds, cancellation rules, fraud scores, inactivity timers, tier demotions, visibility throttles, payment holds. Describe each one by what the person experiences, not by what the feature is called internally. The list is usually longer than anyone expects.

Put a named human in each path, with a working override. Turn each automated action into a recommendation that lands in a decision queue. Then test that the reviewer can genuinely reverse the system, rather than only send it back through.

Write the reasons before you need them. Every decision type needs a template a human can complete with something real. "Account suspended for policy violation" restates the rule that fired; it is not a statement of reasons, and it will not read as one.

Wire both clocks separately. Rectification runs from the decision, reply runs from the request. Track them as two deadlines. And route outcomes back into a system-change review, because the obligation is to fix the system, not just the individual case.

Bottom line

Most of the Platform Work Directive can be met with paperwork, and paperwork moves fast. This provision cannot. It reaches into deactivation logic, admin tooling, support workflow, reason templates, and the way you staff the people who sit behind all of it.

It is also the provision most likely to be tested first, precisely because it is visible from outside the company. Anyone can look at a platform and ask a simple question: what happens when an account gets shut off at two in the morning?

If the honest answer is that a system does it and no one decides, that is a build ticket. And fifteen weeks is enough time to close it, as long as it starts being treated as one.

Get in touch with us:

Netherlands (HQ) : +31 97010207974

UK (HQ) : +44 7401131349

Belgium : +32 460254634

Follow us on:

LinkedIn : https://www.linkedin.com/company/dhi-adt/