Redaction and tool choice: building a safe-use checklist

By the end, you can

• Apply a redaction technique — removing, replacing or generalising an identifying detail — to a sample input before it is used with an AI tool (AF-4).
• Choose an AI product or account tier for a task based on the sensitivity of what remains after redaction, building on Lesson 2's retention and training check (AF-4).
• Build a reusable safe-use checklist that combines classification, necessity, retention and tool choice into a single before-you-send habit (AF-4).

Before you start

This is Module 4, Lesson 3 of 3, the module's closing lesson. It builds on Lesson 1's classification habit and Lesson 2's retention, training and sharing checks, and closes by assembling all three into one reusable checklist. It also draws on Module 2 Lesson 3's decision habit for when a task should not go to AI at all. This lesson does not require coding or technical setup.

Redaction: keeping only what the task needs

Lesson 1 asked whether a sensitive detail was necessary for the task at all; often the honest answer is that most of an input is necessary, but one or two details inside it are not. **Redaction** is the habit of removing, replacing or generalising exactly those details before sending the rest. OWASP's generative-AI security guidance recommends this directly as a mitigation against sensitive information exposure: **"Implement data sanitization to prevent user data from entering the training model. This includes scrubbing or masking sensitive content before it is used in training."** That guidance is written for how a product should treat data on its way into training — the same underlying move works just as well as something you do yourself, before you ever press send: delete a detail entirely if the task does not need it at all; replace it with a placeholder such as "[Client Name]" or "[Account Number]" if the task needs the shape of the sentence but not the real value; or generalise it — "a customer," "last quarter," "a mid-sized supplier" — if the task needs a rough sense of what the detail was without the specific, identifying version of it. The UK's ICO states the standard a redacted input should meet in its own words, in the data minimisation principle: **"adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed."** A well-redacted input is exactly that — enough detail for the task to succeed, and nothing more identifying than the task requires.

Tool choice: matching the tier to whatever remains

Redaction reduces sensitivity; it rarely removes it to zero. A contract clause with names and figures redacted out can still be recognisably *this client's* contract to someone who already knows the deal. That remaining sensitivity is what Lesson 2's retention and training check is for, applied now to what actually survives redaction rather than to the raw input. Anthropic's own documentation gives a concrete case: for its commercial products, including the API and Claude for Work, it states **"we will not use your chats or coding sessions to train our models, unless you choose to participate in our Development Partner Program"** — a different arrangement from its consumer product, where, as Lesson 2 described, routine training use is controlled by an opt-in setting but a safety-flagged conversation may still be used for Safeguards-team models regardless of that setting. The practical habit: the more sensitive the redacted remainder still is, the more that argues for a business or commercial tier with contractual data-handling terms over a free personal account — and if nothing available meets what the remaining content actually needs, that is itself useful information, not a dead end. Module 2 Lesson 3's decision habit already covers exactly this case: a task whose risk cannot be brought low enough for AI is a task for a named human decision-maker instead, not a task to force through the nearest available tool. OWASP's guidance on excessive agency states the same underlying principle for exactly this kind of high-impact gap: teams should **"utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken."** "No tier fits" is one concrete way that gap shows up in a data-confidentiality decision specifically.

Building the safe-use checklist

Putting Lessons 1 through 3 together produces one reusable checklist to run before sending anything you are not already confident is safe:

• **Classify.** Which sensitive-data categories does this input touch — personal data, confidential business data, credentials or secrets, regulated or privileged data?
• **Check necessity.** Is each sensitive detail actually required for this specific task, or can it be trimmed out entirely?
• **Redact what remains.** For anything necessary but still identifying, remove, replace or generalise it rather than sending the specific real value.
• **Check retention and training.** For the specific product and tier you are about to use — not "AI tools" in general — is it used for training, how long is it retained, and who can access it during that time?
• **Match the tool to what's left.** Does the account tier's protections fit the sensitivity of what remains, after redaction? If nothing available fits, that is a signal to keep this task with a named person instead of forcing it through an AI tool.

A worked example: a consultant's contract summary

A solo management consultant has a signed client services contract and wants an AI tool to pull the deliverables and deadlines into a bullet list for their own project tracker. The contract text includes the client's registered company name, the authorising signatory's name and email address, a confidential day-rate figure, and a bank account number used for invoicing.

Running the checklist: **classify** — the input touches personal data (the signatory's name and email), confidential business data (the day-rate) and regulated financial data (the bank account number). **Necessity** — the stated task, extracting deliverables and deadlines, needs none of those four details; it needs the clauses that describe what is being delivered and by when. **Redact** — the consultant removes the bank account number and day-rate entirely, and replaces the company name and signatory's name with placeholders such as "[Client]" and "[Signatory]," keeping the deliverable and deadline clauses as written. **Retention and training** — the consultant checks that the AI product they plan to use is a business-tier account, not a free personal one, since even redacted contract clause language is still recognisably this client's deal. **Tool match** — the business tier's terms cover this level of remaining sensitivity, so it goes ahead; had only a free consumer tier been available, the safer move would have been to redact further, or to extract the deliverables and deadlines by hand instead.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. LLM02:2025 Sensitive Information Disclosure — OWASP Gen AI Security Project. Recommends data sanitization — scrubbing or masking sensitive content — as a mitigation against sensitive information disclosure, the basis for this lesson's redaction technique.
2. How do you use personal data in model training? — Anthropic Privacy Center. States that Anthropic's commercial products are not used to train models by default — a different arrangement from its consumer product's opt-in-plus-safety-flag conditions — reused here as this lesson's worked example of matching a tool tier to remaining sensitivity.
3. "Principle (c): Data minimisation" — Information Commissioner's Office (ICO). States the UK GDPR data minimisation principle, reused here as the standard a redacted input should meet — adequate, relevant and limited to what the task needs.
4. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop control requiring a person to approve high-impact actions, the basis for this lesson's point that a task with no tool tier fitting its sensitivity should stay with a named person rather than be forced through the nearest available tool.