The Recommendation Engine and the Inference Log
A retail platform runs a product recommendation model trained on 14 months of clickstream data. The privacy team learns that the feature pipeline stores per-user embedding vectors in a logging bucket for 30 days to support debugging. Each vector is 128 floats and is keyed to a hashed user ID. The data governance policy says logs may contain only 'aggregated, non-identifying telemetry.' The engineering lead argues the embeddings are not personal data because the user ID is hashed and the floats are meaningless without the model. A security researcher demonstrates that the embeddings can be inverted to reconstruct approximate browsing histories for users who appear in the training data, and that the hash is unsalted, so it can be reversed against a known user list. Retention was set to 30 days by default and never reviewed. Roughly 2.1 million vectors are written per day.
1. Assess whether the embeddings and hashed IDs fall within the policy's 'aggregated, non-identifying telemetry' category, and identify the governance failures.
Read the worked answer
They do not fall within the category, on two independent grounds.
First, the hashed ID is a pseudonymous identifier, not an aggregate. An unsalted hash of a user ID is reversible by anyone holding a candidate list, which the researcher demonstrated. Pseudonymization reduces casual exposure but does not make data non-identifying, and the policy language ('non-identifying') is stricter than 'pseudonymous'.
Second, the embeddings are not aggregated telemetry. They are per-user derived records that, as demonstrated, permit approximate reconstruction of browsing history. A record that can be inverted to recover behavioral data about a specific person is personal data regardless of whether a human can read the floats directly.
The governance failures are concrete:
- Classification failure: the pipeline was never assessed against the policy before logging was enabled.
- Retention failure: a 30-day default was set and never reviewed, so no one applied a purpose test to the retention period.
- Control failure: the logging bucket apparently lacked the access and review controls that a personal-data store would require.
- Review failure: the policy existed but no process connected it to pipeline changes.
The fix is to reclassify the embeddings as personal data, stop unsalted hashing, minimize or drop the logging, and route future pipeline changes through a data-classification review.
2. Propose a remediation sequence with owners and a defensible retention decision, and explain how you would justify the retention period.
Read the worked answer
Sequence, roughly in order of risk reduction:
- Immediate (security/engineering): disable or severely restrict the logging bucket, and purge vectors older than the minimum needed. This stops ongoing accumulation of the highest-risk records.
- Short term (engineering): replace the unsalted hash with a keyed hash or drop the identifier entirely, storing only aggregate counters per model version.
- Short term (privacy/legal): assess whether the reconstructed-history risk triggers notification obligations; document the assessment.
- Medium term (data governance): add the embedding pipeline to the data inventory with an explicit classification, and require a review gate for any new per-user logging.
On retention: the stated purpose is debugging, which typically needs recent examples, not 30 days of full volume. A defensible decision is to keep a small sampled set, for example a few thousand vectors, for 7 days, with access logged, and to aggregate the rest. The justification should state the purpose, why the shorter period still satisfies it, why the sample size is sufficient, and who approved it. 'Default was 30 days' is not a justification; a retention period must be tied to a purpose and reviewed on a schedule.