← Master Index
Vol. 20 Module 20.1 Lecture

Compliance

Safety, Fairness & Governance

How This Lesson Fits the Module & Volume

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.
Definition

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.

Not Legal Advice

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 buildersTypical engineering artifacts
GDPR-style (EU personal data)Lawful basis, purpose limitation, minimization, retention, security, data-subject rights, DPIA-like thinking for high riskPurpose 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 limitsPreference flags; vendor DPAs tracked in inventory; deletion across logs/indexes; no silent training on consumer data
EU AI Act-styleRisk-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
Classify

Data types + AI risk tier (with privacy/legal).

Minimize

Collect / retain only what the purpose needs.

Control

Access, vendors, HITL, guardrails.

Prove

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.

StoreTypical purposeCompliance-minded default
Chat transcriptProduct featureUser-visible retention + delete/export
Prompt tracesDebug / evalRedact; short TTL; separate env
Security audit logAbuse / IRRestricted access; defined TTL; no marketing reuse
RAG embeddingsSearchDelete/rebuild on rights request; manifest ownership
Fine-tune corpusQualityOpt-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.

# Engineering hooks only. Not legal advice. Not a GDPR/CCPA/AI Act implementation. from datetime import datetime, timedelta, timezone PURPOSES = {"provide_support", "security_audit", "optional_quality_improve"} def new_record(user_id: str, purpose: str, payload_ref: str, ttl_days: int) -> dict: if purpose not in PURPOSES: raise ValueError("unknown_purpose") if purpose == "optional_quality_improve": raise ValueError("requires_explicit_preference_flag") # check prefs store first now = datetime.now(timezone.utc) return { "user_id": user_id, "purpose": purpose, "payload_ref": payload_ref, # pointer, not a second PII copy "created_at": now.isoformat(), "delete_after": (now + timedelta(days=ttl_days)).isoformat(), "legal_hold": False, } def can_use_for_training(prefs: dict) -> bool: return bool(prefs.get("quality_improve_opt_in")) and not prefs.get("do_not_share_like_flag") def rights_export(user_id: str, stores: dict) -> dict: """Assemble what you can find. Incomplete stores = a compliance bug to fix.""" return { "user_id": user_id, "chats": stores["chat"].list(user_id), "tickets": stores["ticketing"].list(user_id), "generated_at": datetime.now(timezone.utc).isoformat(), "note": "Embeddings/indexes must be included via rebuild jobs — see privacy runbook.", } def rights_delete(user_id: str, stores: dict, legal_hold: bool) -> dict: if legal_hold: return {"ok": False, "reason": "legal_hold_escalation"} results = {} for name, store in stores.items(): results[name] = store.delete_user(user_id) # chats, logs, index rebuild queue return {"ok": True, "results": results}

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

LectureRole
PrivacySubstantive data-protection design
TransparencyUser-facing AI disclosure
GovernanceInventory & risk evidence
CopyrightTraining data / output obligations (separate from privacy)
SecurityNext: volume capstone threat model
Common Misconception

“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

  1. Short Answer: Is this lecture legal advice? Answer: No—high-level engineering implications only.
  2. True/False: RAG embeddings can contain personal data even if chunks feel “just text.” Answer: True.
  3. Multiple Choice: GDPR-style themes for builders include: (a) minimization, purpose, rights workflows, (b) only dropout rate, (c) only BLEU. Answer: (a).
  4. 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).
  5. True/False: Vendor model compliance automatically covers your chat logs. Answer: False.
  6. Multiple Choice: A rights-delete path should consider: (a) chats and indexes, (b) only CSS files, (c) only GPU firmware. Answer: (a).
  7. Short Answer: Why tag logs with a purpose and TTL? Answer: Purpose limitation and retention—audit vs privacy tension.
  8. True/False: Defaulting to train-on-user-content is a privacy-minded design. Answer: False.
  9. Multiple Choice: Next lecture: (a) security capstone, (b) k-NN, (c) spectrograms. Answer: (a).
  10. 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).
Trainer’s Guide

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.