At some point in the last year somebody at your company asked whether there is a policy on AI tools. The honest answer was probably no, followed by a search that produced a twenty-page template written for an organisation with a compliance department.
That document, if you adopt it, will be signed by everyone and read by nobody. Two months later half your team will be using tools it does not cover, in ways it does not address, and you will have a policy that provides the appearance of control and none of the substance.
What a thirty-person company needs is one page. One page gets read. One page gets remembered. One page can be updated in ten minutes when something changes, which at the current pace is every few months.
Why the long policy template fails
Three reasons, and they are structural rather than a matter of effort.
Long policies are written for organisations that have someone whose job is to enforce them. You do not have that person. A policy with no enforcement mechanism relies entirely on people remembering it, and people remember short things.
They are written to protect the organisation in a dispute rather than to guide behaviour on a Tuesday. Those are different documents. Legal coverage produces careful, hedged sentences. Guidance produces short, specific instructions. A salesperson deciding whether to paste a client email into a chat window needs the second one.
And they go stale fast. A detailed policy naming specific tools and specific features becomes wrong within months as products change, and a policy that is visibly wrong in one place gets ignored everywhere.
So write one page. Aim for something a new employee reads in three minutes and can summarise afterward.
The five things the page must say
One: what data must never go into an AI tool. Be specific and use your own categories, because a general instruction about confidential information means nothing to somebody holding a particular document. Name the things: client contracts, client financial information, employee personal records, anything covered by a signed confidentiality agreement, passwords and access credentials, unreleased pricing. Then give the positive version too, because a list of prohibitions leaves people guessing about everything else. Say what is fine: your own marketing drafts, public information, general questions, your own internal notes with names removed.
Two: which tools are approved. Name them. Two or three is enough. Say which account to use, whether the company pays, and how to get access. This is the section that prevents most shadow tool use, because people reach for their personal account when the company route is unclear or slow.
Three: who reviews AI output before it reaches a customer. The rule is that a named human takes responsibility for anything that leaves the building. Spell out what that review covers: facts checked against a source, any claim about what your company does or will deliver verified, numbers checked, and the tone made to sound like your company. Say who does it for each kind of output, whether that is the author, a manager, or a designated reviewer. The quality control process for AI content covers what a good review actually looks like in practice.
Four: when to disclose that AI was used. Make a decision rather than leaving it open. A reasonable position for most small B2B companies: no disclosure needed for internal drafts and routine business writing, disclosure when a client asks or when a contract requires it, and no AI-generated material presented as original research or as a personal testimonial. Whatever you decide, write it down, because the silence is what creates awkward moments later.
Five: who to ask. One named person, with their email. Every policy produces edge cases, and the page cannot answer them all. If there is no named person, people either guess or ask nobody. This is the cheapest line on the page and the most useful.
What your client contracts may already require
Here is the part most owners have not checked, and it outranks whatever policy you write.
Plenty of B2B contracts contain confidentiality clauses restricting how client information may be disclosed or transferred to third parties. Written before AI tools were common, those clauses were aimed at subcontractors and cloud services, and they can still cover sending client material into an outside AI service. Newer agreements, especially with larger clients, increasingly name AI tools directly, sometimes requiring notice or prohibiting the practice altogether.
Read your master service agreements before you finalise the page, and pay attention to any client in a regulated sector. Financial services, healthcare, and public sector clients often impose obligations that flow down to their suppliers, and those obligations do not care what your internal policy says.
There is a related point about the data protection law that applies to your business. The rules on handling personal information in British Columbia and federally in Canada set expectations about what you can do with personal data and where it is processed. Whether a given use of an AI tool meets those expectations depends on the data and the tool, so this belongs in a conversation with a lawyer rather than a blog post. What matters here is that you should have the conversation once, before a client asks the question in a procurement form.
Put the answer on the page in one line: for clients where a contract restricts AI use, name them or name the rule, so nobody has to remember.
Consumer account versus business account
The most consequential technical detail, and it fits in a sentence on your page.
The major AI providers handle content differently depending on the account tier. Their business and enterprise offerings generally commit in writing that content you submit is not used to train the underlying models, and they typically provide administrative controls, the ability to remove access when someone leaves, and clearer data handling terms. Consumer tiers, particularly free ones, often reserve broader rights, though most now offer a setting to opt out of training.
Those terms change, and they differ between providers and between tiers of the same provider. So the instruction on your page should not quote a specific clause. It should say: use the company account for anything work-related, and here is how to get one.
The practical case for a business account goes beyond the training question. You control who has access. When somebody leaves, you remove it, and their work history does not walk out with them. You can answer a client's procurement questionnaire truthfully. For a thirty-person company the additional cost is small next to the exposure it removes, and it is covered further in the guide to AI risk, privacy and policy.
Keeping the page current
A policy nobody revisits becomes wrong, and a wrong policy is worse than none because it teaches people to ignore the document.
Put a quarterly reminder in one person's calendar. Fifteen minutes, three questions. Are the approved tools still the right ones? Has anything changed in what we handle, such as a new client with stricter requirements? Has anybody hit an edge case the page does not cover?
Keep a short log at the bottom of the page: date changed and what changed. When somebody asks why a rule exists, the log answers it, and it also shows the document is maintained, which affects whether people take it seriously.
Update it when a real situation forces the question rather than waiting for the quarterly slot. The moments that produce the best policy language are the ones where somebody was genuinely unsure what to do.
Enforcement without policing
You are not going to monitor what people paste into a browser, and attempting it would damage trust for little gain. So the page has to work by making the right path the easy one.
Four things do most of the work.
Make the approved tool genuinely available. Same day access, no approval queue. Every hour of delay is an hour where somebody uses their personal account instead.
Explain the reason next to the rule. "Do not paste client contracts into AI tools because our agreement with several clients restricts sharing their information with outside services" gets followed. "Do not paste confidential information" gets interpreted, and interpretation drifts.
Make it safe to report a mistake. Somebody will paste something they should not have. If the response is disciplinary, the next person hides it and you lose the chance to tell the client or fix the exposure. Say on the page that reporting a mistake promptly is the expectation and carries no penalty.
Have the owner or a senior person visibly use the approved tool and visibly follow the rule. A policy that leadership ignores is a policy that does not exist, and everybody notices which one you have.
The takeaway
One page, five sections: what data must never go in, which tools are approved and how to get access, who reviews output before it reaches a customer, when to disclose, and who to ask. Write it in plain sentences that a new hire understands in three minutes.
Before you finalise it, read your client contracts. Confidentiality clauses written for subcontractors may already restrict what you can send to an outside AI service, and that obligation sits above anything you decide internally.
Then make the approved route fast, explain the reason beside each rule, and make reporting a mistake safe. My verdict: a one-page policy that people follow protects you far more than a twenty-page one that sits unread in a shared folder.