Minimisation at inference, retention, and the deletion problem

A support assistant pastes the customer's entire profile into every prompt, including date of birth and full card number, on the reasoning that more context yields better answers. The exposure this creates is not one thing but four: the data is disclosed to the inference provider, it sits in a context window that can be steered by injected content, it lands in whatever logging and tracing the platform performs, and it is available to be echoed into the response. Reducing provider log retention to zero addresses part of the third exposure and none of the other three. Encrypting the payload in transit with a customer-managed key addresses none of them, because the provider necessarily decrypts to run inference.

Minimisation is the control that actually applies. Send only the fields the specific intent requires, and replace sensitive values with reversible tokens that the application resolves after the model responds. The model can reason about a card ending in a token placeholder perfectly well when the task is to explain a declined transaction; it never needs the digits. The date of birth is needed only if the intent is identity verification, and that step belongs in the application, not the prompt. Answer quality survives because the fields you removed were not the fields carrying the meaning.

Designing retention that survives a review

An assistant that keeps full prompt and completion transcripts indefinitely for quality analysis has built an unbounded liability out of a bounded need. The defensible design has four parts. Define a retention period tied to the stated purpose, so the window is justified by the analysis you actually perform rather than by the possibility that someone might want the data one day. Redact or tokenise sensitive fields at capture, not later, because a redaction job that runs nightly means the raw data existed in the store overnight and probably in a backup. Enforce deletion automatically. And keep evidence that deletion executed, because a retention policy nobody can prove ran is a statement of intent.

The two tempting alternatives both fail for the same underlying reason. Retaining indefinitely with encryption at rest protects against theft of the storage media and nothing else: every authorised query, every subpoena, every future reuse of the archive and every credential compromise remains fully in scope, because the system decrypts for legitimate reads by design. Retaining indefinitely with access restricted to a named analytics group narrows who reads it today but leaves the volume, the retention and the future scope creep untouched, and group membership drifts. Retaining only completions is a misunderstanding: completions routinely restate the personal data that was in the prompt.

Erasure when the data is in the weights

A data subject exercises the right to erasure. Their records were in the corpus used to fine-tune a model that is already in production. The technically honest position starts with an uncomfortable fact: trained weights hold no per-record index. There is no key to delete against, no row to remove, and no reliable way to confirm from the outside that a particular record's influence is gone. A targeted delete issued against the model's parameters using the record identifier retained at training time is not a thing that exists.

That leaves three real options, and they should be presented as such. Remove the data upstream from every source and derived corpus, then retrain or fine-tune again from the cleaned corpus: the cleanest answer, and often expensive. Apply an approximate unlearning method that adjusts the model to reduce the influence of the target records: an active research area whose guarantees are partial, whose effectiveness must be evaluated empirically, and whose residual risk must be documented rather than assumed away. Or document a justification for not doing either, which is a legal position with real exposure and should be taken deliberately with advice, not by default.

Two positions to reject. That deletion from source systems is sufficient because trained weights are aggregate statistics that never constitute personal data: this is an argument sometimes made, but the memorisation evidence in the previous module undercuts it, and it is not a safe assumption to build a process on. And that erasure can be satisfied by an output filter suppressing that individual's details: this misrepresents an output control as an erasure. The filter is worth having as a mitigation while you retrain, and it should be described that way in the record, but the record inside the model is untouched and the filter fails the moment the request is phrased differently.

1. Locate every copyUse record-level lineage to find the subject's data in source systems, transcript stores, warehouses, evaluation sets, vector indexes, caches and every training corpus built from them. You cannot delete what you cannot enumerate.
2. Delete upstream first, with evidenceRemove from the primary and derived stores and record the execution. Note the backup expiry lag explicitly rather than claiming instantaneous deletion you cannot perform.
3. Rebuild the corpusRegenerate the training corpus without the records. The corpus hash changes, which is what lets you demonstrate that any future model was not trained on the data.
4. Decide the model route honestlyRetrain from the cleaned corpus where feasible. Otherwise choose an approximate unlearning method and evaluate what it actually achieved, or document why neither is proportionate. State which route you took.
5. Apply an interim mitigation and label it as oneAn output filter is a reasonable stopgap while retraining is scheduled. Record it as a mitigation, never as the erasure, because it leaves the record in the weights and fails against rephrasing.
6. Write down the residual risk and who accepted itWhatever route you chose, state what remains: unverified influence in the weights, backup lag, or reliance on an unlearning method with partial guarantees. Name the person who accepted it.

# Erasure request: the surfaces a complete response has to cover
request: erasure-2026-0142
subject_records: 37
propagate_to:
  - primary_datastore        # delete, evidence recorded
  - transcript_store         # delete, evidence recorded
  - analytics_warehouse      # delete, evidence recorded
  - vector_index             # delete vectors, chunk text and metadata
  - prompt_cache             # purge entries derived from these records
  - evaluation_datasets      # remove curated examples
  - training_corpus_v4       # remove; corpus hash changes
  - backups                  # scheduled expiry, documented lag
model_artefacts:
  finetune-support-v4:
    per_record_delete: not_possible
    chosen_route: retrain_from_cleaned_corpus
    interim_mitigation: output_filter   # mitigation, not erasure
    residual_risk: documented