Compliance · Sep 1, 2026 · 9 min read

GDPR Article 22 and bot detection: when a block is an automated decision

Article 22 GDPR restricts decisions based solely on automated processing that produce legal or similarly significant effects. A bot block on a checkout can be one. What that means for your vendor choice and your DPIA.

Chris Taylor

Prosopo

A recurring question from data protection officers: the bot vendor's documentation says decisions come back as a score between zero and one, so how does the organisation explain a blocked purchase to the customer who made it?

It is a question few vendors in this market answer directly. This page sets out what Article 22 requires, where a bot block falls within it, and what to ask a vendor. None of it is legal advice and you should take your own.

What Article 22 says

Article 22(1) of the UK and EU GDPR:

The data subject shall have 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.

Two conditions have to be met before the article bites. The decision has to be solely automated, and it has to produce a legal or similarly significant effect.

Where the processing is nonetheless permitted, for example because it is necessary for a contract or has explicit consent, Article 22(3) requires safeguards: at minimum the right to obtain human intervention, to express a point of view, and to contest the decision. Articles 13 to 15 separately require the controller to provide meaningful information about the logic involved.

Does a bot block meet the test?

Solely automated is usually satisfied without much argument. A bot verdict is produced by software in milliseconds. There is no human in the loop, and at that speed there could not be.

Legal or similarly significant effect depends on the deployment, and the position runs along a spectrum.

At the low end, a challenge on a newsletter signup form. Low impact, easily retried, hard to argue as significant.

In the middle, a challenge on a checkout. The person can proceed by solving it, unless they cannot, which brings the accessibility question into the same analysis.

At the high end, an outright block on a purchase, a rejected account registration, or an account lockout. Denying someone access to a service they are entitled to use, or preventing a transaction, is where a case for significant effect becomes reasonable. Regulators have taken an expansive view of what counts as significant in adjacent contexts, and the direction of travel has not been toward narrowing it.

The practical consequence is that the answer differs per endpoint. Most organisations have not asked the question per endpoint, and a DPIA stalls at exactly that point.

The part your vendor determines

You can build the human-review process yourself. You can write the privacy notice yourself. What you cannot do yourself is produce meaningful information about the logic involved, if your vendor does not give you any.

So the transparency of the verdict becomes a compliance question, not only an operational one.

If the output of your bot platform is a score of 0.3, then the meaningful information about the logic available to you is that a proprietary model scored the request 0.3. You can explain the process in the abstract, as most privacy notices do. You cannot explain the individual decision, because you do not know what caused it either.

Forrester's Q2 2026 Wave documents the state of this across the market. CHEQ was marked down for numeric reason codes that customers find difficult to interpret. Google reCAPTCHA Enterprise was marked down for lack of detail and limited drill-down for intent and explainability. Arkose customers asked for more self-service configuration. If the vendor's own customers cannot interpret the output, the data subject has no chance.

What a defensible answer looks like

The questions to work through, in order:

Can you identify the individual decision? Given a customer complaint with a timestamp, can you find the specific request and its verdict? If your platform does not correlate by request ID, this is where the process stops.

Can you say what caused it? Not what the system does in general. What matched, on that request.

Can a human review and overturn it? Someone with the authority and the tooling to look at the event and let the person through.

Can the person contest it? A route that does not require them to know the word CAPTCHA.

Have you recorded the assessment? A DPIA covering which endpoints have automated blocking, what effect a block has at each, and what safeguards apply.

How Prosopo handles this

Prosopo was built this way for operational reasons rather than legal ones. The compliance argument came afterwards, and the two align.

Every Prosopo block returns the reason it was stopped. Not a band, not a label. The literal string, for example Solver service detected, Header signature not emitted by real browsers, or Inconsistent hardware readings for device. Every response carries an X-Prosopo-Request-Id correlation header, so a support agent handed a complaint can retrieve the exact event.

Where a block came from a rule your own team wrote, the traceability is stronger again, because the decision is attributable to a documented human-authored policy rather than to a model output alone.

Compliance is a property of your process rather than of a vendor's feature list, so no platform can deliver it on its own. What a platform can do is make the explanation step straightforward, by returning the reason rather than a number.

Questions to ask any vendor

Take these into a demo, including ours.

Show me a blocked request from last week and tell me exactly what caused it.
What does a support agent see, and how do they find it from a customer complaint?
Can a human overturn a specific verdict, and is that recorded?
Can I export the underlying events to my own systems, so my retention and my records are mine?
If the detection model changes, will I know, and will past decisions still be explainable?

DPO asking questions about your bot vendor?

If you need to document how blocking decisions are made and explained, tell us what you run. We will show you what our verdict output looks like so you can judge whether it answers the question.

Frequently Asked Questions

What is GDPR Article 22?

Article 22 of the UK and EU GDPR gives a person the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning them or similarly significantly affects them. Where such processing is permitted, the controller must implement suitable safeguards including at least the right to obtain human intervention, to express a point of view and to contest the decision.

Does Article 22 apply to CAPTCHA and bot detection?

It can. Article 22 turns on two things: whether the decision is solely automated, and whether it produces a legal or similarly significant effect. A bot verdict is normally solely automated. Whether the effect is significant depends on what the block prevents. Refusing a purchase, rejecting an account registration or locking someone out of an account is a stronger case than adding a challenge to a contact form. Take advice on your own deployment; this page is not legal advice.

How do you make bot detection Article 22 compliant?

The practical requirements are that you can identify when an individual was subject to an automated decision, explain the logic involved in a meaningful way, provide a route to human review, and let the person contest the outcome. That is largely an operational and record-keeping problem. It becomes much harder if your vendor returns only a risk score, because a score cannot be explained meaningfully to the person it affected.

Is a risk score enough to satisfy Article 22 transparency?

A number on its own is difficult to defend as meaningful information about the logic involved. Forrester's Q2 2026 Wave marks CHEQ down for numeric reason codes that are difficult to interpret and Google reCAPTCHA Enterprise for lack of detail and limited drill-down. If your own team cannot interpret the output, you will struggle to explain it to a data subject or a regulator.

Does a challenge count as a decision under Article 22?

Serving a challenge is generally a lower-impact intervention than a block, because the person can still proceed by completing it. That said, if the challenge is one a particular person cannot complete, for example an image challenge shown to a blind user, then in practice it functions as a refusal for that person. That is one reason accessibility and Article 22 are related questions rather than separate ones.