Explainables
Govern

Consent & Data Use Transparency

user agencycognitive accessibility
User question

What data is being used and how?

Consulting signal

Surfaces when a client's privacy counsel realizes that 'users agreed to the terms' does not cover the specific AI training uses now in scope, or when users object to data uses they weren't clearly informed of.

Overview

Why this pattern exists

A user clicks "I agree" on a consent screen. It took two seconds. The document they agreed to is 4,000 words long and covers, somewhere in paragraph 18, that their interaction data may be used to improve AI models. They did not know this. They would have cared if asked.

This is the gap between legal consent and informed consent, and it is almost entirely a design problem. The information exists. The legal basis is documented. The failure is that consent interfaces are routinely designed to be accepted, not understood: fine print, pre-ticked boxes, vague language about "improving our services," buried opt-outs. The result is that users have nominally agreed to data uses they have no awareness of.

For AI systems specifically, this gap has become acute. Data used to train or fine-tune a model is a fundamentally different use from data processed to deliver a service, but most consent flows don't distinguish between them. This pattern addresses both sides: making data use genuinely legible to users, and giving them real control over the uses they care about most.

Design goal

Make personal data use visible, comprehensible, and genuinely consented to: giving users a clear understanding of what data is used in AI systems, for what purpose, and what they can do about it.

Usage guidance

When to use

  • The system processes personal data to make or influence decisions
  • Personal data is used to train or improve AI models
  • Users have GDPR or equivalent rights over their data (right of access, rectification, erasure, objection)
  • The legal basis for data processing involves consent (as opposed to contract or legitimate interest)
  • Data is used for purposes beyond the original collection context (secondary use, model training)

When not to use

  • The system does not process personal data
  • Data use is fully self-evident from the nature of the service and no disclosure is needed
  • A "consent theater" approach is the only viable option: if genuine informed consent is not achievable, reconsider whether the data use is appropriate

Design

UI primitives

to be added soon
Content Block / Card

Data use summary card

A compact, plain-language summary of what personal data is used in this system and for what purpose: - What data is used (categories, not raw fields) - Why it is used (the purpose) - Who can access it - How long it is retained - The legal basis

to be added soon
Content Block / Panel

Data rights access panel

A persistent interface for users to exercise their data rights: - View the data held about me - Correct inaccurate data - Delete my data - Object to automated processing - Download a copy of my data Each right links to the mechanism for exercising it, not just a description of the right.

to be added soon
Contextual Overlay / Notification

Data use change notification

When data use practices change, such as new purposes, new third parties, or new AI training uses, send a proactive notification to users, not just an update to terms of service.

to be added soon
Interactive Control / Toggle

Model training opt-out

A specific, visible control for whether the user's data is used to train or improve AI models. This is distinct from consent for the service itself and should be separately controllable.

How to use

Design consent flows for comprehension, not completion.

A consent screen that requires minimal interaction maximizes consent rates, but produces uninformed consent. Design for users who want to understand before they agree.

Separate service consent from data use consent.

Using someone's data to provide a service they requested is different from using their data to train a model. These are different purposes with different legal bases and should be disclosed and consented to separately.

Make data rights actionable, not just described.

"You have the right to access your data" is a legal statement. "Click here to see all data we hold about you" is a design decision that makes the right real. Every data right should link to a mechanism for exercising it.

Disclose AI-specific data uses explicitly.

General privacy notices were not written for AI use cases. Terms like "to improve our services" do not adequately describe model training on personal data. Be specific: "Your interaction data may be used to improve the AI model that generates responses."

Notify proactively when data use changes.

A buried update to a privacy policy is not meaningful notification. If AI training uses are added, extended, or changed, users who previously consented should be actively notified.

Use cases

flow a

Layered consent at onboarding

  1. 1. User creates an account for a service that uses AI.
  2. 2. Consent flow presents: brief summary of data use in plain language.
  3. 3. User can accept basic service terms and separately choose whether to opt in to AI model improvement use.
  4. 4. Controls are genuinely separate: declining model training does not affect access to the service.
  5. 5. Choices are stored and reflected in the user's data rights panel.
flow b

Exercising the right of access

  1. 1. User wants to know what data the system holds about them.
  2. 2. Data rights panel: "View my data" → user is presented with their data in a readable format.
  3. 3. User notices an incorrect attribute (wrong employment status from a third-party source).
  4. 4. User submits a correction request. Correction is applied; correction event is logged in the audit trail.
  5. 5. User is notified when the correction has been applied.
flow c

Objecting to automated processing

  1. 1. User receives an adverse automated decision and wants to object.
  2. 2. Data rights panel includes: "Object to automated processing."
  3. 3. User submits an objection.
  4. 4. Case is routed to human review as required by GDPR Article 22.
  5. 5. User receives a response within the legally required timeframe.

Design trade-offs

Informed consent vs. consent fatigue

The more detailed and layered a consent flow, the less likely users are to read it. Design for comprehension at minimum viable depth, and test whether users actually understand what they've agreed to.

Transparency vs. proprietary disclosure

Being transparent about data use may reveal details about AI system design or data sourcing that organizations consider proprietary. Weigh legitimate commercial sensitivity against the user's right to understand what happens with their data.

User control vs. system integrity

Allowing users to opt out of data use for model training may reduce the quality of the model. This trade-off is real and should be managed through system design (opt-out cohort handling, synthetic data) rather than by making opt-out difficult.

Connections

Relation to other patterns

Sources

European Union (2016). Articles 13/14 (information obligations), Article 15 (right of access), Article 17 (right of erasure), Article 21 (right to object), Article 22 (automated decision-making). The comprehensive legal framework underlying this pattern. https://gdpr-info.eu/ - Dark Patterns in the Age of the GDPR, Gray et al. (2021) — General Data Protection Regulation (GDPR)

documents how consent interfaces are routinely designed to maximize consent rates rather than informed consent: the "consent theater" problem this pattern is designed to counteract

Cavoukian (2009) — Privacy by Design

foundational framework proposing that privacy be built into systems by design rather than added as a compliance layer. Informs the proactive transparency approach of this pattern

European Union (2024) — EU AI Act, Article 13

transparency obligations for high-risk AI systems, including disclosure of the nature of the system and the data it uses to affected persons