Writing a Practical AI Policy for Your Company

A workable AI policy answers one question for every employee: what am I allowed to do with these tools, and where do I have to stop? If your policy doesn't answer that in plain language on a single page, it isn't a policy — it's a document that exists so someone can say a policy exists. The goal here is the opposite of that. Your people are already using AI, whether you've blessed it or not, and the choice isn't "AI or no AI" — it's "in the open with guardrails" or "in the shadows on personal accounts where you have zero visibility." A good policy pulls the usage into the light and makes the safe path the obvious one. Below is what to put in it, section by section, and how to keep it short enough that people actually read it.

Start from enablement, not prohibition

The instinct when writing rules is to reach for the ban list. Resist it. A policy that reads as one long "do not" teaches your team that the company sees AI as a liability to be contained, and smart people respond to that by using their personal ChatGPT accounts on their phones and never telling you. Now the work is happening with less oversight than before you wrote anything.

Frame the policy as "here's how to use these tools well and safely," because that's what earns compliance. You want employees getting the productivity — the point of adopting AI at all is covered in automating your business with AI and the broader operator's leverage playbook — and you want it happening on accounts you control, with rules everyone knows. Safety and enablement aren't in tension here. The safe path and the useful path are the same path if you build the policy right.

Section 1: Approved tools

Name the tools people may use, and name them specifically. "Use good AI tools responsibly" is not a policy; "Approved: [the business-tier accounts your company pays for]; ask before using anything else" is. Listing the approved set does two jobs at once — it tells people what's blessed, and it gives you a natural gate on everything else without having to predict every tool that will launch next quarter.

The single most important line in this section is the business-account requirement. Consumer free tiers often reserve the right to train on what you type; business and enterprise tiers typically contract that away and give you admin control. Pay for the real accounts, require their use, and most of your data-leakage risk disappears before you've written another word.

Section 2: What data may and may not go in

This is the section that prevents the incident that ends up in a headline. Be concrete, and lead with the red lines. Keep out of any tool that isn't contractually private: customer personal information, payment and financial data, health or other regulated records, credentials and keys, source code you don't want copied, and anything under an NDA. Then give the safe default in one sentence — public, non-sensitive material is fine; anything that identifies a real person or exposes the confidential inner workings of the business stays out unless the tool is a contracted business tier that won't retain or train on it.

Two things make this stick. First, a "when in doubt, leave it out, and ask [name]" rule, so nobody has to guess in the gray zone. Second, an honest acknowledgment that the business-tier tools change the calculus — the whole reason to pay for them is that they let more data in safely. The deeper reasoning on what's actually risky lives in is AI safe to use; the policy just needs the operational version.

Section 3: Disclosure and labeling

Decide when AI-assisted work has to be flagged, and set the bar by category rather than by sentence. Internal drafts, brainstorming, and personal productivity need no label — that way lies absurdity. Work that goes to a customer, gets published under the company's name, or feeds a decision someone will rely on should carry a light note that AI assisted and, crucially, that a named human reviewed it and stands behind it.

The purpose isn't confession, it's accountability. A reader — or a regulator, or you six months later — should always be able to find the human who owns what was said. The thing you're actually prohibiting is AI-assisted output with no human owner attached to it. If you operate in a field with its own disclosure rules, those override your internal preference, so name them here rather than leaving people to guess.

Section 4: Human review before it leaves the building

Some output can go straight out; some needs a person to sign off first. Draw the line the same way you'd draw it for a new junior employee's work: by cost and reversibility. Anything external, legal, financial, or regulated gets human review before it ships — customer-facing copy, contracts, financial figures, medical or legal claims, public statements. Low-stakes, easily-undone internal work doesn't need a gate.

State plainly that AI output can be confidently wrong, so the reviewer is checking facts, figures, and claims, not just tidying grammar. Name who the reviewer is for each category — a claim that "someone" will check it is a claim that no one will. This mirrors the human-in-the-loop principle from shipping AI guardrails in production — put a person between the machine's output and any real-world effect that would be expensive to get wrong.

