A policy is the output of about twenty decisions. Most people skip the decisions, download a template, fill in the company name, and end up with a document that is technically about AI but says nothing specific about their business. This page is the twenty decisions, in the order they need answering, with a worksheet you can run in an afternoon and a short-form policy at the end that assembles from your answers.
If what you want is the finished document with every clause already written and argued, that is the companion piece: the full AI acceptable use policy template, which also carries an analysis of what 24 published policies actually contain. This page is the working session that happens before it.
Almost everyone does this in the wrong order
There is a thread on r/ITManagers that describes the failure better than any vendor whitepaper. An IT manager tells staff at a monthly meeting that AI tools are fine as an aid but company data must not go into them. Months later he discovers employees working on paid ChatGPT licences, purchased through the CFO, in a company whose written IT policy already said every program needs IT approval before use. The policy existed. Finance approved the tool anyway. Nobody was being malicious.
The replies are the useful part. The consensus from other IT managers is blunt: people are going to use AI, and if IT says no, they will go around IT and IT will lose that argument to the executive team. So the practical move is to pick a provider, buy a company subscription, show the organisation you are enabling rather than blocking, and only then put a policy in place. Another commenter points out the causation directly: organisations have not provided the tools people are asking for, so people go and find their own. Source thread: AI usage by employees, policy and compliance on r/ITManagers.
That is the sequencing rule, and it changes what you write. Provide at least one sanctioned tool before the policy lands. A policy issued into a vacuum, where the only compliant option is to do less than you did last week, is not a control. It is a request to be ignored, and it will be, quietly, by the people you most need on side.
So decision zero, before the twenty below: what is the sanctioned tool, on a company account, that people can use the day this policy takes effect? If the answer is "none yet", stop and solve that first. Everything downstream is easier.
The licence tier trap, which catches almost everyone
One thing worth settling before the worksheet, because it silently decides how strict the rest of your policy has to be.
Consumer subscription tiers of the major AI tools generally use conversation content to improve the models by default, with an opt-out buried in settings. Business and enterprise tiers generally do not, and that difference is contractual rather than a preference toggle. Same brand, same interface, entirely different data posture.
This is why "we allow ChatGPT" is not a policy statement. A company where everyone is on personal Plus accounts and a company on a business tenant have the same tool name and completely different exposure. It also explains the situation in that thread: nobody had done anything against the rules as they understood them, because the rule referenced a product rather than an account type.
Write the rule against the account, not the brand. Check the current terms of the specific tier you are buying rather than trusting a summary, including this one, because these terms change.
The worksheet: twenty decisions in six passes
Run this as one session with whoever can actually decide, which usually means an owner or an operations lead rather than IT alone. It takes about ninety minutes honestly done. Every question exists because it writes a specific line in the policy, so nothing here is data collection for its own sake.
Pass 1: who owns this
- Who owns AI decisions here, by name? This person appears on page one with contact details and answers tool requests.
- Who is their backup when they are away for a week?
- Which functions exist and roughly how many people are in each? You need this to know whether one rule fits everyone.
- Is there a works council, union, or staff representative body that has to be involved before any monitoring is mentioned? In parts of Europe this gates the whole rollout.
Pass 2: what is already happening
- Which AI tools are actually in use right now, sanctioned or not? Ask people rather than guessing, and ask without threat or you will get a useless answer.
- Which of those are paid, and on whose card?
- For each: sanctioned, tolerated, or not approved? Anything not listed defaults to not approved, and you need to say so out loud.
- Does any client contract forbid AI processing of their data? Strictest applicable rule wins, and this one overrides everything else you decide.
Pass 3: what data you actually handle
- Which of these does this business touch: payment data, customer personal data, employee personal data, health data, credentials and keys, client-confidential documents, financial statements, contracts?
- Which of those must never go into a public AI tool, regardless of who is asking?
- Which are acceptable in a sanctioned tool with care?
- Which national identifier formats matter for you? This decides what "personal data" concretely means in your rules rather than in the abstract.
Pass 4: the rules themselves
- For the never-allowed categories, is the response a warning to the person, or a quiet log? Warning changes behaviour, logging only produces a report.
- Does any role need stricter treatment than the default, for example finance with payment data?
- Is anything explicitly exempt, for example engineers using a sanctioned code assistant?
- How does someone request a new tool, who answers, and within how long? Commit to the timeframe in writing. Of 24 published policies analysed, only 2 did.
Pass 5: what you tell people
- How is this announced, and by whom? A policy that arrives from IT alone reads as a restriction. The same policy from the owner reads as a decision.
- What, honestly, will you monitor? Write down both halves, what you will look at and what you will not, and be prepared to hold to it.
- How long is anything retained?
Pass 6: the two questions people skip
- What would make this policy worth reviewing every quarter rather than filing? If you cannot answer, the review cadence will not survive its second occurrence.
- What would make your team ignore this entirely? Ask it out loud, write down the answer, and fix that thing before you publish.
That last pair is the difference between a policy and a document. Everything above it is mechanical; those two are where you find out whether what you have written will be obeyed.
Does generative AI need its own policy?
Usually no, and the question comes up often enough to answer directly. A separate generative AI policy tends to produce two documents that contradict each other within a quarter, because the boundary between generative and other AI keeps moving and nobody maintains both.
What generative AI does need is two clauses the general document might otherwise skip. First, an output rule: model output used in client work, financial material or anything contractual is the responsibility of the person who used it, and must be checked. Generative systems produce confident, well-written, incorrect answers, which is a failure mode ordinary software does not have. Second, a disclosure rule: say whether AI-assisted work needs flagging, to whom, and in what circumstances. Both belong inside the single policy, not alongside it.
Write one policy. If generative AI needs stricter handling in your business, make it a row in the sensitivity table rather than a second document with its own owner and its own review date that nobody will run.
The short-form policy your answers assemble into
Once the worksheet is filled in, the policy writes itself. This is the compact version, suitable for a company under about a hundred people. For the fully argued long-form version with the employee-protection clauses and the incident process spelled out, use the full template.
AI Usage Policy, [Company]
Owner: [name, role, email, phone] · Backup: [name] · Effective: [date] · Reviewed: every three months
1. The point. We want you using AI here. This says which tools, with which information, so you do not have to guess.
2. Your tools. [Tool] on your company account is approved for everything below confidential. [Tool] is approved including confidential work. Anything not listed is not approved yet, which is not a judgement, it just means nobody has checked it. Use company accounts, never personal ones, because the terms are different and we cannot verify an account we do not control.
3. Your data. Public information: any approved tool, no permission needed. Internal information: approved tools, check the output. Confidential information, meaning client data, anyone's personal data, financials, contracts, credentials: not in a public AI tool at all. Ask [owner] and we will find a way that works. If you cannot tell which it is, treat it as confidential and ask.
4. Getting something approved. Send [owner] the tool, the link, what it is for and which data you would put in. You get an answer within [five working days], with a reason if it is no.
5. What we look at. [Exactly what you decided in question 18.] We do not read your prompts and this is never used for performance review. If that changes you will be told first.
6. If it goes wrong. Tell [owner] the same day. No penalty for an honest first report. The only thing that makes this worse is finding out late.
7. Signed. [Name] [Signature] [Date]
What happens after it is signed
Two things, and neither takes long.
Put the review in the calendar as a recurring item attached to a meeting that already exists. Quarterly. The approved tools table will be wrong within weeks, because vendors keep switching AI features on inside software you already own without asking anyone.
Then find out what people are actually using, rather than assuming the policy settled it. That is a separate exercise with its own methods, most of which need nothing installed: how to detect shadow AI, and what each method misses. Run it once about a month after the policy lands. The gap between what you approved and what is in use is the most informative number you will get all quarter.
FAQ
Roughly twenty decisions across six areas: who owns AI decisions and who covers for them, which tools are already in use and on whose account, which categories of data the business handles and which must never reach a public tool, what happens when a rule is broken, what will and will not be monitored, and how a new tool gets approved and how quickly. Before any of them, decide which sanctioned tool people can use on day one, because a policy with no permitted option gets ignored.
After. IT managers describing this in practice are consistent that if the organisation blocks AI without providing an alternative, staff route around IT using personal accounts, and IT loses that argument to the executive team. Buying a company subscription first, then writing the policy around it, means the policy has a compliant option to point at instead of only prohibitions.
Substantially. Consumer tiers of the major AI tools generally use conversation content for model improvement by default with an opt-out in settings, while business and enterprise tiers generally do not, as a contractual matter. Same product name, different data posture. Policies should therefore name the account type rather than the brand, and the specific tier's current terms should be checked directly rather than taken from any summary.
About an afternoon. Roughly ninety minutes to work through the decisions with whoever can actually make them, usually an owner or operations lead rather than IT alone, then the drafting is mostly transcription because each decision maps to a specific line. What takes longer is the step before it, choosing and buying the sanctioned tool the policy will point to.
A named individual with contact details published in the document, plus a named backup. In an analysis of 24 published AI policies only 17% named a person with contact details, which means most policies tell staff to ask when unsure without saying who to ask. Ownership sitting with an operations lead or owner rather than IT alone also matters for adoption, since a policy issued by IT reads as a restriction while the same policy from the business reads as a decision.