What Data Should You Put Into an AI Tool?

A small business can create a useful AI workflow and still make a poor data decision. The problem usually begins with convenience: somebody copies a customer email, contract, employee note, or spreadsheet into a tool because it makes the task easier.

The question should come first: Is this information appropriate for this tool, account, and workflow?

This guide is a practical operating framework, not legal, security, or compliance advice. If your business handles regulated, highly sensitive, contractual, or otherwise consequential information, involve the appropriate professional or internal owner.

Start with three data buckets

You do not need a 40-page information-security policy to make a better first decision. For a small pilot, classify the data as green, yellow, or red.

Green: low-risk information

Green data is information you would generally be comfortable sharing publicly or using in ordinary business communication.

• Public website copy.
• Public product or service descriptions.
• Generic templates with no customer details.
• Publicly available policies or FAQs.
• Invented or anonymized examples created specifically for testing.

Green does not mean “no rules apply.” It means the data itself is unlikely to be the reason you stop the pilot.

Yellow: business or personal information that needs a deliberate review

Yellow data can be appropriate in the right business-grade tool and configuration, but it should not be pasted into any random AI service without checking how the product handles it.

• Customer contact details.
• Internal business documents.
• Meeting transcripts.
• Contracts or proposals.
• Employee communications.
• Sales notes or CRM records.
• Operational financial information.

Yellow is where most real business use cases live. The answer is not automatically “do not use AI.” The answer is “know what tool and controls you are using before sending the data.”

Red: data that deserves a hard stop until the right owner approves it

Red data is information where misuse, disclosure, or incorrect handling could cause significant harm or violate a serious obligation.

• Passwords, authentication codes, private keys, or secrets.
• Full payment-card or bank-account credentials.
• Highly sensitive employee or customer records.
• Medical or similarly sensitive personal information.
• Documents subject to strict contractual confidentiality where tool use has not been approved.
• Information your security, legal, HR, finance, or compliance owner has explicitly restricted.

Do not use the existence of an AI feature as permission to upload information your organization would otherwise protect.

The five-question data check

Before information enters an AI workflow, answer these five questions.

Anonymization is useful—but do not overestimate it

Replacing a customer's name with “Customer A” can reduce exposure, but removing a name does not automatically make a document anonymous. A combination of address, job details, date, company, and unusual circumstances can still identify someone.

Use anonymization as one control, not a magic switch.

Worked example: turning a customer email into a reply draft

Imagine a home-service company wants AI to draft replies to incoming customer questions.

Bad first version

Forward the entire customer email thread, including full signature, phone number, address, previous messages, attachments, and internal notes, into an unreviewed personal AI account.

Better first version

1. Use an organization-approved account.
2. Pass only the latest customer question plus the minimum context needed to answer it.
3. Keep internal notes out unless they are necessary and approved.
4. Give the model an approved FAQ or policy source.
5. Require an employee to review the draft before sending.

The second workflow can still create value while reducing unnecessary data movement.

Worked example: summarizing a meeting

A transcript can contain far more information than the eventual summary requires: customer details, employee comments, pricing discussions, personal conversation, or confidential strategy.

Before making “record every meeting and send it to AI” the default, decide which meetings belong in the workflow at all. You may choose to exclude certain meeting types, limit recording, or summarize approved notes instead of processing the full transcript.

The hidden data problem: logs and integrations

Even when the AI tool itself is appropriate, the surrounding automation can create additional copies of the data.

A workflow might send information through an automation platform, write the prompt and response into logs, post an error message to a shared chat channel, or store a copy in a spreadsheet for debugging.

The safest AI tool can still be part of a poorly designed data flow.

Do not build policy around a brand name

Product features, account types, privacy settings, and terms can change. Avoid creating a permanent rule like “Tool X is safe” or “Tool Y is never safe.”

Instead, document the requirements: approved account type, acceptable data categories, necessary controls, human review, retention expectations, and who owns the decision. Then evaluate the current product against those requirements.

That approach also makes switching vendors easier.

A one-page AI data rule for a small team

A simple internal rule is better than no rule. For a small company beginning to experiment, it might look like this:

Your actual policy may need to be stricter. The point is to replace “everyone use common sense” with an explicit default.

Pre-upload checklist

How this fits with the rest of an AI pilot

Data handling is one part of readiness, not a separate afterthought. Use the AI readiness scorecard before live deployment and the tool buying framework when comparing vendors.

If the use case does not need AI in the first place, the safest data transfer may be no transfer at all. The AI vs. automation guide helps decide whether a rules-based workflow can solve the problem more simply.