Knowing What Not to Share: Sensitive Data and AI Use Boundaries

AI tools are useful because they respond to the material you give them. That is also the risk. A model can help summarize, rewrite, compare, or plan from source material, but the user still decides what material is appropriate to provide.

This lesson is not a legal policy. It is a practical habit: pause before pasting, uploading, or connecting data to an AI tool. Decide whether the tool should see the material at all, whether a safer substitute would work, and whether someone else owns the decision.

What Counts As Sensitive

Sensitive material is anything that could cause harm, violate an obligation, reveal private facts, or expose business value if it is shared with the wrong system or person.

Common categories include:

• personal information such as names, addresses, phone numbers, account numbers, employee records, or other details tied to an individual
• health, financial, education, legal, HR, security, or compliance-related material
• confidential business material such as contracts, strategy, internal plans, non-public product information, meeting notes, incident details, or negotiation context
• material owned by another party, including partner documents, customer files, licensed content, or examples shared under a business obligation
• access material such as passwords, API keys, tokens, connection strings, certificates, or recovery codes
• source material that looks harmless alone but becomes revealing when combined with names, dates, locations, project details, or internal identifiers

The exact policy depends on the organization. The habit is broader: if the information is not yours to expose, do not paste it into an unapproved tool.

Why AI Input Creates Risk

AI input can travel farther than a learner expects.

Depending on the tool and configuration, prompts, uploads, outputs, and tool actions may be stored, logged, reviewed for abuse, retained in chat history, routed to third-party services, or used in ways the user has not checked. Enterprise, API, consumer, local, and internal tools can have different rules.

Do not guess based on the brand name or the fact that a tool feels familiar. Ask:

• What tool am I using?
• Is it approved for this data type?
• What does it store?
• Who can access the prompt, file, output, or log?
• Can the data be used for model improvement, product analytics, support review, or abuse monitoring?
• Does the workflow call another service or tool after the model responds?

The answer may be acceptable. The point is to know before sharing the material.

A Fast Decision Gate

Before using source material with an AI tool, ask three questions.

Is It Identifiable?

Could this identify a person, account, organization, system, customer, vendor, project, or internal event?

If yes, either remove the identifying details, use an approved environment, or ask the data owner.

Is It Owned Or Restricted?

Did the material come from another party, an internal system, a private meeting, a contract, a licensed source, or a regulated workflow?

If yes, do not assume you can paste it into a tool just because you can read it.

Would Exposure Cause Harm?

Would it matter if the prompt, file, or output appeared in the wrong inbox, system log, training example, support ticket, screenshot, or public search result?

If yes, treat the material as sensitive until a responsible owner says otherwise.

Safer Patterns

Sensitive boundaries do not mean “never use AI.” They mean choose a safer pattern.

Redact

Remove names, account numbers, internal identifiers, addresses, links, and exact values that are not needed for the task.

Weak input:

Rewrite this complaint from Jane Smith at 214 Oak Street about invoice 900184.

Safer input:

Rewrite this customer complaint. Replace personal details with placeholders and keep the tone calm: [customer] reports a billing issue with [invoice].

Generalize

Describe the pattern instead of pasting the real material.

Weak input:

Here is the internal incident report. Tell me what went wrong.

Safer input:

I am reviewing an incident where a workflow skipped a validation step before a record update. What questions should I ask during a root-cause review?

Use Synthetic Examples

Create a fake example with the same structure and none of the real facts.

Use synthetic examples for prompt testing, training exercises, demos, and checklist design. They let you test the shape of the work without exposing the real source.

Work From A Summary

If the exact document is sensitive, summarize the non-sensitive pattern yourself first. Then ask AI to help with structure, questions, or review steps.

Example:

I have a three-page internal policy draft. It covers approval roles, exception handling, and audit records. Give me a review checklist for clarity and completeness. Do not assume the policy content.

Use Approved Tools And Workflows

Some organizations provide tools that are approved for specific data classes. Use those boundaries instead of treating every AI tool the same.

Approved does not mean automatic. It means the tool may be appropriate when the data type, access controls, retention rules, and workflow purpose match.

