Audit an ML pipeline for GDPR compliance

WHAT THIS TESTS: Whether you can operationalize abstract privacy principles as technical checks on a real pipeline, rather than reciting legal definitions, and whether you understand lineage well enough to trace an individual prediction.

A GOOD ANSWER COVERS: Data minimization: build a complete data inventory listing every field ingested and every feature used, then justify each against the model's purpose. Flag data that is collected but never used, retained longer than needed, or more granular than required, for example storing full birthdate when an age band suffices. Check retention policies and deletion mechanisms. Purpose limitation: map each processing step to the purpose the data subject consented to, and detect drift where data gathered for one purpose, say fraud prevention, is repurposed for marketing without a new basis. Verify access controls enforce purpose boundaries. Data provenance: confirm the pipeline records lineage so that for any given prediction you can reconstruct which source records, which feature values, which model version, and which transformations produced it. This supports subject-access and right-to-explanation requests and lets you honor erasure by finding all derived artifacts.

COMMON WRONG ANSWERS: Treating GDPR as a legal checklist with no technical verification. Assuming a privacy policy document equals compliance. Ignoring derived data and model artifacts when handling deletion.

LIKELY FOLLOW-UPS: How would you implement lineage tracking technically? What happens to a model trained on data a user later asks to erase? How do you test that deletion actually propagates?

ONE CONCRETE EXAMPLE: Auditing a credit model, the analyst finds it ingests precise GPS history never used by any feature, flagging a minimization violation, confirms loan data is not being reused for ad targeting, and verifies a lineage system can take one applicant's prediction and list the exact source rows, feature values, and model version behind it.