Governance created inventories and risk registers. Compliance asks which external regimes those records must satisfy. This lecture covers high-level engineering implications of GDPR, CCPA/CPRA-style privacy law, and the EU AI Act—mapped to logging, minimization, user rights workflows, transparency, and risk-tiered controls you already built in Vol. 13–15 and earlier Vol. 20 lectures.
Not legal advice. Statutes change; counsel and DPOs interpret them for a real company. Students learn what engineers usually get asked to implement, so they do not invent shadow processing. The volume then closes with security as the technical capstone before Vol. 21 product building.
Learning Objectives
By the end of this lesson, students should be able to:
- State that this lecture is engineering orientation, not legal advice.
- Map GDPR/CCPA-style themes to data minimization, purpose, retention, and rights workflows.
- Map EU AI Act-style risk tiers to use-case allowlists and documentation.
- Design logging and deletion hooks that respect privacy + audit tension.
- Connect privacy, transparency, and governance artifacts to compliance evidence.
- Know when to stop and escalate to qualified legal/privacy specialists.
Compliance (in this curriculum) is the practice of designing AI systems so that processing, documentation, and user-facing controls can be shown to match applicable legal and policy obligations. Engineers implement capabilities (consent flags, export/delete, retention jobs, model cards, human oversight switches). Lawyers decide whether those capabilities are sufficient for a jurisdiction and use case. Never ship a “we are GDPR-compliant” claim from a lecture alone.
Names of laws below are teaching labels for common themes. They are simplified, incomplete, and not a checklist for production. If your product touches personal data, high-risk decisions, minors, or the EU/UK/US state privacy markets, involve qualified counsel. This page exists so engineers do not accidentally ignore the themes.
Three Regimes as Engineering Themes
| Regime (teaching label) | Core themes for builders | Typical engineering artifacts |
|---|---|---|
| GDPR-style (EU personal data) | Lawful basis, purpose limitation, minimization, retention, security, data-subject rights, DPIA-like thinking for high risk | Purpose tags on pipelines; delete/export APIs; retention jobs; access control; records of processing (with privacy team) |
| CCPA/CPRA-style (US consumer privacy) | Notice, “do not sell/share” style choices, access/delete, sensitive data care, service-provider limits | Preference flags; vendor DPAs tracked in inventory; deletion across logs/indexes; no silent training on consumer data |
| EU AI Act-style | Risk-tiered AI (prohibited / high-risk / limited / minimal), transparency for some systems, human oversight, quality & logging for high-risk uses; GPAI (general-purpose AI) provider obligations for foundation models above certain capability thresholds (transparency, copyright policy, energy reporting where applicable) | Use-case allowlist; system documentation; HITL for high-impact; eval evidence; incident logs; for GPAI providers—model documentation, training-data summaries, and compliance artifacts (with counsel) |
Overlap is the point: inventory + risk register is evidence for several regimes. Vol. 15 HITL is both a safety control and a common high-risk oversight pattern. Vol. 13 guardrails and logging support security-of-processing themes without claiming a certification.
Implications for LLM Apps
Data plane
- Know what personal data enters prompts, logs, traces, RAG
- Default: do not train on user content
- Indexes are processing: chunking does not erase personal data
- Vendors (model APIs) are part of the processing chain
Rights & preferences
- Export / delete must consider chat logs and embeddings
- Consent or preference flags gate optional uses (e.g. improve model)
- Identity verification for rights requests is a product flow
- Unstructured LLM logs make naive “grep delete” insufficient
AI Act-style product design
- Refuse prohibited / out-of-policy use cases in the product, not only the prompt
- High-impact decisions: HITL + documentation + eval
- Transparency: tell users they interact with AI (transparency)
- Keep technical docs aligned with the inventory
Data types + AI risk tier (with privacy/legal).
Collect / retain only what the purpose needs.
Access, vendors, HITL, guardrails.
Logs, inventory, eval, rights SLAs.
Logging vs Deletion (Design Tension)
Security and incident response want rich logs. Privacy regimes want minimization and deletion. The engineering resolution is purpose-tagged retention: security logs with shorter TTL and restricted access; debug traces without raw PII where possible; explicit legal holds. Do not keep forever “just in case,” and do not delete the only evidence during an active incident without a playbook.
| Store | Typical purpose | Compliance-minded default |
|---|---|---|
| Chat transcript | Product feature | User-visible retention + delete/export |
| Prompt traces | Debug / eval | Redact; short TTL; separate env |
| Security audit log | Abuse / IR | Restricted access; defined TTL; no marketing reuse |
| RAG embeddings | Search | Delete/rebuild on rights request; manifest ownership |
| Fine-tune corpus | Quality | Opt-in only; license + inventory; hard to unlearn—prefer not to include |
Defensive Snippet: Purpose, Retention, Rights Hooks
Illustrative flags and jobs—not a compliance certification. Wire these to real identity, legal hold, and vendor deletion APIs with your privacy team.
What Engineers Escalate
Build without waiting
- Inventory fields for data classes and vendors
- Retention TTLs and delete/export stubs
- HITL + eval evidence packs
- User-facing “this is AI” copy with product/legal review
Stop and call specialists
- Lawful basis / “are we allowed to” questions
- High-risk automated decisions (credit, employment, biometrics)
- Cross-border transfers, minors, health data
- Public “we are compliant” marketing claims
Related Lectures
| Lecture | Role |
|---|---|
| Privacy | Substantive data-protection design |
| Transparency | User-facing AI disclosure |
| Governance | Inventory & risk evidence |
| Copyright | Training data / output obligations (separate from privacy) |
| Security | Next: volume capstone threat model |
“The model vendor is GDPR-compliant, so we are.” Your prompts, logs, and indexes are still your processing. Second: deleting SQL rows while leaving vector embeddings. Third: using this lecture as a certification. Fourth: EU AI Act duties apply to both deployers of high-risk systems and GPAI providers of certain foundation models—counsel maps which role you hold. Fifth: compliance is a one-time launch form; regimes expect ongoing logs, updates, and rights handling.
Knowledge Check
- Short Answer: Is this lecture legal advice? Answer: No—high-level engineering implications only.
- True/False: RAG embeddings can contain personal data even if chunks feel “just text.” Answer: True.
- Multiple Choice: GDPR-style themes for builders include: (a) minimization, purpose, rights workflows, (b) only dropout rate, (c) only BLEU. Answer: (a).
- Short Answer: Name one EU AI Act-style engineering implication. Answer: Risk-tiered use-case allowlists, HITL/oversight, documentation, transparency, or eval/logging evidence (any valid).
- True/False: Vendor model compliance automatically covers your chat logs. Answer: False.
- Multiple Choice: A rights-delete path should consider: (a) chats and indexes, (b) only CSS files, (c) only GPU firmware. Answer: (a).
- Short Answer: Why tag logs with a purpose and TTL? Answer: Purpose limitation and retention—audit vs privacy tension.
- True/False: Defaulting to train-on-user-content is a privacy-minded design. Answer: False.
- Multiple Choice: Next lecture: (a) security capstone, (b) k-NN, (c) spectrograms. Answer: (a).
- Short Answer: When must engineers escalate to counsel/DPO? Answer: Lawful-basis, high-risk decisions, minors/health, transfers, or public compliance claims (any valid).
Key Takeaways
- Compliance here = engineering capabilities + evidence, not a law degree.
- GDPR/CCPA-style: minimize, purpose-tag, retain less, honor rights across stores.
- AI Act-style: risk-tier use cases, oversight, transparency, documentation.
- Inventories, HITL, and eval gates are reusable evidence—still not legal advice.
- Next: Security (Vol. 20 capstone).
Lab: Students map a support copilot’s stores (chat, traces, KB index, vendor API) to purpose + TTL + delete/export notes. They mark three questions they would escalate to legal. No jurisdiction-specific legal conclusions.
Discussion: Security wants 1-year prompt traces; privacy wants 30 days. Design a split (redacted debug vs restricted audit) without claiming it “satisfies GDPR.”
Recap: Compliance translates governance records into privacy and AI-risk engineering themes—never into DIY legal certification. Close Vol. 20 by threat-modeling the whole stack in Security.