AI usage policy for companies: 7 questions so your data doesn’t leak

A staff member pastes a customer contract into a public AI chatbot to get a quick summary. Someone else uploads a spreadsheet of employee salaries to have it reformatted. Neither one means any harm, but both actions may have just sent your company’s sensitive data to a third-party server with no way to get it back.

This is happening at companies right now, often without any policy in place to prevent it. Below are 7 questions to answer before writing your policy, plus a starting template.

Why this matters now

AI tools have become genuinely useful for everyday work, which is exactly why they spread through a company without anyone approving it first. Unlike a new piece of internal software, no one needs sign-off to open a chatbot in a browser tab and start pasting in text.

Question 1: What data are we actually worried about?

Not all company data carries the same risk. Group it into categories: customer personal data, financial figures, proprietary source code, unreleased product plans, employee data. Each category may need a different rule, rather than one blanket answer for "AI" as a whole.

Question 2: Which tools does the team already use?

Before writing any rule, find out what’s already in use. A policy written without this step usually gets ignored, because it doesn’t match reality. Ask directly rather than assuming, since usage is often higher and more varied than management expects.

Question 3: What does each tool’s data policy actually say?

Free and paid tiers often have different data handling terms. Some explicitly state that input data may be used for model training; others exclude business accounts from this by default. Read the specific terms for each tool your team actually uses, rather than assuming.

Question 4: What’s explicitly allowed?

Give concrete, specific examples: drafting a generic email, brainstorming a blog outline, summarizing publicly available information. Vague language like "use good judgment" leaves people guessing and inconsistent.

Question 5: What’s explicitly not allowed?

Equally specific: no pasting of customer personal data, no uploading of unreleased financials, no sharing of proprietary source code into a public AI tool. Concrete examples people can recognize in the moment matter far more than abstract principles.

Question 6: How will this actually be enforced?

A policy with no enforcement tends to be read once and forgotten. Decide who monitors this, how violations are reported, and what the consequence is, then make sure it’s consistently applied rather than selectively.

Question 7: How will people actually learn this policy?

A policy document sitting unread in a shared drive changes nothing. Walk the team through it directly, using real examples relevant to their own daily work, and revisit it periodically rather than treating it as a one-time announcement.

A starting template

Checklist before rollout

• Data categories identified and risk-ranked
• Actual AI tools in use across the team identified
• Each tool’s data handling terms reviewed
• Allowed and not-allowed examples written concretely
• Enforcement owner and process assigned
• Team walkthrough scheduled, not just a document sent out

Frequently asked questions

Do we need to ban AI tools entirely to stay safe?

Usually not. An outright ban tends to just push usage underground, where you have even less visibility. A clear policy on what data can and can’t be shared is generally safer and more realistic.

What about free AI tools versus paid ones?

Many free tiers use your input to train their models by default; paid business tiers often (but not always) exclude this. Always check the specific tool’s data policy rather than assuming based on price.

Who should own this policy internally?

Someone with both technical understanding and the authority to enforce it, often in IT or operations, working with input from whoever handles the most sensitive data.

How often should the policy be reviewed?

At least every six months, since AI tools and their data terms change quickly, and new categories of company data may need to be added as your product evolves.

What should happen if someone breaks the policy?

A clear, proportionate consequence that is actually applied, not just written down. An unenforced policy is quickly understood by the team as optional.