Consent and Data Rights
Consent is a running deal, not a past checkbox: who agreed, for which use, and what happens when they take it back.
Why Does This Exist?
Models eat personal traces: messages, photos, health notes, locations. Early internet deals traded those traces for free services under long unreadable terms, and the same data later trained systems nobody had named. When a diagnostic note resurfaces in an ad model, the harm is not abstract. Someone shared for care and got scored for profit.
Data rights reset the deal toward stewardship: agree first, use narrowly, keep little, delete on request, and prove each step. This page covers that running deal. The privacy machinery around it lives in privacy in ML. The disclosure half lives in transparency and accountability. How outsiders check your claims lives in model auditing.
Think of It Like This
A library with recall slips
You lend a library your diary for one exhibit on street history, with a signed slip naming that exhibit. The library may show those pages, in that room, for that season. It may not photocopy the diary for advertisers, lend it to a theater group, or keep it after you file a recall slip.
Map it across: the diary is your data, the slip is opt in consent, the room and season are purpose limits, refusing extra copies is minimization, and the recall slip is erasure. Stewardship means the library holds your words under your terms and returns them on demand.
Where it stops: the library can hand back paper. A trained model cannot hand back influence on its weights without real work, which is why lineage and unlearning sit at the center of this page.
How It Actually Works
Consent is a small ledger attached to every record, checked before every use. Let be collected records. Let be withdrawals. Let be records usable for the agreed purpose A. Let be records usable for a new purpose B. Let be stored fields per record.
The four rules in order
- Agree first, plainly. Opt in names the data, the purpose and the keeper, with refusal as easy as acceptance. Pre ticked boxes and maze like declines do not count.
- Use narrowly. Purpose A never implies purpose B. A health note given for diagnosis cannot train an ad model without a fresh yes.
- Keep little. If the task needs an age band, store the band, not the birth date and street. Fewer fields mean smaller blast radius.
- Delete and prove it. A withdrawal must remove the record from stores and from training influence so far as the technique allows, and lineage must show where it went.
Data lineage
Lineage is the map from each weight update back to the records and slips behind it. Without it you cannot answer which models touched a withdrawn record. With it you can list affected sets, retrain or patch them, and show the auditor the before and after counts.
Worked example with twelve records
Collect records for purpose A, appointment reminders. Three people file withdrawals, so and . The team then proposes purpose B, marketing profiles. Nothing carries over, so without fresh consent. Four of the nine agree to B, giving . On fields, the form asked five items while reminders need three, so two fields should never have been stored. The diagram draws this as a ledger bar of twelve with three marked out, a gate that blocks purpose B at zero, and a second gate that passes four after fresh opt in.
Code
The ledger rule in a few annotated lines. Standard library only.
N: int = 12W: int = 3U_A: int = N - WU_B_without_consent: int = 0fresh_opt_in: int = 4U_B: int = fresh_opt_inprint(U_A) # -> 9print(U_B_without_consent) # -> 0print(U_B) # -> 4Nine stay usable for the first purpose. Zero carry to the new one without a fresh yes. Four move over after people agree again. The prints are the policy.
Watch Out For
Calling scrubbed data anonymous
Symptom: names go away, the set ships as safe, and a join on postal code plus birth year singles out rows again. Three coarse fields can isolate one person in a small sample. Fix: treat scrubbed sets as personal until tested, test joins against outside data, drop or coarsen quasi identifiers, and keep purpose A consent in force regardless.
Wearing users down into yes
Symptom: consent walls on every visit, a bright accept button and a grey maze for no, and acceptance rates near 100 percent that mean nothing. Tired clicks are not agreement. Fix: ask once per purpose in plain words, make no as quick as yes, and log the slip with its scope so model auditing can replay it.
The Quick Version
- Usable records equal collected minus withdrawn, here 12 minus 3 leaves 9 for purpose A.
- A new purpose starts at zero usable without fresh opt in, here rising to 4 after new yeses.
- Store the smallest fields that do the job. Our form kept two fields it never needed.
- Withdrawal must reach stores and training influence, with lineage listing every affected set.
- Scrubbed is not anonymous until joins and quasi identifiers are tested.
- One plain ask per purpose beats a wall of dark patterns that manufactures yeses.