Can you move beyond conceptual understanding to production implementation? Do you understand the privacy-utility tradeoff at a quantitative level?

1. Define the privacy budget — set epsilon (ε) and delta (δ) parameters based on the sensitivity of the data and the required privacy guarantee. Lower epsilon = stronger privacy but more noise. 2. Implement DP-SGD — use PyTorch Opacus or TensorFlow Privacy to modify the training loop: per-sample gradient clipping, calibrated noise addition, and privacy accounting. 3. Privacy accounting — track cumulative privacy loss across training iterations using Rényi differential privacy or the moments accountant. 4. Utility optimization — tune hyperparameters (clipping norm, noise multiplier, batch size) to maximize model accuracy within the privacy budget. Larger batch sizes reduce noise impact. 5. Verification — run membership inference attacks against the trained model to empirically validate that privacy guarantees hold.

This tests your understanding of privacy attacks against ML models. Can you explain both the attack mechanism and practical defenses?

Membership inference: An attacker determines whether a specific data point was in the model’s training set by analyzing the model’s confidence scores. Models tend to be more confident on training data vs. unseen data. Defenses: differential privacy (formal guarantee), regularization (reduce overfitting), confidence masking (round or threshold output probabilities). Model inversion: An attacker reconstructs training data features (potentially PII) from model outputs. Given a prediction, the attacker optimizes an input to maximize the model’s confidence, effectively “inverting” the model. Defenses: differential privacy, output perturbation, limiting query access, input feature masking. Data memorization: LLMs can memorize and verbatim reproduce training data. Defenses: deduplication, differential privacy during training, output filtering for known PII patterns.

Can you translate GDPR Article 25 (data protection by design) into a concrete engineering architecture? Do you think about privacy from system design, not just post-hoc?

1. Data minimization — collect only what’s necessary. Define purpose limitation at the schema level. Implement retention policies with automated deletion. 2. Privacy-preserving training — federated learning (data stays on-device), differential privacy (formal guarantees), or secure aggregation (encrypted model updates). 3. Access control architecture — role-based access to raw data, anonymized views for analytics, audit logging for all data access. 4. Consent management — granular consent capture, propagation through the data pipeline, and machine-readable consent signals that gate data processing. 5. Right-to-erasure implementation — data deletion across all systems (including backups and derived datasets), with machine unlearning for deployed models if retraining is infeasible.

This tests your judgment on the privacy-utility tradeoff. Can you make quantitative decisions, not just philosophical ones?

The privacy-utility tradeoff is the central challenge. Quantitative approach: 1. Define acceptable utility loss thresholds with product teams before implementation (e.g., <2% accuracy drop). 2. Experiment with epsilon values on held-out data to map the privacy-utility curve for the specific task. 3. Use composition theorems to budget total privacy loss across multiple queries or training runs. 4. Consider task-specific techniques: federated learning for recommendation systems (no raw data leaves device), synthetic data generation for analytics (preserves statistical properties without real PII), differential privacy for aggregate statistics (census-style). 5. Communicate tradeoffs to stakeholders in business terms: “This privacy level means X% accuracy reduction, which translates to Y impact on user experience.”

This tests whether you understand the novel privacy risks that LLMs introduce beyond traditional ML models.

LLM-specific privacy challenges: 1. Training data memorization — LLMs can memorize and reproduce verbatim passages from training data, including PII, copyrighted text, and private communications. Mitigation: deduplication, DP-SGD during fine-tuning, canary token detection. 2. Prompt injection and data extraction — adversaries craft prompts to extract training data or system prompt contents. Mitigation: input/output filtering, guardrails, monitoring. 3. Inference-time privacy — user prompts may contain sensitive information that gets logged, cached, or used for further training. Mitigation: prompt anonymization, opt-out mechanisms, encrypted inference. 4. Embedding leakage — vector embeddings can be reversed to recover original text. Mitigation: embedding perturbation, access controls on vector databases. 5. Right-to-erasure compliance — removing an individual’s data influence from a trained LLM is an unsolved problem at scale. Mitigation: machine unlearning research, retraining on filtered datasets, retrieval-augmented approaches that decouple knowledge from model weights.