Definitions

Definitions

Data flow

Results

Without the Luhn check, an order number, a tracking number and a block of digits inside an IBAN added 3 false positives (precision 81%).

1. The cheapest privacy control is not sending the field.
2. Detectors miss what they have no rule for, so redaction is a reduction of risk, not a guarantee.
3. Derived data is personal data too: summaries and embeddings built from a record must be traceable and deletable.
4. Tokens preserve function: the model can still tell that two mentions are the same person.

Design rules

• Inventory the copies (prompts, tool I/O, traces, memory, summaries, embeddings, eval sets, backups, provider logs) and give each an owner and a retention limit.
• Minimise first: build the model's context from an allowlist of fields per task.
• Tokenise before the model sees data, keep the vault and key outside prompts, logs and traces, and detokenise only at the boundary that needs the real value.
• Redact traces and logs before export (Level 9 module 8); capture prompt content only on purpose, with short retention and restricted access.
• Record lineage for every derived artefact so erasure and retention can follow it.
• Set retention by data class and enforce it with a job that you test.
• Validate detections (Luhn for cards, range checks for IPs) and measure precision and recall on your own data, per type and per language.
• Treat memory and eval datasets as data stores, with consent and deletion paths (Level 7).
• Check providers' data handling and regional rules, and document it; have the design reviewed for the laws that apply (module 10).
• Test the deletion path, including backups and caches.

Interview questions, with the follow-ups

Common mistakes

• Sending the whole customer record to the model.
• Logging full prompts and tool results forever.
• Deleting the source record but not its summary or embedding.
• Trusting a regex redactor (or a model) as complete.
• Storing the token vault next to the logs.
• Evaluating detectors on English test data only.
• No retention limit on traces and eval sets.
• Ignoring provider-side retention and region.

What the example does not do

• Small, hand-written, fictional corpus; the same person wrote rules and labels, so the 100 percent precision is optimistic.
• No named-entity recognition, non-English text, addresses, dates of birth or free-text identifiers.
• Vault in memory, with a fixed demo key; no key rotation, access control or audit.
• Erasure on an in-memory store, not on real databases, backups, caches or provider logs.
• No re-identification analysis: combinations of harmless fields can identify a person.
• No legal analysis, and no differential privacy or anonymisation guarantees.
• Optional real experiment (I did not run this): take 200 real (consented, internal) support tickets, label PII by hand and compare your detector with an NER-based one per type.

For the curious Detection is imperfect, so minimise first

Regex rules found 13 of 17 labelled items (recall 76 percent, precision 100 percent) on a 20-text set I wrote; they missed an obfuscated email, a name without a title and a spelled-out phone number. A Luhn check stopped order numbers and IBAN digit blocks being redacted as cards. The best defence is to not send the field at all: the three example tasks needed 2, 3 and 3 of 12 fields and none of the six personal ones. This is not legal advice.

What you must be able to say (one page)

• An agent system copies personal data in many places: the prompt, tool arguments and results, traces and logs, memory, summaries, embeddings and vector indexes, evaluation datasets built from traces (Level 9 module 2) and provider-side logs. Privacy engineering is about knowing every copy.
• Order of preference: do not send it, then hide it, then protect it. (1) Minimise: pass only the fields the task needs. In my example, 12 fields in the record; the three tasks needed 2, 3 and 3 fields and none of the six personal fields. (2) Pseudonymise: replace personal data with stable tokens and keep the mapping in a vault outside the prompt and logs. (3) Redact in logs and traces.
• Detection is imperfect, and I measured it. On a 20-text labelled set written by me (fictional data), regex rules found 13 of 17 labelled items with 0 false positives (recall 76 percent, precision 100 percent). It missed an obfuscated email ("alice at example dot test"), a name without a title, a spelled-out phone number and an IBAN. Because I wrote both the rules and the labels, treat these numbers as optimistic.
• Validation cuts false positives. Card numbers need a Luhn check: without it, an order number, a tracking number and a block of digits inside an IBAN were wrongly redacted as cards and precision fell to 81 percent; with it, 0 false positives on card-like numbers.
• Reversible tokens keep the agent useful. The vault replaces each value with a keyed token (<EMAIL_35beb7>), the same value always gets the same token within a vault, tokens differ across keys, and detokenisation can be limited by type at the point where a tool genuinely needs the real value (for example sending an email). Round trip and stability were tested.
• Erasure must follow lineage. With four stored copies for one customer (raw record, a summary made from it, an embedding made from the summary, and a log line), deleting the raw record left 3 copies; following derivation links removed all 4 and kept the other customer's record. Retention by age (a 30-day limit on logs removed the log line) is a second, independent control.
• Not legal advice. What counts as personal data, lawful bases, retention limits and erasure rights depend on the law that applies. From general knowledge (not re-checked here) regimes such as the GDPR give individuals rights over their data; module 10 looks at the current rules. Have counsel review any real design.
• Honest limits: regex detection, fictional data, small corpus, no named-entity model, no differential privacy, no provider-side retention analysis.