Section 5: Security basics

Keep this short and behavioral. Use the company's approved business accounts, never a personal login for company work. Don't share seats or credentials. Turn off model-training on your data wherever the tool allows it. Don't paste secrets, keys, or passwords into any prompt. Treat anything an AI tool tells you to do — click this, run that, email this person — with the same skepticism you'd apply to an unexpected email, because tools that browse or read documents can be fed malicious instructions. Five plain rules beat a security essay nobody finishes.

Section 6: Who to ask, and keeping it current

Name one person or channel that owns "is this okay?" questions and answers them without judgment. A policy with no living owner calcifies the day tools change, which is roughly every quarter now. Put a review date on it and actually revisit it — new approved tools get added, red lines get sharpened by real situations, and the document stays trusted because it stays true.

The one-page template

Put it in this order, one screen if you can: purpose (two sentences on enabling safe use) · approved tools · data that may and may not go in · disclosure and labeling · human-review requirements · security basics · who to ask and the review date. That's the whole thing. If it runs past a page, cut words, not sections — every section here earns its place, but none of them needs a paragraph where a sentence works.

A short policy people read and follow beats a thorough one that lives unread in a shared drive. Adopt one, name an owner, walk the team through it in five minutes, and revise it as the tools move. This is general operational guidance, not legal advice — if you're in a regulated field or the policy touches anything contractual, have counsel review and adapt it before it's final. For the wider set of operator questions this connects to, see the AI for operators FAQ.

FAQ

What should a small business AI policy actually cover?

Six things, and it fits on one page: which tools are approved, what data may and may not go into them, when AI-assisted work has to be disclosed or labeled, what output requires a human to review before it leaves the building, the security basics (business accounts, no shared logins, opt out of training where you can), and who to ask when something isn't covered. Skip the legal boilerplate and the philosophy. If a new hire can read it in three minutes and know what to do on Monday, it's the right length. A policy nobody reads governs nothing.

What data should employees never put into a public AI tool?

Anything you'd be uncomfortable seeing on a competitor's screen or in a breach notice: customer personal information, payment or financial data, health or other regulated records, unreleased plans, source code you don't want copied, passwords and keys, and anything covered by an NDA. The safe default is a whitelist mindset — public, non-sensitive material is fine; anything identifying a real person or the business's confidential inner workings stays out unless you're using a business-tier tool with a contract that says the data won't be trained on or retained. When in doubt, leave it out and ask.

Should we disclose when work was made with AI?

Disclose by category, not on every sentence. Internal drafts, brainstorming, and personal productivity don't need a label. Work that goes to customers, gets published under the company's name, or informs a decision someone relies on should note that AI assisted and, more importantly, that a named human reviewed and stands behind it. The point isn't confession — it's accountability. A reader should always be able to find the person responsible for what was said, and AI-assisted work with no human owner is the thing to prohibit.

Do we need a lawyer to write an AI policy?

You can write a solid internal usage policy yourself — the six sections here are operational, not legal. But if you're in a regulated field (health, finance, law, anything touching protected data), or the policy will govern anything contractual or customer-facing, have counsel review it before it's final. Treat a template as a starting draft to adapt with your lawyer, never as legal advice. The version your team follows day to day should be plain-English and short; the compliance-grade language, if you need it, can live in a separate appendix.

How do we get people to actually follow the AI policy?

Make the compliant path the easy path. Pay for the approved business-tier tools so nobody reaches for a personal free account to get their work done, keep the policy to one page so it's actually readable, and pair it with a five-minute walkthrough instead of a signature drive. Name one person to answer "is this okay?" questions without judgment, and revisit the policy every quarter as tools change. Enforcement by fear drives usage into the shadows where you can't see it; enablement with clear guardrails keeps it in the open.