Runtime Privacy Controls and Audit Evidence

Definition
Runtime privacy controls enforce compliance during live inference, while audit evidence provides immutable proof for regulatory inquiries.
CONSENT ENFORCEMENT AT INFERENCE
Before personalized predictions, check user consent. Query consent service with user_id and purpose. Cache decisions locally (TTL 5-15 minutes) to reduce latency. If revoked or missing, fall back to non-personalized defaults. Log every check for audit.
PURPOSE LIMITATION AT RUNTIME
Data for purpose A cannot be used for purpose B without re-consent. Tag every access with purpose. Feature store returns different sets based on purpose: recommendation features only for purpose=recommendations. Violations trigger alerts and block processing.
💡 Key Insight: Purpose limitation must be enforced at data layer, not application. Applications make mistakes. Feature store should reject purpose violations—no exceptions.
IMMUTABLE AUDIT LOGS
Log every privacy action immutably: consent changes, data access, DSAR processing, deletions. Use append-only storage. Include timestamps, actor, action, outcome. Regulators may request logs years later—retention often exceeds data retention.
AUDIT EVIDENCE GENERATION
When regulators inquire, generate reports: consent records, data accesses, DSAR handling with timestamps. Automate—manual compilation takes weeks. Include cryptographic hashes proving log integrity.
⚠️ Key Trade-off: Comprehensive logging increases storage and latency. Retain detailed logs 90 days, summarized 7 years. Balance regulatory requirements with cost.

💡 Key Takeaways

✓Check consent at inference; cache with 5-15 min TTL, fallback to non-personalized

✓Purpose limitation enforced at data layer, not application

✓Immutable audit logs with cryptographic integrity for regulators

📌 Interview Tips

1Describe consent check: query, cache, fallback on revocation

2Mention purpose limitation at feature store level

← Back to Regulatory Compliance (GDPR, CCPA) Overview