If you want help rewriting an incident summary, remove or generalise identifying details before using an approved AI service. Keep the structure needed for the task, then check whether the remaining combination of details could still identify a person, organisation or event.
"Just don't paste sensitive information" is not a control
A policy that says only "don't put confidential information into AI tools" fails the same way any policy fails when it gives no method for compliance. Staff under deadline pressure will make their own judgement call about what counts as sensitive, and that judgement will be inconsistent, because nobody has told them what "sensitive" actually means in this specific context, and nobody has given them a faster path than not using the tool at all. Give staff a usable process for checking the information, the approved service and the task. A quick screening step can identify a problem, but it cannot certify that complex information has been safely anonymised.
What needs anonymising, and what doesn't
The instinct is to strip everything specific out of a prompt "to be safe," which usually produces a prompt so generic the answer is useless. The distinction that matters is between identity and structure. Identity — who, which organisation, which site, which individual — is almost always safe to remove without affecting the quality of the answer, because the AI tool's job, whether that is tightening language, suggesting a structure, or checking logic, does not depend on knowing who the client actually is. Structure — the sequence of events, the relationships between cause and consequence, the actual numbers that show scale or severity — usually needs to stay, because that is what the tool is actually reasoning about. Anonymising a prompt by deleting structure instead of identity is the most common way people wreck the answer and then conclude AI tools "don't understand" their work.
Replacing names with reversible placeholders is pseudonymisation, not proof of anonymity. The OAIC’s de-identification guidance explains that re-identification risk depends on both the data and the environment in which it is released.
Reducing identifying detail: a four-step method
- Substitute identifiers consistently. Replace the real organisation, site and individual names with placeholders — "Organisation A," "Site 1," "the contractor" — and use the same placeholder every time that entity appears in the prompt. Inconsistent substitution, calling the same site "Site 1" once and "the northern facility" a paragraph later, can let a model, or a human reader later, reconnect the pieces.
- Generalise precise details that don't change the analysis. An exact date, a specific dollar figure, or a precise headcount is often identifying without being analytically necessary. "Early in the contract, before the annual security review" usually does the same analytical job as an exact date, without pinpointing which contract at which organisation.
- Preserve relationships and structure. Keep the sequence, the cause-and-consequence logic, and any numbers that describe scale or severity relative to each other, such as three incidents in six months rather than one. Preserve only what the task requires. If a distinctive sequence or set of numbers could identify the event, generalise it further or use a synthetic example.
- Keep the mapping key separate and secure. If you need to reverse the anonymisation later, to insert the real names back into a finished draft, keep that mapping in a separate, appropriately controlled location, not in the same document or chat history as the anonymised prompt.
Worked example
Consider this fictional incident summary being prepared for a board report.
Before anonymisation:
"On 14 March, a contractor from Ferrow Logistics used an access card issued to a former employee, Dana Ricci, to enter the Blackwood Street depot after hours. The card had not been deactivated since Dana's departure eleven weeks earlier. CCTV footage confirmed the entry but no alarm was triggered."
After anonymisation:
"A contractor from a third-party logistics provider used an access card issued to a former employee to enter a depot after hours, several weeks after that employee's departure. CCTV footage confirmed the entry but no alarm was triggered."
The revised version keeps the sequence useful for editing, but removing direct identifiers does not prove anonymity. Someone with other knowledge might recognise the incident from the remaining details. Check the release context and use a synthetic example where the service is not approved for the real information.
When anonymisation is not enough
Some categories of information should not go into a general-purpose AI tool at all, however well you anonymise the surrounding text, because the sensitivity is in the content itself rather than in whose name is attached to it: classified or nationally sensitive material, health information, credentials and access details, and anything covered by a specific confidentiality obligation to a client that would be breached by the tool's own terms of use, regardless of anonymisation. The judgement call is not always obvious in the moment, which is exactly why a fast, repeatable test, rather than a case-by-case debate, is worth having before the prompt gets typed, not after it is sent.
Check the output, not just the input
Anonymising the prompt is only half the job. The answer that comes back can reintroduce specifics you never typed, because a well-anonymised prompt still gives a capable model enough to infer or invent plausible-sounding detail — a name, a date, a location — that reads as authoritative but is not something you provided and not something you have verified. Before using any AI-generated text in a real document, check it against two questions: does it contain any specific fact, name or figure you did not put in, and if so, is it correct or fabricated. Treat anything the tool added rather than reworded as a claim that needs the same verification as a fact from any other unverified source, not as information you can rely on because it sounded consistent with the rest of the answer.
Common mistakes
- Deleting structure instead of identity. Stripping out the sequence of events "to be safe" produces a vague prompt and a vague, low-value answer.
- Inconsistent placeholders. Using different labels for the same entity across a long prompt defeats the purpose of substituting it in the first place.
- No separate mapping key. Writing the anonymisation mapping in the same file as the anonymised prompt means anyone who sees one sees both.
- Assuming anonymisation fixes everything. Some content, such as credentials, classified material or health information, should not go in regardless of how well the names are stripped out.
- Treating this as a one-off decision. A long chat session can drift back toward specifics as follow-up questions get asked; the anonymisation discipline needs to hold for the whole conversation, not just the first message.
Get the field card
The SRMBOK AI Line Field Card is a free thirty-second, four-question test for whether something is safe to paste into an AI service, built around a Never / Only With Controls / Fine framework, with anonymisation guidance and a pre-delivery checklist. If you are building this into a team's day-to-day practice, pair it with Security Risk Management Policy Template (Free, One Page) so the expectation is written down somewhere staff can point to, and Spearphishing vs Phishing: What Staff Need to Be Able to Tell Apart if AI-related risk awareness is part of a broader staff training push. If the anonymised content originated from a security risk assessment, How to Scope a Security Risk Assessment (Free Template) is worth having alongside it.