- The part of a policy that decides whether it works is a data classification table. Generic advice to use good judgement is exactly what fails under time pressure.
- Seven short sections is enough for a business under fifty people. Anything longer stops being read, which makes it a document rather than a control.
- Consumer and business accounts of the same product carry different data commitments. OpenAI's business terms say business data is not used for training by default, and that is not the same promise a personal login gets.
- Write the three judgement calls out with answers. A customer email, an unreleased figure and a candidate CV cover most of what people will actually ask.
- The NIST AI Risk Management Framework is voluntary and useful as a spine. It is not a policy, and adopting it does not produce one.
Somebody in your business pasted a customer complaint into a chatbot last week to get help writing a reply. It was a reasonable thing to do. The reply was better than what they would have written tired on a Friday, the customer was happy, and the email address, the order number and a sentence about a medical reason for the return are now sitting in a conversation history on somebody else's servers under a personal account.
That is the actual problem an AI policy solves, and it is also the row a regulator now expects you to have covered, since the AI Act obligations that already apply include staff literacy rather than only high risk paperwork. Not misuse, not people writing nonsense with a model, not some hypothetical about deepfakes. It is well meant work with company data, done through whichever tool was open.
Why do most AI policies fail?
Because they answer the wrong question. A typical template opens with definitions, spends a page on responsible use principles, then says employees should exercise good judgement when handling sensitive information.
Good judgement is precisely what is unavailable at the moment of the decision. The person is halfway through a task, the tool is open, and the question in their head is narrow: can I paste this. A policy that does not answer that question in one glance has not been written for the situation it exists to govern.
The second failure is banning something people are already doing. A policy that says no external AI tools, in a business where four people use one daily, converts open use into hidden use. You lose the thing a policy is for, which is knowing what is happening.
What goes in it
Seven sections. Model text for each follows, and it is written to be adapted rather than admired.
1. Scope and definitions
Keep this to four sentences. The mistake is defining artificial intelligence, which nobody needs and which dates badly.
This policy applies to everyone working for or on behalf of [company], including contractors and temporary staff. It covers any tool that sends text, images, files or code to a third party service for generation, summarisation, transcription or analysis. This includes assistants built into software we already pay for. Where this policy conflicts with a client contract, the contract wins and you should tell [owner name] before proceeding.
The last sentence matters more than it looks. Client confidentiality clauses are the most common real constraint in a small business, and they are usually stricter than anything you would write yourself.
2. Data classes and what may leave
This is the section the whole document exists for. Four classes, named after what they are rather than after a security scheme nobody remembers.
| Class | What it looks like here | Approved hosted tool? | If you need help with it |
|---|---|---|---|
| Public | Published product copy, your own website text, price lists customers already see | Yes, freely | No restriction |
| Internal | Stock counts, order volumes, draft marketing plans, supplier names | Yes, with an approved tool | Use the approved list, nothing else |
| Confidential | Named customers, staff pay, supplier contract terms, unreleased figures | Only with written vendor terms we have read | Remove the identifying parts first, then ask |
| Restricted | Payment details, identity documents, health information, anything under an NDA | Never | Do it yourself or ask [owner name] |
Two design choices are worth explaining. The examples are drawn from your business, not from a generic list, which is the difference between a table people can apply and one they have to interpret. And the last column gives a route rather than a refusal, because a policy whose only answer is no gets routed around.
3. Approved tools and how to add one
The approved tools are listed at [link]. Using anything not on that list with Internal, Confidential or Restricted data is not permitted. To add a tool, send [owner name] the link to its terms covering data retention and model training, and the account tier we would be on. Approval usually takes two days. Tools are reviewed every six months.
Name the account tier explicitly, because it is where the commitment actually lives. OpenAI's enterprise privacy page states that business data from its business and enterprise products is not used to train models by default, with retention controls on some tiers. A personal login to the same brand of product is governed by different terms. Two people in your business can use what looks like the same tool under two different agreements, and only one of them is covered by what you read.
4. Disclosure of AI assisted work
You do not need to declare AI assistance on internal drafts, notes or code. You do need to declare it when: the output goes to a customer as advice, the output is a formal record such as a contract or an incident report, or a client contract requires it. Published marketing copy does not require a disclosure, but a named person must have reviewed it and is responsible for it.
That last clause is doing legal work as well as editorial work. Under the EU transparency rules, text published to inform the public on a matter of public interest carries a disclosure duty with an exemption where the content has had human review or editorial control and a person holds editorial responsibility. Naming a reviewer is the cheapest way to sit inside that exemption. Our piece on what AI text watermarking changes for the pages you publish covers how that interacts with vendors now marking their own output.
5. Human review, scaled to consequence
Low consequence work, such as internal notes and first drafts, needs no review. Medium consequence work, such as customer facing copy, product descriptions and support replies, needs a second person to read it before it ships. High consequence work, meaning anything that affects money, employment, safety or a legal position, needs a named reviewer who checks the substance, not the wording, and records that they did.
Grading review by consequence rather than by tool is what keeps this workable. It also survives the next tool. If you write the rule about a product name, you rewrite the policy every quarter.
6. Logging and retention
Where the tool supports it, use the company account rather than a personal one so activity is visible to [owner name]. Do not keep AI conversations as a record of a decision: if a conversation produced a decision, write the decision into the system where decisions live. Delete conversation history containing Confidential data once the task is done.
The middle sentence prevents a problem that arrives quietly. Chat histories become a shadow archive of business reasoning that nobody has classified, nobody backs up and everybody forgets is discoverable.
7. What happens when it goes wrong
Telling us about a mistake within a day is always better than not telling us. Nobody has ever been disciplined here for reporting that they pasted something they should not have. Deliberately routing around the approved tools list with Confidential or Restricted data is a disciplinary matter. If you think you have exposed customer data, contact [owner name] immediately, because we may have a notification deadline.
The first sentence is the one that pays for itself. You want to hear about the paste on the day it happens, while deleting the conversation still helps.
Three judgement calls, with the answers
Worked examples are what make a table stick, because they show the reasoning rather than the rule.
A customer email asking for a refund
Confidential, because it contains a named person and their purchase history. The answer is not no. The answer is that you paste the situation without the identifying parts: a customer bought a coat, wore it twice, wants a refund outside the window, and is unhappy. That version is Internal and gets you the same drafting help. Replace the name at the end, in your mail client.
An unreleased revenue figure you want summarised
Confidential and, in a listed company, potentially Restricted. The class is not really about the number, it is about the timing: the same figure is Public two weeks later. This is the case people get wrong because the data feels harmless, and the harm is not disclosure to the vendor but disclosure through a shared conversation link or a colleague's screen.
A candidate CV you want screened
Restricted, and this one is a hard stop rather than a judgement. A CV holds personal data provided for one narrow purpose, and running it through a general assistant is a different purpose. Screening is also a regulated use in its own right in several jurisdictions. The route in the last column is to do it yourself, and it should stay that way until you have a tool chosen deliberately for it.
Notice that two of the three answers were a rewrite rather than a refusal. A policy that teaches people to strip identifiers before asking gets used. One that teaches them to ask permission gets avoided.
How do you roll it out so people read it?
Send the table, not the document. The seven sections are what you keep on file; the data classification table is what people need on the day.
Four steps that take about a week. Circulate the one page version with a two line note saying what changed and why. Ask for an acknowledgement, which can be a reply, because the acknowledgement is what makes it a control rather than a suggestion. Walk through the three judgement calls in a normal meeting rather than a training session. Then diary a review for six months out and actually do it.
The review is where most of the value accumulates. Every question somebody asked in the meantime becomes either a new row in the table or a sentence in section three, and after two cycles the document reflects your business instead of a template.
What to do about the tools that were never approved
Every business that writes one of these discovers the same thing in week one: the approved list is aspirational and the real list is longer. Handling that badly is how a policy loses credibility on day one.
The move that works is an amnesty with a deadline. Ask everyone to reply with what they actually use, say plainly that nothing said in that reply causes a problem, and give it two weeks. You will get browser extensions, a transcription tool somebody signed up for personally, and at least one assistant embedded in a subscription the business pays for. Then classify what you got instead of banning it: most of it will be fine for Internal work, some will need a company account, and one or two will genuinely have to stop.
The reason to run this before publishing the final version is that your approved list becomes real rather than theoretical, and section three stops describing a fantasy. A list nobody can work from is the fastest way to teach a team that the policy is decoration.
Sizing the review requirement honestly
Section five is where small businesses over commit and then quietly stop complying. A rule that says all customer facing copy needs a second reader is easy to write and hard to sustain when there are three of you and forty product descriptions.
Two adjustments make it survivable. Batch the review rather than gating each item, so a weekly pass over everything published that week replaces a per item approval that never happens. And define review as checking the claims rather than reading every word, because the failure you are guarding against is a product description that promises something the product does not do, not a clumsy sentence.
Write the rule you will follow in your busiest week, not the one that sounds most responsible in a quiet one. A policy that gets suspended every December is teaching people that it is optional the rest of the year too.
Where a framework fits, and where it does not
You will be pointed at the NIST AI Risk Management Framework, which is worth knowing about and is not a policy. It is voluntary, released in January 2023, with a companion playbook and a Generative AI Profile published in July 2024 that identifies risks specific to generative systems. It gives you a vocabulary and a structure for thinking about risk across a lifecycle.
For a business of eight people it is a reference, not a project. The useful move is to borrow its insistence that risk management is a continuing activity with named owners, and to skip the apparatus. If you are large enough that this stops being true, our guide to what to build in the first ninety days of AI governance sets out the order to do things in.
Data protection regulators have their own view, and it is more directly binding. The UK Information Commissioner's Office publishes guidance on AI and data protection covering accountability, transparency, lawfulness, accuracy, fairness and data minimisation. Data minimisation is the one that maps straight onto the table above: the reason to strip a customer's name before asking for drafting help is not only that a vendor might see it, it is that the task never needed it.
Questions people ask
Do we need this if it is just me and one other person?
You need the table, which takes twenty minutes. You do not need the seven sections until somebody joins who was not part of the conversation that produced the habits. The moment to write the rest is when you hire, not when you reach a headcount.
Should we ban personal accounts outright?
Ban them for anything above Public, and provide the alternative in the same sentence. A ban without a company account is a ban on doing the work, which people will interpret correctly as not really meant.
What about tools that added AI without telling us?
This is now the common case, and it is why section one covers assistants built into software you already pay for. Once a year, go through your subscriptions and check which ones have grown a chat panel and what their terms say about it. Most businesses find at least two they did not know about. We wrote about the wider version of this problem in the keys your AI tools hold that nobody is watching.
How do we handle a shared conversation link?
Treat a share link as publication, because that is what it is. Anything shared from a conversation should pass the test you would apply to putting it on your website. That is not a hypothetical: our write up of shared chats turning up in Google's index traces exactly how a private looking link became a public page.
The version that survives contact
A policy is a control when it changes what somebody does at the moment of the decision, and a document the rest of the time. The table is the control. The sections are the file.
Which means the test of this is not whether you have written it. It is whether the person handling a difficult refund on a Friday afternoon knows, without looking anything up, that they can paste the situation and not the customer. If the answer is yes, the rest is administration. If your business also handles customer data through a storefront you did not build, the same question applies to the platform underneath it, and our security page sets out what we hold and what we never see.