The Privacy, GDPR, and EU AI Act sections of the checklist

Description

We fill in sections 2-4 of the checklist: Privacy, Transparency, and Compliance. The items are derived directly from the M3, M4, and M5 work.

By the end you'll have 14-17 additional, well-specified items for your checklist.

---

Section 2: Privacy and Data Protection (5-6 items)

## Item 2.1: Data inventory complete

**Question**: Is there a documented inventory of all personal data fields
processed by the system (training + inference)?

**Why**: You can't apply data minimization without knowing what you have.

**Evidence**: A data inventory document with field names, purposes,
sources, and retention periods.

**Critical**: Yes

---

## Item 2.2: Data minimization applied

**Question**: For each personal data field, is its necessity documented and
justified, OR has the field been removed?

**Why**: The GDPR Art. 5(1)(c) data minimization principle.

**Evidence**: Per-field justification in the data inventory; removed fields
documented as such.

**Critical**: Yes

---

## Item 2.3: Anonymization/pseudonymization applied where possible

**Question**: For data fields that don't require direct identification, has
anonymization or pseudonymization been applied?

**Why**: It reduces the impact of a breach; supports GDPR.

**Evidence**: The anonymization procedure documented; verified in code review.

**Critical**: Medium

---

## Item 2.4: Multi-tenant data isolation verified

**Question**: For multi-tenant systems, is tenant data isolation verified
through testing (a penetration test or comprehensive test cases)?

**Why**: Cross-tenant leakage is catastrophic legally and
reputationally.

**Evidence**: Test results showing tenant isolation; a penetration test
report.

**Critical**: Yes (for multi-tenant systems)

---

## Item 2.5: Retention policy implemented

**Question**: Are retention periods defined per data category and
automatically enforced via TTL or scheduled deletion?

**Why**: GDPR requires storage limitation. Manual deletion = unreliable.

**Evidence**: A retention policy document; evidence of the automated job.

**Critical**: Yes

---

## Item 2.6: Encryption at rest and in transit

**Question**: Is all personal data encrypted at rest (AES-256+) and in
transit (TLS 1.2+)?

**Why**: GDPR Art. 32 security; best practice; it reduces breach impact.

**Evidence**: The encryption config; an SSL/TLS validator report.

**Critical**: Yes

---

Section 3: Transparency and Explainability (4-5 items)

## Item 3.1: AI disclosure to users

**Question**: Are users explicitly informed they're interacting with AI?

**Why**: The EU AI Act limited risk requirement + general transparency.

**Evidence**: User onboarding screenshots; the UI showing an AI indicator.

**Critical**: Yes

---

## Item 3.2: Decision explanations provided

**Question**: For automated decisions affecting users, is a meaningful
explanation provided?

**Why**: GDPR Art. 22; the user's right to understand.

**Evidence**: The explanation template; sample notifications.

**Critical**: Yes for systems with automated decisions

---

## Item 3.3: Source citations or sources shown

**Question**: For information-based outputs, are sources cited or
shown to the user?

**Why**: It enables verification; reduces overreliance; supports
accountability.

**Evidence**: The UI showing citations; sample responses.

**Critical**: Yes for information systems

---

## Item 3.4: System limitations disclosed

**Question**: Are the system's known limitations documented and disclosed to
users where relevant?

**Why**: It sets correct expectations; reduces misuse.

**Evidence**: Limitations documentation; UI disclosures.

**Critical**: Medium

---

## Item 3.5: Confidence indicators (where applicable)

**Question**: For probabilistic outputs, are confidence indicators
shown to users?

**Why**: Users make better decisions with confidence information.

**Evidence**: The UI showing confidence; threshold documentation.

**Critical**: Medium

---

Section 4: Compliance — EU AI Act + GDPR (6-7 items)

## Item 4.1: EU AI Act risk classification

**Question**: Has the system been classified by EU AI Act risk
category (unacceptable, high, limited, minimal)?

**Why**: The risk category determines your compliance obligations.

**Evidence**: The Risk Classification document (the M4 deliverable).

**Critical**: Yes

---

## Item 4.2: High-risk obligations met (if high-risk)

**Question**: If classified as high-risk, are all the Article 9-15 obligations
implemented (risk management, data quality, documentation, logging,
transparency, human oversight, accuracy, robustness)?

**Why**: High-risk AI cannot be deployed in the EU without these.

**Evidence**: A compliance matrix per obligation.

**Critical**: Yes (if high-risk)

---

## Item 4.3: GDPR Art. 22 — automated decisions

**Question**: For automated decisions, is Art. 22 compliance achieved
(meaningful information about the logic, human review available, the right to
contest)?

**Why**: A legal mandate; multi-million-euro fines for a violation.

**Evidence**: User-facing notifications; the human review workflow.

**Critical**: Yes (if Art. 22 applies)

---

## Item 4.4: Lawful basis documented per processing

**Question**: Is each processing activity documented with a clear
lawful basis (consent, contract, legitimate interest, etc.)?

**Why**: A GDPR Art. 6 requirement.

**Evidence**: The RoPA with a lawful basis per activity.

**Critical**: Yes

---

## Item 4.5: Data subject rights implemented

**Question**: Are processes implemented for all the GDPR data subject
rights (access, rectification, erasure, portability, object, restrict)?

**Why**: A legal mandate; a 1-month SLA for responses.

**Evidence**: Process documentation; a sample request handled.

**Critical**: Yes

---

## Item 4.6: International transfers safeguarded

**Question**: For data transfers outside the EU, are appropriate safeguards
in place (SCCs, BCRs, an adequacy decision)?

**Why**: GDPR Chapter V.

**Evidence**: SCCs with the processors; legal review.

**Critical**: Yes (if transfers occur)

---

## Item 4.7: Breach notification procedure ready

**Question**: Is a breach notification procedure documented that enables
72-hour notification to the supervisory authority?

**Why**: The GDPR Art. 33 obligation.

**Evidence**: The incident response runbook; team training records.

**Critical**: Yes

---

Common traps for these sections

Trap 1 — "We comply with GDPR." Far too vague. Specify EACH article + how.

Trap 2 — Cross-references between sections with no clarity. Item 4.3 references Art. 22 from M5. Document it: "see Item 4.3 and its evidence."

Trap 3 — Item 4.6 ignored. "Pinecone is in the US" → then you have a transfer. You need documented SCCs.

Trap 4 — Item 4.7 with no team training. A documented procedure, but the team doesn't know it. A breach happens, and the response is slow.

---

Exercise

Fill in the 3 sections for your system:

1. The Privacy section: the status of each item with evidence
2. The Transparency section: the status of each item
3. The Compliance section: the status of each item
4. Identify the "No" items and plan the remediation

---

Summary

You learned:

• ✅ Section 2 (Privacy): 6 items
• ✅ Section 3 (Transparency): 5 items
• ✅ Section 4 (Compliance): 7 items
• ✅ Each item linked to the M3-M5 work
• ✅ Critical flags marking the blockers

Checkpoint: if you have 18+ items in full format, combined with section 1 (6 items) you already have ~24 items.

---

Next capsule

05 — Review processes. You have items. Now design WHEN they're applied, WHO participates, and WHAT happens when there's a "No."

---

Resources

1. GDPR Compliance Checklist M5.
2. EU AI Act Risk Classification M4.
3. Privacy Assessment M3.