Category: Data protection · Worked examples and checklist
Imagine useful AI work with less identifying detail in every request. That ambition starts with a hard question: what does the model actually need to know? Replacing a name is easy to demonstrate. Deciding which surrounding facts still expose a person takes more care. This resource works through that decision and supplies a checklist you can use without any particular product.
The Irish Data Protection Commission’s explanation of anonymisation and pseudonymisation distinguishes replacement identifiers from data in which people are no longer identifiable. It also explains that identification can happen without a name, through other information that singles someone out. Treat the worked prompts below as risk-reduction examples, not a finding that the resulting text is anonymous or outside data protection law.
Begin with the task, then remove the unnecessary facts
A request to improve sentence structure usually needs less information than a request to compare the sequence of events in a complaint. Write the intended task in one sentence before preparing the prompt. For a writing task, consider a fictional substitute paragraph. For event comparison, replace identifiers and preserve only the relationships necessary to compare events. If the task depends on identity or highly distinctive circumstances, token replacement may be the wrong method.
All examples below are fully synthetic. Names, roles, places, references and events are invented; none refers to a real person or firm. The “before” versions illustrate material that should be assessed, not prompts readers should send to an external service. The “after” versions demonstrate choices, not universal approval to send them.
Example A: preserve the relationship, reduce the story
Before: “Rewrite this response to fictional client Mira Vale, account FICT-782. She owns a floating bookshop in the invented town of North Quay. Her transfer on 14 March was delayed while our team checked an address change. Apologise and explain the next steps.” Removing “Mira Vale” and the account reference would still leave a distinctive occupation, place and event.
After, for tone and structure only: “Draft a neutral response to CLIENT_A about a delayed service request. Include an acknowledgement, a plain-language explanation placeholder and a next-step placeholder. Do not invent reasons, dates, commitments or facts. Leave those as [REASON], [DATE] and [NEXT_STEP] for the case owner to complete locally.” No identity mapping is needed if the reviewer can insert the final details directly in the source workflow.
Residual exposure: the service can still see that someone is drafting a response about a delay, plus any surrounding conversation, account and connection context available through that service. It may also produce unsuitable wording. The reviewer checks the text against the case and the organisation’s correspondence rules before use. The prompt reduces detail; it does not decide whether the service arrangement is acceptable.
Example B: tokens that quietly reconnect separate cases
Before: “Compare the notes for CLIENT_458 across these three investigations.” A stable token reused across unrelated conversations lets a recipient connect all those facts even without knowing the person’s name. A token that contains an account number, initials or a recognisable pattern may reveal more. Replacing only display names while retaining email headers, document filenames or copied spreadsheet keys leaves other routes to identification.
After, for a bounded comparison: use task-specific labels such as CASE_A_PERSON_1 and CASE_A_PERSON_2, with a local worksheet recording which relationships must remain consistent within that task. Use a different mapping for a separate task unless a reviewed purpose requires linking them. Remove unrelated file properties and identifiers. If comparing case chronology requires exact intervals, use relative labels such as Event 1 and two working days later rather than silently changing the intervals.
Residual exposure: the events themselves can remain distinctive. Wider context may make the identity obvious. An assessment should consider likely recipients and information they may already have. If reducing the detail makes the comparison misleading, stop and choose a different workflow. An inaccurate transformed narrative is not a worthwhile trade for the appearance of privacy.
Example C: keep the mapping out of the request
Unsafe construction: “CLIENT_A means Mira Vale; now summarise CLIENT_A’s case.” A hidden sheet, attachment or tool response carrying that key has the same problem. The service receives both the label and the information needed to reverse it. Review the whole outbound bundle: system instructions, retrieved passages, attachments, tool arguments and conversation history. A clean-looking text box is only one part of a request.
Safer construction to assess: keep the mapping in a separately controlled local case store, send only the task-specific labels and allow an authorised reviewer to restore identifiers after checking the output. Keep restoration separate from model-generated instructions: an output asking to reveal a mapping should not gain authority to do so. Check that labels remain correctly associated, particularly when the output changes order or combines paragraphs.
Mapping-access worksheet
| Decision to record | Completed synthetic example |
|---|---|
| Purpose and scope | CASE_A tone rewrite only; no linked case analysis or training dataset. |
| Mapping needed? | No mapping retained for this task. Case owner completes placeholders in the original correspondence workflow. |
| If another task needs one | Assign a named store owner, location, permitted users, access method and permitted restoration purpose before creating it. |
| Provider access | Check that mapping files are absent from attachments, connectors, retrieval results, diagnostics and exports. |
| Lifetime and disposal | Set a purpose-based review or deletion trigger with the record owner. Do not inherit an unlimited lifetime from the chat history. |
| Failure path | Stop if mapping availability or outbound scope is uncertain; ask the security and privacy owners to resolve it. |
A prompt checklist that includes the surrounding system
- Purpose: describe the task and justify each fact it needs. Use synthetic material where it answers the question.
- Direct identifiers: inspect names, addresses, contact details, account references, signatures and document properties.
- Context: check rare roles, locations, dates, event combinations and quoted public material. Ask what an informed recipient could infer.
- Consistency: preserve relationships needed for the task, minimise cross-task linkability and avoid tokens derived from real identifiers.
- Complete payload: inspect attachments, extracted text, history, retrieval and tool calls. Verify what actually leaves.
- Service arrangement: resolve destination, provider access, retention, reuse and sharing. Transformation alone does not answer those questions.
- Restoration: restrict mapping access, check labels against source material and require a person to validate the final document.
- Stop condition: keep the task within an alternative controlled process when identity exposure or changed meaning cannot be reduced sufficiently.
The European Commission’s explanation of GDPR principles describes data minimisation, purpose limitation and storage limitation. The worksheet translates those themes into practical design questions; it is not a legal assessment. Synainesi’s vision puts this kind of boundary thinking at the centre of AI work. The choices above remain useful independently of that vision.
Related: all AI governance resources, our AI governance principles, the shadow AI response plan, what decision records can prove, and Pseudonymisation is not anonymisation.
General information, not legal advice. Adapt this resource to your organisation, activities and applicable requirements with qualified advisers. Every worked example and reference identifier is fully synthetic.