Prompt, Upload, Tool, And Output Boundaries

Sensitive data can enter an AI workflow in several ways.

Prompt Text

The obvious risk is what you paste into the chat box.

Check names, numbers, source excerpts, internal details, and copied messages before submitting.

Uploaded Files

Files often carry more than visible text. They may include names, comments, metadata, revision history, hidden sheets, screenshots, or embedded links.

If you would not share the whole file externally, do not upload it to an unapproved tool.

Connected Tools

An AI system with access to email, documents, ticketing systems, databases, calendars, or code can see and act on more than one prompt.

Ask what it can read, what it can change, what logs are kept, and what stops it when the task leaves scope.

Output

Output can also expose data. A summary may reveal private facts even after names are removed. A draft may combine details in a way that makes a person, project, or event identifiable.

Review the output before sharing it, especially if it was based on sensitive source material.

When To Stop And Ask

Stop when:

• the material includes personal, regulated, or confidential details
• you are not sure what the tool stores or who can access it
• the task involves legal, HR, finance, health, security, contracts, or public communication
• the prompt would include access material or system connection details
• another organization owns the source material
• the output might influence a decision about a person, customer, vendor, or system

The professional move is not “paste and hope.” It is to ask the data owner, policy owner, security team, manager, or project lead what boundary applies.

Practice: The Friday Deadline Paste

This drill is about the moment before the prompt. Nothing has been pasted yet. That is the best time to make the boundary decision.

Priya is an operations analyst at the fictional Example Operations Group. She has 30 minutes to prepare a short director summary from a quarterly incident packet. The packet contains a mix of material:

• aggregate shipment-volume trends for the quarter
• a summary of a Dock 4 warehouse injury involving three staff members
• an internal root-cause paragraph marked “Internal Only”
• a customer contract penalty clause
• a note that customer follow-up is not complete
• an aggregate injury count that might identify the incident because only one incident happened that quarter

Priya is tempted to paste the packet into a public AI chatbot and ask for a quick executive summary.

Unsafe Prompt Examples

Unsafe prompt 1:

Summarize this incident packet into five bullets for my director. Include the warehouse injury details, the internal root-cause explanation, the customer penalty clause, and the follow-up status.

Why it is unsafe: it asks the public tool to process personal, confidential, and third-party material without checking whether the tool is approved for those data types.

Unsafe prompt 2:

Summarize this incident packet. I removed the staff names, but keep the Dock 4 injury details, the internal cause statement, and the customer penalty language because they are important.

Why it is still unsafe: removing names is not enough. Location, timing, role, incident details, and rare events can still make people, customers, or contracts identifiable.

Classification Exercise

Classify each source element before deciding what the tool can see.

Use these labels:

• Public: safe to share broadly.
• Internal: not public, but may be safe in an approved internal workflow.
• Confidential: business-sensitive, customer-owned, contractual, security, incident, or restricted material.
• Personal: information about an identifiable person or event involving a person.
• Unknown: classification is not clear, so treat it as higher risk until an owner confirms.

Source elements to classify:

• aggregate shipment-volume trends
• warehouse injury narrative
• staff member names or role details
• internal root-cause paragraph
• customer contract penalty clause
• customer follow-up status
• aggregate injury count for a quarter with only one incident
• director’s request for a short summary

Learner Task

Produce three artifacts:

1. A classification list for the source elements.
2. A safer prompt rewrite.
3. An escalation or approved-tool decision.

For each source element, write:

Source element:
Classification:
Boundary decision:
Reason:

Then write:

Safer prompt:
Escalation or approved-tool decision:
Reason:

Safer Rewrite Pattern

The safer prompt should preserve the useful task without exposing the sensitive source.

Weak rewrite:

Summarize the incident but use placeholders.

Better rewrite:

I need a structure for summarizing an operations incident packet. The safe facts I can use are aggregate shipment trends and a generic note that the packet includes an operational incident, an unresolved root-cause review, and a contractual follow-up item. Create a five-bullet executive summary template with placeholders. Do not infer names, causes, liability, contract terms, dates, owners, or recommendations.

