Skip to content
AI360XpertBeta

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.

Twelve records with three withdrawals leave nine usable for the first purpose and zero for a new purpose without fresh opt in.
Twelve records with three withdrawals leave nine usable for the first purpose and zero for a new purpose without fresh opt in.

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 NN be collected records. Let WW be withdrawals. Let UAU_A be records usable for the agreed purpose A. Let UBU_B be records usable for a new purpose B. Let FF 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 N=12N = 12 records for purpose A, appointment reminders. Three people file withdrawals, so W=3W = 3 and UA=N−W=12−3=9U_A = N - W = 12 - 3 = 9. The team then proposes purpose B, marketing profiles. Nothing carries over, so UB=0U_B = 0 without fresh consent. Four of the nine agree to B, giving UB=4U_B = 4. 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)  # -> 4

Nine 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.