
Answering an Article 22 Complaint: "What Did Your AI Decide About Me?"
Under GDPR Article 22, a person subject to an automated decision can demand an explanation. Most organizations can't answer truthfully or quickly. Here's how a complete, verifiable record turns that dreaded request into a query.
- Katya SavenkovaDirector of Operations
In this article
It's the request every organization running AI hopes never to receive: a person, protected by GDPR Article 22, asking what an automated system decided about them and why — with a regulator ready to compel an answer. The reason it's dreaded is that most companies genuinely cannot answer, because the evidence was never captured in a form that survives the question.
What Article 22 actually asks for
Article 22 gives people rights around decisions made solely by automated processing that significantly affect them — including the ability to obtain human review and contest the outcome. (The related right to meaningful information about the logic involved comes from the GDPR's transparency and access provisions, not Article 22 itself.) In plain terms: they can ask 'what did your system decide about me, on what basis, and can you show me.' The obligation isn't to have made a perfect decision; it's to be able to account for the one you made.
Why most organizations can't answer
The answer requires reconstructing a specific past decision — the inputs, the retrieval, the model's response, the controls that applied — often months later. In an assembled stack that evidence is scattered across a chat vendor, a retrieval system, and a logging tool, none of which was designed to answer this question and none of which can be independently trusted. So the honest response becomes a scramble, and a scramble under a statutory clock is how enforcement actions start.
The problem is almost never that the decision was wrong. It's that the organization can't account for it — the record either doesn't exist or can't be trusted.
Answering from the record
When every prompt, retrieval, completion, and redaction was written to a signed, hash-chained ledger as it happened, the Article 22 answer stops being a reconstruction and becomes a retrieval. You pull every entry touching that subject and you have, in order and unaltered: what the system was asked, what it drew on, what it decided, and what safeguards applied. The story was recorded as it happened — you're reading it, not rebuilding it.
Giving the person something they can verify
Meaningful information is worth more when the recipient can check it. A signed decision receipt lets the subject — or their advisor, or the regulator — verify the account independently, offline, against a published key. That moves the interaction from 'trust our explanation' to 'here is the verifiable evidence,' which is a far stronger position to be in when someone is contesting an outcome.
The thirty-day clock becomes a lookup
Subject requests come with statutory deadlines, and the reason they cause panic is that reconstruction is slow and uncertain. A complete, queryable record collapses the timeline: the same request that would take an assembled stack a frantic multi-system reconstruction becomes, against one ledger, a scoped query returning a verifiable slice. You're not racing the clock; you're answering a question you already have the answer to.
Frequently asked questions
Turn the dreaded request into a query. See how a signed, hash-chained record lets you answer 'what did your AI decide about me' completely, verifiably, and inside the clock. Book a walkthrough.
Part of