Classifying sensitive inputs

By the end, you can

• Sort a piece of information into at least one sensitive-data category — personal data, confidential business data, credentials or secrets, and regulated or legally privileged data — before it is used with an AI tool (AF-4).
• Explain why an AI system has no built-in ability to recognise that an input is sensitive, and so cannot be relied on to flag it (AF-4).
• Apply a classification check to a set of sample inputs, identifying which ones need a data-sensitivity check before they are sent to an AI tool (AF-4).

Before you start

This is Module 4, Lesson 1 of 3, the first lesson in this course's work on data and confidentiality. It builds on Module 1's vocabulary (rule, pattern, model), Module 2's three-question decision habit for whether a task is safe for AI, and Module 3's task-brief building blocks (goal, context, constraints). Nothing here requires coding or technical setup — the check this lesson teaches happens before you type or paste anything, not inside the tool.

Four categories of sensitive input

When people talk about keeping sensitive data out of an AI tool, personal data is usually the first thing that comes to mind — but treating it as the only category misses real risk. OWASP's generative-AI security effort names the fuller list directly: sensitive information "can affect both the LLM and its application context," and that includes **"personal identifiable information (PII), financial details, health records, confidential business data, security credentials, and legal documents."** For a working habit, it helps to group that list into four checkable categories:

One input can sit in more than one category at once. A customer support ticket that names a person and quotes part of their card number is both personal data and regulated data — classifying it is not a single yes/no question, it is naming every category that applies.

• **Personal data**: anything that identifies, or could identify, a specific person — a name, an email address, a phone number, a photo, a home address.
• **Confidential business data**: unreleased plans, internal figures, supplier terms, or anything your organisation would not want a competitor or the public to see.
• **Credentials and secrets**: passwords, API keys, access tokens, one-time codes — anything that grants access to a system or account.
• **Regulated or legally privileged data**: health records, financial account details, data covered by a specific law or sector rule, or material under legal privilege, such as draft legal advice.

The tool has no idea what's sensitive

It is tempting to assume a modern AI tool will notice when you have pasted in something risky and warn you. It won't, unless a separate feature has been explicitly built and enabled to do exactly that. The US National Institute of Standards and Technology (NIST) frames what an AI system fundamentally does: it is "an engineered or machine-based system that can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions." Nothing in that description includes recognising that a given input is sensitive, deciding not to use it, or pausing to ask you first. This is the same limit Module 1 described for facts and Module 3 described for unstated goals, now applied to sensitivity: the system does not already know what you did not tell it, and it does not independently judge what you hand it either. Classification is a check you perform before you send something, not a safeguard the tool performs for you.

Why this needs a habit, not just good instincts

Module 1 Lesson 2 introduced NIST's companion profile addressing risks specific to generative AI systems — the existence of a dedicated risk profile is itself evidence that data-handling risk in generative AI is treated as its own recognised category, not folded into general software risk. That is why this course teaches classification as a repeatable four-category check rather than leaving it to "use good judgement" — good judgement without a checklist tends to catch the obvious case (a name, a password) and miss the less obvious one (an unreleased figure, a privileged document) precisely when someone is moving quickly.

Why classification needs to happen before you type, not after

Once something has been sent to an AI tool, undoing that is often difficult or impossible — the details of what happens next are exactly what the rest of this module covers. That makes the classification check a *before* habit, not an *after* one. The UK's data protection regulator, the Information Commissioner's Office (ICO), states the underlying discipline in general terms as one of the core UK GDPR principles: personal data must be **"adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed."** The same discipline applies well beyond formal data protection law and beyond personal data alone: before pasting something into an AI tool, ask whether the specific facts you are about to include are actually necessary for this task — not just convenient to include because you already had them copied. Pasting an entire spreadsheet, an entire email thread or a whole contract, when the task only needs two rows, one paragraph or one clause, adds sensitive-data risk that the task itself never asked for.

A worked example: a support reply that almost went too far

A support agent is asked to draft a reply to a customer complaint using an AI writing tool. The quickest approach is to copy the customer's entire message — including their full name, email address, order number and a partial card number quoted in the complaint — directly into the tool, along with the instruction "write an apologetic reply."

Applying this lesson's habit first: the input contains personal data (the name and email address) and regulated data (the partial card number is financial account data). None of that is necessary for the task — the AI tool only needs to know what went wrong and what tone to use, not who the customer is or their payment details. A revised input keeps the complaint's substance ("a customer's order arrived damaged and they are asking for a replacement or refund") and drops the name, email address and card number entirely; the agent adds those back into the final reply by hand, outside the AI tool, where they are needed. The task is completed just as well, with three sensitive-data categories reduced to zero in what was actually sent.

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. Lists the categories of sensitive information an AI application can expose or be given: personal identifiable information, financial details, health records, confidential business data, security credentials and legal documents.
2. Artificial Intelligence Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as an engineered system that generates outputs such as predictions, recommendations or decisions — not a system that judges or flags what it has been given.
3. "Principle (c): Data minimisation" — Information Commissioner's Office (ICO). States the UK GDPR data minimisation principle — personal data must be adequate, relevant and limited to what is necessary for the purpose it is processed for — the basis for this lesson's "necessary for this task" check.
4. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — NIST. A NIST companion profile to the AI Risk Management Framework addressing risks unique to generative AI systems, referenced here as the reason data-handling risk needs a distinct, repeatable classification habit rather than case-by-case judgement.