AI user consent audit
If you rely on consent to process personal data through AI systems, that consent has to clear a high bar. The GDPR requires it to be freely given, specific, informed, and unambiguous, with withdrawal as easy as opting in — and you must be able to prove it. This tool walks you through the conditions for valid consent, scores each one based on how your flow actually behaves, and produces a report that flags exactly where you fall short.
Is consent even the right legal basis?
Before auditing your consent flow, it is worth confirming that consent is the correct lawful basis for the processing in question. GDPR Article 6 provides six lawful bases; consent is just one. For many AI processing activities, a different basis may be more appropriate and more robust:
- Contractual necessity — if processing is required to deliver a service the user requested, this is often cleaner than relying on consent.
- Legitimate interests — possible for some AI processing, but requires a balancing test and is not available for special-category data.
- Legal obligation — relevant where processing is required by law.
Consent is the strongest basis when it is truly voluntary and when the user has genuine choice. But it is also the weakest in the sense that it can be withdrawn at any time, which means your processing must stop. If the processing is integral to the service and cannot practically stop when consent is withdrawn, consent is the wrong basis — and relying on it creates an unresolvable contradiction.
How it works
You answer a focused checklist covering five dimensions: granularity (separate choices per purpose), clarity (plain-language, no pre-ticked boxes), freely-given nature (no service conditioned on unnecessary consent), the withdrawal mechanism (as easy as opting in), and documentation (records you can produce on demand). Each answer is scored, weak areas are flagged with specific remediation notes, and you get an overall rating. The audit is entirely local — nothing you enter leaves the browser.
The five dimensions in detail
Granularity — separate purposes need separate consent requests. You cannot bundle “use your data to deliver this service” with “use your data to train our AI model” in a single checkbox. Bundled purposes fail the specificity test and are routinely challenged by data protection authorities.
Clarity — the consent request must be in plain language, separate from other terms, and visually prominent. Buried consent buried in a privacy policy, or phrased in legal jargon, is unlikely to be genuinely informed.
Freely given — if consent is a precondition for access to a service that could be provided without that processing, it is not freely given. This dimension is the most commonly contested in enforcement; conditioning service access on consent to model training is a particularly frequent issue.
Withdrawal mechanism — Article 7(3) requires withdrawal to be as easy as giving consent. A one-click opt-in with a multi-step email process to opt out fails this test clearly. The audit checks your actual withdrawal path, not your intention.
Documentation — you must be able to demonstrate that consent was obtained, when it was obtained, what was explained, and which version of the consent text was in place. This is a record-keeping obligation that lives in your system, not in a verbal claim.
Tips and notes
- Unbundle your purposes. A single “I agree” for service delivery and model training is the most common failure — split them.
- Kill pre-ticked boxes. Silence, inactivity, or a pre-checked box is not valid consent; require a clear affirmative action.
- Make opt-out symmetric. If opting in is one click, opting out must be too.
- Keep records. You must be able to demonstrate when, how, and to what each user consented — re-run this audit after any flow change.
- Re-audit when the flow changes. A consent collected under one set of terms does not cover new purposes added later. Each new use case needs a fresh consent if consent is the basis you are relying on.