AI security · Practical guide
Protect Sensitive Data Before Using AI: A Practical Workflow
Before asking AI to improve a document, decide whether the information should leave its current location. This guide helps teachers and professionals prepare a smaller, safer input, check the tool and review the output. It uses entirely invented examples; no student, employee or customer records are needed.
1. Define the task before choosing the data
Write one sentence describing the work product you need. “Draft a feedback structure for a calculation exercise” is different from “assess this named student’s performance.” The first can usually be practised with a public criterion and an invented answer. The second involves an actual person and requires an approved process. Do not upload a whole class spreadsheet simply because it is the easiest file to find.
Make a three-column inventory on your own device: information item, why the task needs it, and proposed treatment. Use REMOVE when the item is unnecessary, REPLACE when an invented example will serve the learning purpose, and KEEP ONLY IN AN APPROVED WORKFLOW when the real detail is essential. These are working decisions, not a legal classification system. If you cannot explain why a field is necessary, leave it out of the practice input.
2. Recognise sensitive content beyond names
Look for direct identifiers such as names, email addresses and IDs, but also details that identify someone when combined: a rare job role, a specific incident date, a small class or a distinctive personal story. Commercial information can be sensitive without naming a person. Examples include unreleased prices, internal security diagrams, examination questions and customer contract terms. Credentials and access tokens are not useful context for an ordinary writing task.
Replacing a name with “Student A” does not establish anonymity. If a separate key or the remaining context reconnects the record to a person, it still needs protection. The UK Information Commissioner distinguishes pseudonymisation from anonymisation; its guidance is UK-specific and currently marked as under review. Use that distinction as a caution against overclaiming privacy, and ask your organisation’s privacy lead which rules and approvals apply locally.
3. Check the service, account and destination
Confirm the exact product and account approved for this kind of work. Approval for public lesson planning does not automatically cover student records, HR information or confidential contracts. Record who approved the use and what restrictions apply. If approval is absent or the product’s handling of your data is unclear, practise with independently invented material instead of experimenting with a real record.
Check the applicable terms and settings for storage, retention, training use, access by others, sharing links and connected services. A setting about model training does not answer every question about storage or access. Product plans and policies differ, so this guide does not promise that any particular free or paid service is private. A prompt saying “keep this confidential” cannot change the service’s technical controls or contract.
For connected tools, consider the full route: the chat service, a document store, an external action and the person who receives the result. OWASP’s sensitive-information-disclosure guidance recommends limiting data access and warns that prompt restrictions are not a dependable barrier. Keep permissions limited to the task; do not connect an entire drive to prepare a generic example.
4. Prepare a clean, minimal input
For practice, start in a new document with a public criterion and an invented response. This is easier to inspect than a redacted copy of a complex original. Do not send an unapproved service the original file and ask it to remove sensitive information: the disclosure would already have happened. If real material must be processed, follow your organisation’s approved redaction, review and transfer procedure.
Inspect the attachment as well as the visible prompt. Filenames, comments, revision history, hidden sheets, document properties and embedded objects can contain information outside the passage you intend to share. A coloured rectangle over text is not evidence that the underlying text has been removed. Reopen the actual export and check it using an approved local tool; where reliable sanitisation cannot be confirmed, use the clean fictional version.
Keep necessary technical meaning. For a packet-loss exercise, sent and lost counts are needed; the learner’s identity is not. For a policy summary, conditions and exceptions may be essential even if names can be omitted. Minimisation should preserve the facts needed for the task rather than producing an incomplete input that invites the model to guess.
5. Worked example: feedback without a class record
Imagine a fictional teacher wants a reusable feedback pattern. Their proposed attachment contains a learner name, learner ID, email address, previous grade, absence note and an answer to a packet-loss question. None of those personal fields is needed to design the pattern. The teacher does not upload that attachment. Instead, they create a fresh practice prompt with the public criterion “calculate a percentage and explain the denominator” and the invented response “12 lost out of 200 packets means 12% loss.”
The independently checked answer is 12 ÷ 200 × 100 = 6%. A suitable illustrative feedback draft is: “You identified the lost-packet count. To express it as a percentage, divide by the number sent and multiply by 100: 12 ÷ 200 × 100 = 6%. Now try 9 lost out of 150 and show your working.” The follow-up also gives 6%. These are constructed examples, not reported classroom results.
The teacher checks the arithmetic and tone before saving a generic feedback pattern. The draft should not assign a grade, infer motivation or mention an absence. Any later use with a real learner remains a separate decision under the institution’s approved workflow. The exercise demonstrates that a useful teaching resource can be developed without submitting a class record.
6. Review the output and manage copies
Read the output before using or sharing it. Check that it does not invent identities, reconstruct omitted facts or introduce unsupported claims. For this example, reject “the student missed class and therefore needs remedial support”: the input supplies no evidence for that statement. Verify calculations yourself rather than treating a fluent explanation as a checked result.
Treat generated content according to what it contains, not merely how it was created. NCSC secure-development guidance includes prompts, logs and generated material among assets that need appropriate protection. Store approved outputs in the intended location, restrict access and follow the relevant retention process. Downloaded copies and shared links deserve the same attention as the original chat.
If you realise real confidential material was sent to an unapproved destination, stop further sharing and contact the designated security or privacy contact promptly. Record the service, time and types of information involved without duplicating the sensitive content unnecessarily. Follow the organisation’s incident procedure. Do not assume deleting the visible chat proves that all copies or access have been removed.
7. Practice activity: build an upload decision record
Spend 15–20 minutes on an entirely fictional support scenario. You want AI to draft a generic reply to “I cannot sign in to the practice website.” Your invented ticket contains a name, email address, account ID, a screenshot with an access token, the public error text “Session expired” and an internal troubleshooting note. Do not create or use a real credential.
Step 1 — Write the intended output: a short general reply explaining the public session-expired message. Step 2 — Assign REMOVE, REPLACE or KEEP ONLY IN AN APPROVED WORKFLOW to each item and explain why. Step 3 — Write a clean prompt containing only the public error text and a request for a generic response; explicitly avoid claiming that any account was checked. Step 4 — Check the attachment decision, intended recipient and review owner. You can finish the exercise on paper without opening an AI service.
Explained example answer and three self-review checks
A defensible answer removes the name, email and account ID because a generic explanation does not need them. It excludes the screenshot containing the token and leaves the internal troubleshooting note in the approved internal system. It keeps only the public error wording in the practice prompt. A plausible draft asks the reader to return to the official sign-in page and contact support if the problem persists; it does not request passwords or assert that their account has been repaired. The reviewer must confirm the organisation’s actual support instructions before real use.
Check 1 — Necessity: can I explain why every included detail is required for the stated output? Check 2 — Destination: have I identified the approved service, account and sharing route, or chosen wholly fictional/public material? Check 3 — Residual information: have I checked the actual input and output for hidden content, indirect identification, credentials and invented claims? If any check fails, revise the package before submitting or sharing it.
Source scope and further practice
The primary sources below were checked on 31 October 2026. OWASP addresses sensitive disclosure in LLM applications; NCSC covers secure handling across an AI system’s lifecycle; ICO explains pseudonymisation in its UK data-protection context. Microsoft documents hidden content and the limits of its inspection tools. These sources support different parts of this workflow and do not certify a particular product or establish that a proposed upload is authorised. Recheck provider terms and your organisation’s requirements when using real information.
For another practice attempt, use a fictional meeting note or customer request. Aim to retain the task’s useful facts while removing the need to identify anyone. Compare your new prompt with the original proposed input and explain what you excluded, what you preserved and what still requires approval.
Reusable prompt
Select and copy this template, or customise your own using the free builder.
Use only the public or wholly invented material below. Help me draft a generic feedback pattern; do not assess a real person. Task: [specific output and audience]. Approved criterion: [public criterion]. Invented example: [fictional answer or scenario, with no real identifiers, credentials or confidential text]. Return: one evidence-based observation, one correction with any calculation shown, and one practice question with an explained answer. Do not infer identity, personal circumstances, ability or motivation. Do not assign a final grade. Mark missing information rather than inventing it. Finish with items the human reviewer must check. This prompt is not a privacy control: I must inspect and approve the input and destination before sending it.Open the prompt builder →
Pause · Think · Check
Test your understanding
Choose one answer per question, then check your reasoning. This is practice; scores are not saved.