Data classification questions to ask before every AI prompt

The most common AI governance incident I get called about is not a hallucination. It is not a hostile prompt injection, or a rogue employee doing something they shouldn't. It is a well-intentioned team member pasting internal data into a public AI tool because nobody had told them not to — and, more importantly, because nobody had given them a simple way to figure out whether they should.

Data classification is the specific layer of AI governance that sits between "here is our policy document" and "here is what I actually do on Tuesday afternoon at 3:15pm when I'm running behind on a deliverable and want to use ChatGPT to save twenty minutes." Most organizations skip this layer, or bury it inside a fifty-page policy nobody reads, and then are surprised when the incidents happen.

The checklist below is what I now teach every team I work with. It fits on one page. It can be adopted in a single meeting. And it has stopped every incident I would otherwise have been called about.

Why classification, not policy, is the leverage point

Most AI policies I read are written the way legal writes contracts — comprehensive, defensive, and functionally unusable by the person on the ground. They tell you what you can't do without giving you a decision procedure for the ninety percent of cases where the answer isn't obvious.

Classification flips this. Instead of asking "does this violate policy?" — a question the average employee cannot answer confidently — you ask "what class of data is this?" — a question they can answer in about thirty seconds if the classes are named well. Then the policy specifies what you can and can't do with each class. The employee's judgment call is reduced from "will this get me in trouble?" to "which of these four buckets does this fall into?"

That reduction is the entire point. Governance is only real when the person doing the work can execute it in the moment, without picking up the phone.

The five questions

Every prompt, before it goes into any AI tool, should be run through five questions in order. If the answer to any of them is "yes, and I'm not sure," stop and check with the AI owner on your team. If the answer to all five is a confident "no" or "yes and I know the rule," proceed.

Question 1: Does this prompt contain information that identifies a specific individual — client, patient, employee, or third party — by name, ID number, contact detail, or any combination of attributes that would make them identifiable?

This is the PII question. Names alone are borderline; names plus role plus organization are almost always PII. The failure mode here is not the obvious one — nobody I've trained pastes a Social Security number into ChatGPT. The failure mode is subtler: a stakeholder analysis that names six people at a client organization, a project risk brief that quotes an internal team member by name, a status update that mentions a specific patient case. Each of these is a PII disclosure to whatever third party operates the AI service, and each of these is done casually by well-meaning people every day.

Question 2: Does this prompt contain information that would harm the organization commercially if a competitor read it?

The competitive question. Pricing models, unreleased product features, deal terms with specific clients, internal financial projections, hiring plans, acquisition targets — any of these landing in a public AI tool's training data is a commercial exposure. The failure mode is treating this as an IT question. It is not. It is a business judgment question, and the person best positioned to answer it is the person writing the prompt, provided they have been trained to ask.

Question 3: Does this prompt contain information subject to regulatory or contractual restriction — HIPAA, GDPR, SOX, MNPI, attorney-client privilege, or a specific client NDA?

The compliance question. This one is not judgment. It is bright-line. If the answer is yes, the prompt does not go into a general-purpose AI tool, full stop. It goes into whatever the organization has approved for that data class — an enterprise deployment with data processing agreements, or nothing at all. The failure mode is teams treating this as an edge case that "probably doesn't apply to us." It usually does apply to at least one team's daily work, and usually nobody has said so out loud.

Question 4: Would this prompt cause harm if the AI's response, given verbatim to a customer or regulator, turned out to be wrong?

The stakes question. Some prompts are low-stakes: draft a brainstorm list, summarize this article for my own reading. Some are high-stakes: draft a customer response about a service failure, summarize the regulatory guidance for a compliance email. The classification here isn't about the input data — it's about the output's blast radius if it goes wrong. High-stakes outputs need a human review layer, an accountability chain, and a documented paper trail. Low-stakes outputs don't.

Question 5: Am I about to paste in something I received from a client, patient, vendor, or partner that they gave me for a specific purpose that doesn't include being processed by AI?

The consent question. This is the one teams most consistently miss, because it feels like an over-reach. It isn't. Data that someone shared with you for one purpose — a medical intake form, a legal document, a client-supplied dataset — is not by default authorized for AI processing. If your organization's contracts, privacy notices, and consent flows haven't been updated to cover AI use, you may be creating a compliance issue every time you paste that data into a tool.

What the checklist changes

Teams that adopt this checklist have three specific things start happening within about four weeks.

First, the number of high-risk prompts going into public AI tools drops sharply — not because people are less enthusiastic about AI, but because they are able to distinguish the safe prompts from the risky ones without having to ask permission for either.

Second, the questions that do come up ("is this class 3?", "does this cross the compliance line?") get routed to a single named person on the team — the AI owner — who is now doing five to ten quick judgment calls per week rather than fielding vague policy questions.

Third, when an auditor, a client's security team, or an internal risk review asks "how does your team handle sensitive data with AI?", the answer is a one-page document that names what gets checked before every prompt. This is a shockingly different position to be in from "here's our fifty-page policy."

The one meeting to adopt this

The adoption process I now use with every client fits into a single sixty-minute meeting. Fifteen minutes to walk through the five questions and get team-level agreement on which ones apply most acutely to this team's work. Fifteen minutes for the team to nominate its AI owner and agree on how questions get routed to them. Fifteen minutes to identify the three or four highest-risk prompt patterns the team currently uses and agree on which class of tool each one should go into. Fifteen minutes to write the one-page team-specific version of the checklist and agree on who reviews it in three months.

The output of that meeting is not a policy. It is a decision procedure the team can execute in real time. That is what governance is supposed to be, and it is the layer most organizations skip entirely.

Adopting this checklist will not fix everything about your AI governance. There are structural questions — enterprise tooling, DPAs, model selection, monitoring — that sit above it. But it will fix the most common incident category I get called about, and it will do so without adding a single approval step or slowing down a single legitimate use case.

That is a better return on one meeting than almost anything else you'll do this quarter.

---