A discovery platform builds personalisation from user behaviour. What privacy-engineering decisions must be made early, and which are expensive to retrofit?

The decisions that are expensive to retrofit

1. Data minimisation at collection. What is collected, at what granularity, and for how long. Collecting everything and deciding later means the retrospective decision is made about data that already exists in backups, derived datasets, models and partner integrations. Reducing collection later does not remove what was already gathered.

2. Purpose binding. Recording why each piece of data was collected, and enforcing that it is used only for that purpose. Retrofitting purpose limitation onto a data lake where everything is available to everything is close to impossible, because nobody can determine which downstream use is authorised.

3. Identifier architecture. Whether behavioural data is linked to a durable account identifier or to a rotating pseudonymous one. This decision propagates through every derived dataset, every model and every partner integration, and reversing it means rebuilding the data estate.

4. Deletion propagation. The ability to remove a user's data from every store — primary, replicas, backups, search indexes, derived aggregates, trained models, partner systems. Every new store must participate in the deletion workflow from the day it is created, which requires it to be a platform requirement rather than a checklist item.

5. Consent as an enforced input, not a record. Consent stored in a table that nothing consults is a compliance artefact. Consent evaluated at the point of use, so a withdrawal actually stops the processing, is a design decision that touches every pipeline.

The genuinely hard problem: models

Behavioural data trained into a model does not have a delete operation. Removing a user's contribution means retraining, which is expensive, or accepting that their influence persists in some form.

The practical approaches: retrain on a schedule so influence decays with a bounded window; exclude identifiable individual signals from long-lived models; and be precise in the privacy notice about what happens to derived data. The failure is claiming complete deletion while trained models retain influence, which is a statement that will not survive scrutiny.

The architectural pattern

A privacy layer between collection and use: data lands with purpose tags and retention metadata, consumers request access by purpose, and the layer enforces what is permitted. This makes purpose limitation a mechanism rather than a policy, and it is the thing that must exist early.

The framing that helps engineers

Privacy is a data architecture property, not a legal review step. The questions — what do we collect, why, for how long, who can use it, how do we remove it — are design questions with technical answers. Treating them as a review gate at the end produces designs that cannot satisfy them, at the point where changing the design is most expensive.