Module 5: GDPR for AI Systems
Granular consent for AI processing
Description
Consent is the area where most sites fail GDPR. The "accept all" cookie banner that most implement is not valid consent under a strict reading of GDPR. For AI processing, the requirements are even more specific: consent must be informed (they know what they're consenting to), granular (separate from base consent), and revocable.
This capsule teaches you to design consent that's legally defensible and good for UX.
By the end you'll be able to:
- Identify the 4 requirements of valid consent
- Design granular consent for AI processing (separate from base consent)
- Implement a functional revocation mechanism
- Distinguish consent (Art. 6(1)(a)) from legitimate interest (Art. 6(1)(f))
The 4 requirements of valid consent (GDPR Art. 4(11))
- Freely given: the user has a real choice. If not accepting = no service, it isn't freely given.
- Specific: for specific purposes. Catch-all consent doesn't count.
- Informed: the user understands what they're consenting to.
- Unambiguous: a clear affirmative action. Pre-checked boxes do NOT count.
For AI specifically, add:
- Granular: consent for AI separate from other processing
- Revocable: as easy to withdraw as it was to give
The problem with typical consent banners
"This site uses cookies. [Accept all]"
[Reject all]
[Configure]
The problems:
- If "configure" takes 10 clicks vs. 1 click for "accept all" → not freely given
- "Accept all" covers marketing + analytics + ad personalization + AI → not specific
- Users click accept without reading → not informed
For AI, it's worse:
- "Your data may be used to improve our services" → vague, doesn't mention AI specifically
- It doesn't mention that the data feeds ML models
- It doesn't mention profile inference, predictions, etc.
Designing consent for AI
Pattern A: Layered consent
Bottom layer (cookie banner):
"We use cookies and process data. For detailed settings, click here."
Click → Modal layer:
┌─────────────────────────────────────────────────────────────┐
│ How do we use your data? │
│ │
│ [✓] Functional (required) — login, cart, security │
│ [ ] Analytics — understanding product usage │
│ [ ] Marketing — personalizing offers │
│ [ ] AI processing — using your data to improve our AI │
│ models and personalize responses. [More info] │
│ │
│ [Accept selection] [Accept all] │
└─────────────────────────────────────────────────────────────┘
Click "More info" →
"AI processing means your data (interactions, queries,
feedback) may:
- Feed the training of our models
- Generate usage profiles for personalization
- Influence future recommendations
This does not include [list of specific exclusions]"
Why it works:
- Granular (each purpose is separate)
- Informed (explicit explanations)
- Specific (each checkbox = specific consent)
- Freely given (every toggle works independently)
Pattern B: Just-in-time consent
Instead of an upfront banner, you ask for consent when the feature is activated:
User trying to use the "AI suggestions" feature for the first time:
┌─────────────────────────────────────────────────────────────┐
│ Enable AI Suggestions │
│ │
│ To suggest relevant products to you, we need to: │
│ - Analyze your purchase history │
│ - Process your preferences with AI │
│ │
│ Your data is NOT shared with third parties. You can turn │
│ this feature off at any time from Settings. │
│ │
│ [Enable] [No, thanks] │
└─────────────────────────────────────────────────────────────┘
Better UX: the user understands why they're giving consent at the exact moment.
Revocation: as easy as giving consent
Settings > Privacy:
AI personalization [ON ] Turn off →
Analytics tracking [ON ] Turn off →
Marketing communications [OFF] Turn on →
Details:
- AI personalization enabled on 2024-01-15
- Last model update with your data: 2024-03-10
- If you turn it off: future data will NOT be processed. Your past data
remains in aggregated datasets (not individually identifiable).
[Request full deletion of my data]
Important: revocation must effectively stop future processing. If users turn AI off and it keeps processing, that's a violation.
Consent vs. Legitimate Interest
GDPR Art. 6 lists 6 legal bases for processing. The two most relevant to AI:
Consent (Art. 6(1)(a))
When to use it:
- Optional or discretionary processing
- Personalized marketing, optional AI features
Pros:
- Defensible if well implemented
- Gives the user control
Cons:
- Revocable at any time
- You have to stop processing on revocation
- A high compliance burden
Legitimate Interest (Art. 6(1)(f))
When to use it:
- Processing that is necessary and proportionate for your business
- Fraud detection, security, internal analytics
It requires:
- A documented balancing test: your legitimate interest vs. the data subject's rights
- A right to object on the user's part
- Clear notification in the privacy policy
Pros:
- Not trivially revocable
- More stable for operations
Cons:
- Greater regulatory scrutiny if abused
- Suspected of being biased toward bigger-company interests
The decision framework
| Your processing is... | Likely legal basis |
|---|---|
| Core service (login, payments) | Contract necessity (Art. 6(1)(b)) |
| Required by law (KYC) | Legal obligation (Art. 6(1)(c)) |
| Fraud detection, security | Legitimate interest |
| Aggregated internal analytics | Legitimate interest |
| Marketing personalization | Consent |
| AI-driven recommendations (optional) | Consent |
| AI training on user data | Consent (preferable) or LI (defensible if the balancing test passes) |
| Profile inference for ads | Consent |
Consent revocation: the technical flow
# 1. User clicks "revoke AI consent"
def revoke_ai_consent(user_id):
# Update consent record
db.update_consent(user_id, "ai_processing", granted=False, revoked_at=now())
# Stop future AI processing
cache.invalidate(f"user_consent:{user_id}")
# Optional: trigger downstream cleanup
queue.publish("consent_revoked", {"user_id": user_id, "scope": "ai_processing"})
# 2. Each AI inference checks consent
async def ai_recommendation(user_id, context):
consent = await get_consent(user_id, "ai_processing")
if not consent.granted:
# Use non-personalized fallback
return generic_recommendations(context)
# Personalized
return personalized_recommendations(user_id, context)
# 3. Async cleanup
@subscribe("consent_revoked")
def cleanup_ai_data(event):
user_id = event["user_id"]
# Don't delete (it might be needed for legal reasons). Mark as "no further processing"
db.execute(
"UPDATE user_data SET ai_processing_allowed = false WHERE user_id = ?",
(user_id,)
)An important trade-off: revocation usually means "stop future processing," not "delete past results." Past results in the training data still exist.
Common traps
Trap 1 — Consent buried in the T&Cs. The user checks "I accept the terms" → "that implies consent to AI processing." NOT VALID. Consent must be specific and separate.
Trap 2 — Pre-checked boxes. Checked by default = no unambiguous action. It must be explicitly checked by the user.
Trap 3 — Revocation that doesn't work. The user turns it off, the system keeps processing. A critical legal bug. Test the revocation flow routinely.
Trap 4 — The cookie banner as an excuse. "You accepted cookies, that covers AI." No. Cookies and AI processing are distinct scopes. Specific consent is required.
Trap 5 — Dark patterns in the consent UX. "Accept" is big and prominent. "Configure" is tiny and hidden. NOT freely given.
Trap 6 — No consent record. The user claims they never consented. Your DB has no record. With no evidence, you can't defend yourself. Log consent grants/revokes with a timestamp + IP + the version of the consent text.
Exercise
Your product: a productivity app with AI features (smart suggestions, auto-complete, sentiment analysis on emails). Design the consent flow:
- Which features require specific consent? Which fall under legitimate interest?
- Design the initial consent (when, format)
- Design the revocation flow
- What do you log as evidence?
See the solution
-
By feature:
- Login/payments: contract necessity (no consent)
- Smart suggestions on the user's own data: consent (AI processing of personal data)
- Auto-complete on the user's own typing: consent (AI processing)
- Sentiment analysis on emails: EXPLICIT consent (sensitive)
- Fraud detection (internal): legitimate interest
- Aggregated usage analytics: legitimate interest
-
Initial consent — just-in-time:
- On first use of each AI feature, a modal explains:
- What the feature does
- What data it processes
- Whether the data stays internal or leaves
- The option to "activate" or "no thanks"
- A persistent indicator (an icon in the UI) showing "AI active" with a toggle to disable
- On first use of each AI feature, a modal explains:
-
Revocation:
- Settings → Privacy → AI Features with toggles
- Each toggle: feature name + status + last activated date
- "Deactivate" → a confirmation modal explaining what stops
- "Delete all my AI data" → a separate option with stronger confirmation
-
Evidence logging:
{ "user_id": tokenized, "consent_record_id": uuid, "feature": "smart_suggestions", "action": "granted", "timestamp": "2026-05-11T15:30:00Z", "consent_text_version": "v3.2", "consent_text_hash": "abc123...", # to prove the text shown "ip_address": hashed, # for security; hashed for privacy "user_agent": "Mozilla/...", }
Summary
You learned:
- ✅ The 4 requirements of valid consent (freely given, specific, informed, unambiguous)
- ✅ Layered and just-in-time consent patterns
- ✅ Revocation as easy as granting
- ✅ Consent vs. Legitimate Interest (when to use each)
- ✅ The technical implementation of revocation
- ✅ The traps: dark patterns, pre-checked boxes, no records
Checkpoint: if your consent flow could be defended in an audit, you're ready.
Next capsule
06 — Legitimate Interest vs Consent. We go deeper into choosing a legal basis, with the balancing test and concrete cases.
Resources
- GDPR Art. 6 — Lawfulness of processing.
- EDPB Guidelines on consent.
- ICO consent guidance.
- Dark patterns and GDPR — examples of violations.