Lesson 6.4: Data Privacy and Compliance
Data Privacy Laws & Compliance
Data is the fuel of AI — and when that data is about people, the law applies. Learn to identify PII, obtain valid consent, protect data through anonymization, and respond correctly when something goes wrong.
The practical mechanics of keeping data private
Lesson 6.3 gave you the regulatory landscape — the laws and frameworks. This lesson gives you the practical mechanics: how to identify personal data, how to obtain consent that actually holds up legally, how to protect data through anonymization and pseudonymization, and exactly what to do in the first 72 hours after a data breach. These aren't abstract principles — they're the day-to-day decisions that determine whether your AI project stays compliant or lands your organization in a regulatory investigation.
Every AI system that processes personal data requires these skills. And almost every AI system processes personal data — training data, inference inputs, user logs, behavioral profiles. Understanding the practical compliance mechanics is what separates AI professionals who can deploy responsibly from those who create expensive liability for their organizations.
Privacy by design means the question isn't "can we collect this?" — it's "do we need this?" GDPR's data minimization principle requires collecting only what's necessary for the stated purpose. The most compliant AI systems are the ones that were designed from the start to use the minimum personal data required — not the ones that collected everything and tried to justify it later.
The language of data privacy compliance
These terms are tested on the AIAS exam and appear in every data privacy compliance conversation. Pay special attention to the distinctions between anonymization and pseudonymization — one removes GDPR obligations, the other doesn't.
| Term | Definition |
|---|---|
| Personal Data / PII | Any information that relates to an identified or identifiable person. Under GDPR: "any information relating to an identified or identifiable natural person." Includes obvious identifiers (name, email, SSN) and less obvious ones (IP address, device ID, location data, behavioral patterns). If it can be linked back to a specific person — directly or indirectly — it's personal data. |
| Sensitive Personal Data | A special category under GDPR with stricter protection requirements. Includes: health and medical data, racial/ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data used for identification, sexual orientation, and criminal convictions. Processing sensitive data typically requires explicit consent (stronger than regular consent) or another specific legal basis. |
| Data Controller | The entity that determines why and how personal data is processed — the one with decision-making authority over the data. Carries primary GDPR responsibility. Example: a hospital using AI for patient risk scoring is the data controller for patient data. |
| Data Processor | An entity that processes personal data on behalf of the data controller — following instructions rather than making processing decisions independently. Example: an AI cloud vendor processing hospital patient data to run the risk model is the data processor. Both controller and processor have GDPR obligations. |
| Consent | Under GDPR: a freely given, specific, informed, and unambiguous indication of agreement to data processing. Must be as easy to withdraw as to give. Cannot be buried in terms of service, pre-ticked, or made a condition of service when not necessary. Documented and auditable. |
| Legitimate Interest | A GDPR legal basis for processing personal data — used when consent isn't appropriate but processing is reasonably expected and doesn't override individuals' rights. Requires a balancing test: the controller's interest vs. the individual's privacy expectations. Often used for fraud detection, network security, and direct marketing (with opt-out). |
| Anonymization | Irreversible transformation of data so that individuals can no longer be identified — even with additional information. Truly anonymized data is not personal data and falls outside GDPR's scope. The bar is high: if re-identification is reasonably possible by anyone, it's not truly anonymous. |
| Pseudonymization | Replacing identifying fields with artificial identifiers (pseudonyms) in a way that could be reversed with the right key. Example: replacing names with user IDs, where a separate key links IDs to names. Still personal data under GDPR (the key still exists), but encouraged as a security measure — reduces re-identification risk without eliminating it. |
| Data Breach | A security incident resulting in accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access to personal data. Doesn't require malicious intent — accidentally emailing the wrong person a client list is a breach. The severity determines response requirements. |
| 72-Hour Notification Rule | GDPR requires data controllers to notify the relevant supervisory authority (data protection regulator) within 72 hours of becoming aware of a breach — if the breach is likely to result in risk to individuals' rights and freedoms. If the risk to individuals is high, affected individuals must also be notified without undue delay. |
| Privacy by Design & Default | GDPR principle requiring that data protection be built into systems from the outset (by design) and that default settings maximize privacy (by default). For AI: design systems to use minimum data, anonymize where possible, and ensure privacy-protective settings are the default — not something users must opt into. |
Anonymization removes GDPR obligations. Pseudonymization does not. This is one of the most commonly tested distinctions. Pseudonymized data (where a key still exists to re-link) is still personal data under GDPR — it receives some protections but doesn't escape regulation. Only truly irreversible anonymization takes data outside GDPR's scope. When in doubt: if re-identification is theoretically possible, treat it as personal data.
Identify personal data — then protect it
PII Identifier Challenge
Every item below is a type of data an AI system might use. Classify each as: Personal Data (PII), Sensitive Personal Data, or Not Personal Data — then reveal the answers to see if your instincts are right.
IP addresses are personal data. Under GDPR, an IP address is personal data when it can be used (with other information a party has access to) to identify an individual. Most web services and ISPs can make this link — so treat IP addresses as personal data.
Aggregated data can still be personal data. If "total monthly sales" could be attributed to a single salesperson's records, it becomes personal data in that context. Aggregation only escapes PII status when individuals genuinely cannot be re-identified — even with additional information.
Anonymization & Protection Techniques
Once you've identified personal data, the next question is: how do you protect it? These techniques range from full anonymization (removes GDPR obligations) to protective measures that reduce risk while keeping data usable.
Direct Identifier Removal — the simplest step
Remove fields that directly identify individuals: name, email, phone number, SSN, address, account number. This is always step one — but it's rarely sufficient on its own, because remaining fields can often be combined to re-identify individuals ("quasi-identifiers" like age + ZIP + occupation can uniquely identify most people).
GDPR status: Removal of direct identifiers does NOT create anonymized data — it creates pseudonymized data if the remaining fields can still re-identify individuals. Only when re-identification is practically impossible does the data become truly anonymous.
Name: Sarah Johnson
Email: sarah.j@email.com
DOB: 1987-03-14
ZIP: 30301
Diagnosis: Hypertension
Score: 0.73
Name: [REMOVED]
Email: [REMOVED]
DOB: 1987-03-14 ← still risky
ZIP: 30301 ← still risky
Diagnosis: Hypertension ← sensitive
Score: 0.73
Note: DOB + ZIP + Diagnosis still creates a quasi-identifier combination that could re-identify this individual. Further steps are needed.
Generalization — reduce precision to reduce re-identification risk
Replace specific values with broader categories. Instead of exact age, use an age range. Instead of a precise address, use city or region. Instead of exact salary, use a salary band. Generalization reduces the specificity that enables re-identification while keeping the data analytically useful.
GDPR status: Generalization is a key anonymization technique. If done thoroughly enough across all quasi-identifiers, the resulting data may be truly anonymous. The standard: would it be "reasonably possible" for anyone — using all means available — to re-identify individuals? If no, it's anonymous.
Age: 36
ZIP: 30301
Salary: $87,450
Employer: TechCorp Inc
Condition: Hypertension
Age: 30–40
Region: Southeast US
Salary: $80K–$100K
Industry: Technology
Condition: Cardiovascular
The generalized version is far less specific. Combined with other records in an aggregate dataset, re-identification becomes much harder — potentially crossing the threshold to true anonymization.
Pseudonymization — protect identities while keeping data linkable
Replace identifying fields with artificial identifiers (pseudonyms) while storing the key that links pseudonyms to real identities separately. This allows the data to be analyzed without exposing identities — and allows re-linkage when legally authorized (e.g., for follow-up medical treatment).
GDPR status: Pseudonymized data is still personal data under GDPR — the key still exists, so re-identification is possible. However, GDPR encourages pseudonymization as a technical safeguard (Article 32) and treats it as a mitigating factor in risk assessments. It reduces risk without eliminating compliance obligations.
Patient: Sarah Johnson
Email: sarah.j@email.com
Record ID: 10042
Diagnosis: Hypertension
Patient: USR-8847-X
Email: [HASHED]
Record ID: [REPLACED]
Diagnosis: Hypertension
Key file: USR-8847-X → Sarah Johnson (stored securely, access-controlled)
The key file must be stored separately with strict access controls. If the key and data are ever combined, re-identification is immediate — so the separation of key from pseudonymized data is the critical safeguard.
Encryption — make data unreadable to unauthorized parties
Encryption transforms data into an unreadable format using cryptographic keys. Only parties with the decryption key can read the data. Encryption protects data at rest (stored in databases) and in transit (moving over networks). Unlike anonymization, encryption is reversible — it's a security measure, not a privacy technique.
GDPR relevance: GDPR Article 32 requires "appropriate technical measures" to protect personal data — encryption is the gold standard. Critically: if an encrypted database is breached but the encryption keys were not compromised, GDPR may not require individual notification (because the stolen data is essentially unusable). This makes encryption a key breach mitigation strategy.
Name: Sarah Johnson
SSN: 123-45-6789
Diagnosis: Hypertension
Account: ACC-10042
7f3a8b2c91de4f...
a1b2c3d4e5f678...
9k2m4p7r1s5t8u...
3x6y9z2w5q8r1p...
Encryption protects against breaches but not against authorized misuse. If someone with a valid decryption key misuses data, encryption provides no protection — access controls and auditing are also required.
Differential Privacy — mathematical privacy guarantees for AI training
Differential privacy adds carefully calibrated mathematical noise to data or model outputs, making it impossible to determine whether any specific individual's data was included in a training dataset. It provides a mathematical guarantee: the model's output would be essentially the same whether or not any individual's data was included — making it impossible to extract information about specific people from the model.
Why it matters for AI: Standard anonymization protects training data — but AI models can sometimes "memorize" and inadvertently reveal individual training examples through their outputs (especially large language models). Differential privacy addresses this risk by adding noise during training, preventing the model itself from becoming a privacy leak.
Real-world use: Apple uses differential privacy to collect usage statistics without exposing individual user behavior. Google uses it in Chrome for histogram reporting. OpenAI and other AI labs have explored differential privacy for training large models. It's an emerging but increasingly important technique for privacy-preserving AI.
Differential privacy involves a trade-off: more noise = stronger privacy guarantee but lower model utility (accuracy). The "privacy budget" (epsilon ε) controls this balance — a lower ε means stronger privacy but noisier, less accurate results. This is an active research area and an important concept for AI professionals working with sensitive training data.
72 hours — walk through a real breach response
A data breach has just been discovered at a healthcare AI startup. Walk through each step of the correct GDPR breach response — the clock is ticking from the moment of discovery. This is the sequence you need to execute correctly.
Breach Response Simulator — HealthAI Startup
Scenario: Friday 6:47pm — an engineer discovers that a misconfigured database has been publicly accessible for approximately 72 hours. It contains 14,000 patient records including names, email addresses, medical diagnoses, and treatment histories. Click through each response step.
Progress: Step 0 of 6 complete
Choose the right lawful basis for each scenario
GDPR requires a lawful basis for every use of personal data. Consent is just one of six options — and it's not always the right one. For each scenario below, identify the most appropriate lawful basis for data processing.
Ask the Privacy Compliance Advisor
Practice the data privacy conversations you'll have with development teams, legal, and clients. Use the prompts or ask your own question about PII, consent, anonymization, or breach response.
5-Question Quiz
Test your mastery of Lesson 6.4. Select the best answer, then submit for your score and detailed feedback.