What Data Should Stay Out of Public AI Tools?

Keep customer records, credentials, confidential business material, and regulated information out of unapproved public artificial intelligence tools. Permit sensitive uploads only through a specifically approved service and use case with documented data handling and access controls. Give employees safe alternatives and a reporting path, rather than relying on a vague instruction to be careful.

The National Institute of Standards and Technology (NIST) identifies data privacy, sensitive-information leakage, and third-party risks in its July 2024 Generative Artificial Intelligence Profile, NIST AI 600-1. Our recommended upload policy translates those concerns into a decision employees can make before pasting text, attaching a file, or enabling a connector (NIST AI 600-1).

What are the key takeaways?

• Approve the particular service, account plan, data category, and use case together.
• Use public or synthetic examples when they can answer the business question without exposing sensitive material.
• Review third-party access, data handling, and contract terms as part of procurement (NIST AI 600-1, Appendix A.1.3).
• Create a prompt reporting route for accidental uploads and preserve the facts needed to assess them.

Which data should employees avoid uploading?

Our default recommendation is to prohibit sensitive business information in unapproved tools, including secrets, customer records, confidential contracts, and restricted technical material. The policy should name recognizable examples from the organization’s work instead of expecting employees to interpret an abstract classification scheme.

Make the distinction between approved public information and information that happens to be easy to copy. A draft proposal, a customer support export, or a screenshot of an internal dashboard should not become approved merely because it is convenient to paste.

NIST describes the risk that generative artificial intelligence (AI) models may leak, generate, or infer sensitive information. Its profile also notes that combining information can create privacy concerns even when a particular sensitive fact was not directly disclosed by the user (NIST AI 600-1, section 2.4).

That is why our proposed rule covers combinations of details as well as obvious identifiers. Ask whether the remaining context would still identify a person, customer, transaction, system, or unreleased plan. If the answer is uncertain, use a synthetic example or seek approval rather than guessing.

Does every public AI service use data the same way?

Do not assume identical handling across services or account plans. Our recommended procurement approach is to verify the terms and settings for the exact offering before approving sensitive use, rather than making a blanket claim that every prompt is used for training.

NIST recommends due diligence and contracts addressing content ownership, usage rights, security requirements, and third-party risks. It also recommends maintaining an inventory of entities with access to organizational content and approved AI technologies and providers (NIST AI 600-1, GV-6.1 actions).

Ask what the service stores, how long it keeps it, who can access it, which subprocessors are involved, and what deletion means. Confirm how those commitments apply to prompts, attachments, generated outputs, feedback, support requests, and connected data sources.

Require an accountable owner to document the answers and unresolved issues. A statement about one service plan should not silently authorize a different personal account or browser extension. If the provider changes material terms or the organization expands the use case, reopen the review.

How can employees make a quick upload decision?

Use a short decision checklist with a clear stop condition. The following is our recommended employee workflow, not a legal classification standard or a claim that NIST mandates these exact categories.

1. Identify the material: is it approved public information, internal business information, regulated data, a credential, or someone else’s confidential material?
2. Confirm the tool: is this exact service and account approved for that data category and purpose? A familiar logo is not an approval record.
3. Reduce the input: can a public excerpt, synthetic example, or rewritten question achieve the same result without the original sensitive material?
4. Check the attachment and context: review hidden sheets, comments, screenshots, filenames, and surrounding narrative before submitting anything.
5. Check connected access: determine whether enabling a connector would expose more content than the immediate question requires.
6. Stop or proceed: if authorization is missing or unclear, use the approved alternative or ask the designated owner. Record an exception before the upload, not afterward.

What should a useful approved-tools register include?

Record enough detail that employees and reviewers can tell what is permitted without reconstructing a procurement conversation. We recommend listing the business owner, service plan, approved purposes, allowed data categories, prohibited inputs, access requirements, and review date.

Include the settings that support the approval and who can change them. Identify whether users may invite collaborators, create shared workspaces, publish outputs, or connect repositories and document stores. Each of those decisions should have an owner rather than an implicit default.

NIST’s third-party guidance recommends use-case-based supplier assessment, updated acceptable-use policies, and ongoing monitoring of deployed third-party AI systems. It also calls for incident-response planning with assigned responsibilities (NIST AI 600-1, GV-6.1 and GV-6.2).

Use the register as an operating document, not a purchasing trophy. Retire approvals that no longer have an owner, and provide employees a practical route to request a new use case. An approval process that never answers requests invites uncertainty rather than informed decisions.

What should happen after an accidental upload?

Create a prompt, non-punitive reporting path and assess the actual exposure. Our recommended first step is to capture what was submitted, when, through which account and service, and whether sharing or connector access was enabled.

Do not ask the employee to reproduce sensitive material in an ordinary support ticket. Use an approved channel and preserve only what the response team needs. If credentials were included, involve the responsible system owner to determine revocation and replacement actions.

Coordinate any deletion request with the incident lead, and record what the provider confirms rather than assuming a deleted chat eliminates every retained copy. Legal and privacy advisers should assess applicable notification duties based on the facts; the employee should not have to make that determination alone.

NIST recommends third-party AI incident-response plans that define ownership, communication, and alignment with applicable data-protection and reporting obligations. This supports preparing the workflow in advance rather than improvising after an upload (NIST AI 600-1, GV-6.2-003).

How would our SOC help without collecting every prompt?

Our U.S.-based security operations center (SOC) would start with the approved tool inventory, access model, and available security telemetry. For a hypothetical suspected upload, we would coordinate with the data owner to establish the account, service, timing, and potential information involved.

We would not claim that a network connection alone proves which text was submitted. We would also avoid creating an unnecessary central archive of sensitive prompts. The investigation should state what the available evidence establishes, what remains uncertain, and which owner must make the next decision.

This is a proposed response model, not a description of a client incident or a claim that every AI service exposes the same telemetry. The monitoring scope should be agreed with privacy, legal, and operations stakeholders before rollout.

How do you turn the policy into procurement requirements?

Ask prospective providers to explain how they support the approved-use register, access review, evidence retrieval, and incident escalation. Require them to identify the limits of their visibility and distinguish policy advice from technical enforcement.

Our virtual chief information security officer service can support ownership and policy design. The broader AI security checklist for regulated industries covers deployment governance, while the managed SOC pricing guide helps scope monitoring and response work.

What else should buyers know?

Should credentials ever go into an unapproved AI tool?

Our recommended policy is no. Use synthetic values for examples, and route accidental credential exposure to the system owner for assessment and appropriate revocation or replacement.

Is removing names enough to make a document safe?

Not necessarily. NIST describes sensitive information being inferred through combinations of data, so review the remaining context rather than treating name removal as a guarantee (NIST AI 600-1, section 2.4).

Does this policy mean banning all AI use?

No. We recommend approved tools and use cases, safe alternatives, and a clear request process. The goal is a deliberate data-handling decision rather than an unrestricted upload habit.

Who should own exceptions?

Assign a business data owner and security reviewer, with legal or privacy review where appropriate. Record the specific tool, data, purpose, conditions, and expiration or review trigger before use.

Need help defining the next step?

Bring your approved-tool list and proposed data categories to define a usable AI upload policy. Schedule a security review or Call 833-92-CYBER to discuss scope and ownership.