Phase 3: Data Strategy for AI Products · 45 min · GDPR.eu · CCPA (California OAG) · Python

Privacy, Consent & Data Governance for AI

You can delete a row from a database. You cannot delete a fact from a trained model's weights.

Hiring signal: The hiring-signal research behind this course is explicit: an AI PM needs to 'understand GDPR/CCPA well enough to flag training-data risk before legal has to kill a launch.' That's a narrower, more practical bar than compliance-officer-level expertise — it's the ability to spot a provenance or consent gap during feature scoping, months before a launch date, rather than discovering it during a legal review the week of ship.

What you will learn

Explain the GDPR basics an AI PM needs: lawful basis for processing, data subject rights, and why 'right to erasure' is complicated by model weights
Explain CCPA/CPRA basics: opt-out of sale/sharing, and sensitive personal information categories
Assess training data provenance and licensing risk for a proposed AI feature
Design opt-out/opt-in UX that satisfies legal requirements without silently killing the data flywheel

The Problem

A PM at a consumer productivity app ships a feature that fine-tunes a per-user writing-style model on each user's document history, to auto-complete in their own voice. Six months later, a user in the EU exercises their GDPR right to erasure and asks the company to delete their data. Engineering deletes the user's documents from the database within the required window — and closes the ticket. Legal reopens it two weeks later: the user's writing style is still baked into a fine-tuned model checkpoint that's been deployed to production and used to generate completions for other users' shared workspace documents. The database deletion was real and correct. The actual request — "remove my information from your systems" — was not satisfied, because a fine-tuned model isn't a database row you can delete; it's a set of weights that absorbed a statistical trace of the training data and doesn't offer a clean way to subtract one user's contribution back out.

This is the specific way AI makes data governance harder than a traditional PM's mental model expects. Traditional data governance assumes deletion is mechanical: find the row, delete the row, done. AI governance has to account for the fact that some data — anything used in training or fine-tuning — leaves a trace that ordinary deletion doesn't reach, which means the PM's job shifts from "can we delete this" to "should this data have gone into training in the first place, and if so, under what documented consent." Getting this right before a feature launches is dramatically cheaper than discovering the gap after a regulator or a user's lawyer asks about it.

GDPR Basics an AI PM Actually Needs

GDPR applies to any company processing personal data of EU residents, regardless of where the company is based. The AI-relevant basics:

Lawful basis for processing — every use of personal data needs a legal basis (consent, legitimate interest, contract necessity, etc.). "We need it to train a better model" is not automatically a lawful basis; it typically needs to be consent or a carefully justified legitimate-interest assessment, especially for training data that will influence outputs shown to other users.
Data subject rights — access, rectification, erasure, portability, and the right to object to automated decision-making. The erasure right is the one that collides hardest with ML: deleting a row is straightforward, but if that row's content was already baked into a trained model, true erasure may require retraining without that data, which is expensive and slow — which is exactly why the consent decision at collection time matters so much more for AI features than for traditional ones.
Automated decision-making (Article 22) — GDPR gives data subjects the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects, without meaningful human involvement. Any AI feature that approves/denies/scores people (credit, hiring, insurance) needs a human-in-the-loop path, not just a model output, to stay compliant.

The consent question belongs at data-collection time, not at model-training time
By the time engineering is ready to train, the honest question — "did we get consent for this specific use, including training a model on it" — is usually much harder and more expensive to answer well than it would have been at the point the data was first collected. Bake a training-use consent flag into data collection from day one, even for data you're not yet planning to use for training. Retrofitting consent onto data already collected for a narrower purpose is a legal and product mess that regularly delays or kills AI features late in the roadmap.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers CCPA/CPRA Basics for AI PMs, Designing Opt-Out/Opt-In UX Without Killing the Flywheel, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.