17. Privacy & Compliance

Privacy and compliance are architectural concerns, not afterthoughts. AI systems that handle personal data must be designed for regulatory requirements from day one.

GDPR & CCPA Requirements

Requirement	System Implication
Right to be forgotten	Data deletion must propagate to all systems: feature store, training data, model registry, logs.
Data portability	Export user's data and model predictions in machine-readable format.
Consent management	Track user consent per data type. Feature computation must respect consent flags.
Explainability	Users can request explanation of automated decisions. Must store feature values + model explanations.
Data minimization	Only collect and store features actually needed for the model.
Retention limits	Delete raw data after retention period. Audit data deletion.

Differential Privacy

Differential privacy adds calibrated noise to data or model updates to prevent identifying individuals from model outputs.

# Differential privacy during training
For each training batch:
  1. Compute gradients
  2. Clip gradient norm to C (max sensitivity)
  3. Add Gaussian noise with scale σ = C * √(2 * log(1.25/δ)) / ε
  4. Apply noisy gradients

Parameters:
  ε (epsilon): privacy budget. Smaller = stronger privacy.
  δ (delta): probability of privacy breach. Typically < 1/N.

Practical values: ε=8 (moderate privacy), ε=1 (strong privacy)

AI TRiSM (Trust, Risk, Security, Management)

IBM's AI TRiSM framework guides enterprise AI governance:

Trust: Model explainability, fairness auditing, bias detection.
Risk: Risk assessment for each model — what happens if it fails? Classification: low/medium/high/critical.
Security: Model protection (adversarial robustness), data security, prompt injection defenses.
Management: Model lifecycle, approval gates (staging → production), compliance documentation.

Data Sovereignty

Data must stay within geographic boundaries. System design implications:

Regional deployment: Deploy inference pipelines in each region (EU, US, APAC) with local data stores.
Data routing: Route user data based on origin (EU users → EU cluster).
Cross-region transfer: Anonymize or pseudonymize before cross-border transfer.
Model training in-region: Training data must not leave the region.

Architecting for Compliance

# Compliance-aware system design
Data ingestion:
  → Check user consent (consent store)
  → Tag data with region, consent level, retention policy
  → Store in region-specific data lake

Feature computation:
  → Skip features for users who have revoked consent
  → Apply retention window (delete features older than N days)

Model inference:
  → Log all predictions with feature values for audit
  → Support explanation generation (SHAP, LIME)
  → Support data deletion request (delete from feature store + retrain model)

Model registry:
  → Store training data lineage (which dataset version, consent snapshot)
  → Approval gates: legal review before production deployment

Exercise: You are designing a health recommendation system that uses patient medical history. The data is subject to HIPAA and GDPR. Describe your architecture for: a) obtaining and storing patient consent, b) ensuring data stays in-region, c) handling a patient's "right to be forgotten" request that requires deleting their data from the feature store AND retraining the model without their data, d) providing explainability for each recommendation.