Protect sensitive data by deciding what the task truly needs, classifying the information, removing or substituting identifiers, using only approved services and configurations, and controlling retention, access, logs, and outputs. If the workflow cannot meet policy or legal requirements, do not send the data to the model.
Who this is for: Employees, managers, developers, and policy owners using AI with customer, employee, research, or company information.
- Data minimization should happen before a prompt reaches any external or internal model service.
- Provider contracts, product settings, and architecture must be verified for the exact approved environment.
- Generated output, traces, caches, and review tools can remain sensitive even after the original prompt is gone.
Classify the data and purpose
Identify personal information, credentials, confidential business data, regulated records, copyrighted material, security details, and contractual restrictions. Determine the lawful and approved purpose, who owns the data, and who may access it. A useful task does not automatically justify every available field.
Map the minimum information needed. A support-summary task may need issue category and timeline but not a full payment number or home address. Substitute synthetic examples during development. When identifiers are necessary for matching, consider controlled tokens that can be resolved only inside the approved system.
Verify the service environment
Confirm the exact product, account, project, region, API path, contractual terms, retention behavior, training-use terms, and administrative controls. Consumer and enterprise offerings may differ. Product behavior changes, so consult current official documentation and obtain security, privacy, or legal approval where required.
Restrict access with least privilege, separate development from production, protect keys, and monitor usage. Do not let employees route restricted work through personal accounts because the approved service is inconvenient. Document which data classes are permitted, prohibited, or require additional approval.
Minimize and transform inputs
Remove names, contact details, account numbers, secrets, unnecessary free text, and unrelated attachments before submission. Redaction must account for context: replacing a name may not anonymize a rare job title and location. Test whether remaining combinations can identify a person or reveal a confidential event.
Prefer local deterministic preprocessing for redaction when reliable patterns exist, followed by sampling and review. Do not ask the same external model to find secrets after the full unredacted document has already been sent. For high-risk data, use an architecture designed and approved for that classification or keep the task outside generative AI.
Protect the full lifecycle
Prompts can appear in application logs, observability traces, error reports, caches, evaluation datasets, support tickets, and screenshots. Define retention, encryption, access, deletion, and incident handling for each location. Mask secrets before logging and use privacy-safe identifiers for debugging.
Treat output according to the source sensitivity and new inferences it contains. Review who can export or share it. Audit access and test deletion. NIST risk-management practices can help teams govern and monitor the system, but organization-specific obligations still require accountable privacy, security, and legal owners.
Summarize customer complaint trends
A service manager wants themes from complaint tickets that include names, addresses, order IDs, and free-text medical details.
- Define the analysis purpose and determine that category, date band, product, and redacted narrative are sufficient.
- Remove direct identifiers and rare details, replace order IDs with controlled tokens, and exclude unrelated medical content.
- Verify the approved project, provider terms, retention configuration, access roles, and logging behavior with responsible owners.
- Generate aggregate themes with minimum group-size rules and prohibit output that reconstructs individual stories.
- Review results for re-identification risk, store only the approved aggregate, and delete temporary transformed inputs on schedule.
Sensitive-data AI intake form
Require approval of these fields before a sensitive workflow is enabled.
- Purpose and owner: business need, accountable owner, affected people, and approved use boundary.
- Data map: classifications, sources, minimum fields, identifiers, prohibited elements, and redaction method.
- Environment: provider product, project, region, terms, retention, training use, encryption, and access control.
- Lifecycle: prompt, output, log, trace, cache, evaluation copy, export, deletion, and incident path.
- Review: privacy, security, legal, domain, and periodic reassessment requirements.
Common mistakes
- Pasting a full record into an approved tool when the task needs only two non-identifying fields.
- Assuming deletion from chat history removes copies from logs, exports, caches, or evaluation datasets.
- Relying on a provider name alone without verifying the exact account, product, configuration, and terms.
Try one
A recruiter wants AI help rewriting interview notes that contain candidate health information. What should happen before use?
The workflow should stop until the purpose, necessity, employment rules, policy, and approved environment are reviewed by accountable owners. Unnecessary health information should be removed rather than merely hidden in the prompt. A strong answer considers source notes, output, logs, access, retention, and human decision responsibility. Evaluation should reject casual use based only on convenience or a generic confidentiality claim.
Sources
- NIST AI Risk Management FrameworkNIST framework for governing, mapping, measuring, and managing AI risk.
- OpenAI safety best practicesOfficial recommendations for moderation, testing, and human oversight.