That request asks for help with structure. It does not ask the public tool to process the original packet.

Sample Answer

Classification list:

• Aggregate shipment-volume trends: internal. Boundary decision: can be used only if summarized without identifying a customer, site, contract, incident, or rare event. Reason: aggregate operational data may still reveal business activity when combined with other details.
• Warehouse injury narrative: personal and high-stakes. Boundary decision: do not paste into a public tool. Reason: it involves people and an incident.
• Staff member names or role details: personal. Boundary decision: remove from the public prompt and use only an approved workflow if policy allows. Reason: names, roles, and incident context can identify people.
• Internal root-cause paragraph: confidential. Boundary decision: do not paste into a public tool. Reason: root-cause analysis can expose internal operations, controls, or liability-sensitive details.
• Customer contract penalty clause: confidential and third-party-owned. Boundary decision: do not paste without contract owner approval and an approved tool. Reason: the clause belongs to a business relationship and may carry legal or commercial restrictions.
• Customer follow-up status: confidential. Boundary decision: generalize or ask the customer/account owner what can be summarized. Reason: unresolved follow-up can reveal customer relationship context.
• Aggregate injury count for a quarter with only one incident: unknown/high risk. Boundary decision: treat as sensitive until the incident owner confirms whether it can identify the event. Reason: aggregate does not always mean anonymous.
• Director’s request for a short summary: internal. Boundary decision: safe to describe as the task shape. Reason: the request itself does not require the sensitive source details.

Safer prompt:

I need a structure for summarizing an operations incident packet for a director. Use placeholders and do not assume facts. The summary needs to cover shipment trend, incident status, root-cause review status, customer follow-up status, and open owner questions. Create five concise bullets with [placeholder] markers where sensitive details would go. Do not include names, dates, contract text, legal conclusions, causes, or recommendations.

Escalation or approved-tool decision:

Do not paste the original packet into a public AI tool. If an approved internal AI workflow exists for incident and contract material, use it only within that policy. Otherwise ask the incident owner and contract/customer owner what can be summarized, or build the summary manually from a sanitized outline.

Rubric

Your answer is strong when it:

• classifies every source element instead of labeling the whole packet as one data type
• blocks personal, confidential, third-party, and unknown details from the public tool
• considers re-identification risk, not only visible names
• preserves useful task shape through placeholders, generalization, or synthetic details
• names an escalation or approved-tool decision with a reason
• avoids inventing safer facts that were not in the source

Common Mistakes

• Deleting names but leaving role, location, timing, or rare-event details that still identify the incident.
• Treating an internal AI tool as approval to paste every data class.
• Classifying the whole packet by the least sensitive item.
• Pasting first and planning to remove sensitive details from the output later.
• Asking the model for a final summary when the safer request is a template, checklist, or question set.

Self-Check Questions

Before prompting, ask:

• Could someone re-identify a person, customer, contract, site, or incident from what remains?
• Which source element has the highest classification?
• Am I asking the tool to process the real source, or only to help with structure?
• Who owns the boundary decision if the classification is unknown?

Completion Evidence

Save three items:

• the classification list
• the safer prompt rewrite
• the escalation or approved-tool decision

Add one sentence naming the detail that was easiest to underestimate. That is the detail most likely to leak under deadline pressure.

Reference Frameworks

Public frameworks can help teams ask better boundary questions.

The NIST Privacy Framework is useful for thinking about privacy risk and organizational controls.

The NIST AI Risk Management Framework is useful for connecting AI use to governance, mapping, measurement, and risk management.

The OWASP Top 10 for LLM Applications is useful for AI-specific security patterns, including prompt injection and data exposure concerns.

You do not need to memorize these frameworks before doing useful work. Use them as reminders that data boundaries are part of responsible AI use, not an afterthought.

Compact Exercise

Take one AI task you are tempted to try this week.

Write three versions of the prompt:

• the unsafe version with too much real detail
• the redacted version with placeholders
• the synthetic version with made-up facts

Then decide which version is appropriate for the tool you plan to use. If you cannot answer that, the next step is not prompting. The next step is asking who owns the boundary.