What should an AI acceptable use policy actually say?
An AI acceptable use policy states which AI tools people may use, what data may go into them, who checks AI-assisted work before it leaves the company, and what happens when someone gets it wrong.
Want this made concrete for your company? Ask me — or pick one:
It does not need to be long. Most published templates are written by organizations with legal departments, for readers like auditors and courts, and that length is the single most common reason a policy gets filed and never followed. A policy your team can read in three minutes and recall in a meeting governs more behavior than a thorough one nobody opens.
The policy problem nobody names
Ask most companies whether they have an AI policy and you will get one of three answers. No. We are working on one. Or yes, and then a pause while somebody tries to remember where it lives.
That third answer is the interesting one, because on paper it is a success. The document exists. Somebody wrote it, somebody approved it, it sits in a shared drive. And it governs nothing at all, because the people it applies to have either never opened it or read it once during onboarding and retained none of it.
This is not a discipline problem. It is a design problem.
A policy competes for attention against a deadline. If following it requires remembering pages of guidance, or going to find a document to check one specific case, the policy loses. Not because anyone decided to ignore it. Because the person had a client deliverable due at four and a tool open that would help.
A policy nobody can recall in the moment they need it is not a control. It is documentation of an intention.
So the useful question is not what should go in an AI policy. It is what fits in the head of somebody under deadline pressure. That is a much shorter list, and it is the one below.
Why most templates are long
It is worth being fair to the long ones, because they are not badly made.
The AI policy templates you will find published come mostly from security vendors, HR bodies, and law firms. Each writes for its own reader. A security vendor writes to survive an audit. An HR body writes to survive a tribunal. A law firm writes to survive a court.
All three of those readers are adversarial, and adversarial readers reward completeness. That is why the documents cover model provenance, vendor due diligence, intellectual property assignment, third-party processor obligations, and incident escalation matrices. Every one of those clauses exists because it saved somebody once.
But your reader is not adversarial. Your reader is a project manager on a Tuesday who wants to know whether she can paste a client brief into a chat window. She is not going to work through the whole document. She is going to guess.
The long policy is the right document for an organization with a compliance function whose job is to know it. It is the wrong document for a company of sixty where the policy has to live in everyone’s head, because there is nobody whose job is to hold it for them.
The AI Briefing
Tuesdays. 500+ leaders. No hype, just what works.
The policy
Here it is, complete. Copy it, change the bracketed parts, delete anything that does not apply to you. The reasoning behind each clause follows underneath, because you should not adopt a rule you cannot explain.
The text
Purpose. We use AI at [COMPANY] because it makes good work faster. This policy exists so that everyone knows where the edges are, and so that nobody has to guess. It applies to everyone: employees, contractors, and anyone doing work in our name.
Tools. Use [APPROVED TOOLS] on your [COMPANY] account. Do not use a personal account for company work, even on the same tool, because the company account is what keeps our data inside our agreements. If you want to use something that is not on this list, ask [NAME]. You will get an answer within [TIMEFRAME], and the answer is often yes.
Data. These never go into any AI tool: [CLIENT CONTRACTS], [CANDIDATE AND PERSONNEL FILES], [ANYTHING UNDER NDA], [PRE-ANNOUNCEMENT FINANCIALS], [CREDENTIALS AND KEYS]. Everything else is fine. If you are unsure, the answer is to ask [NAME] rather than to decide alone, and asking is never held against you.
Release. You can send AI-assisted work out yourself when a mistake would be cheap and easy to undo. Anything that reaches a client, a candidate, a regulator, or the public gets read by a second person first. You are responsible for what you send, whether or not AI helped write it. “The AI wrote it” is not a defense we can offer a client, so it is not one we will offer each other.
When it goes wrong. Tell [NAME] as soon as you notice. Nobody is disciplined for reporting a mistake quickly, and that is a commitment, not a comfort. What we cannot fix is the thing we find out about in six weeks from a client. Deliberately hiding a problem is a different matter, and that is treated as such.
That is the policy. Roughly three hundred words, which is somewhere between three and four minutes of reading and a document somebody can actually hold in their head.
The reasoning, clause by clause
You should not adopt a rule you cannot explain, because the first time someone challenges it you will fold. Here is why each line is worded the way it is.
Why the purpose says “makes good work faster”
Most policies open defensively, in the register of risk and compliance. That tells your reader the document is about protecting the company from them.
Opening with why you use AI at all sets a different frame: this is a tool we want you to use, and here is where the edges are. The boundaries land differently after that sentence than before it. Same rules, different reception.
Why the tools clause names a person and a timeframe
This is the most important line in the policy and the one most templates omit.
A sanctioned list with no route for anything else is a policy that expires the moment something new appears, which in this field is roughly monthly. Worse, it teaches people that the honest path is a dead end, and the moment they learn that, you lose visibility into everything.
The timeframe is what makes it credible. “Ask [NAME]” with no commitment attached is an invitation to a queue. If the answer takes three weeks, people stop asking, and you are back to shadow usage with a document that says otherwise. Put a real number in there and then meet it.
“And the answer is often yes” is doing deliberate work. It tells people the route is not decorative.
Why the data clause lists categories, not principles
“Confidential information” means whatever the reader wants it to mean at four in the afternoon.
Named categories do not have that problem. A client contract is a client contract. Everyone recognizes one, and nobody has to interpret the word “confidential” under time pressure.
The other half of that clause matters just as much: everything else is fine. A list of prohibitions with no stated permission implies that everything is risky, which produces exactly the hesitation you were trying to remove. Say what is allowed, out loud.
Why the release clause talks about consequences, not seniority
The instinct is to gate by job title. Managers can send, everyone else needs approval.
That fails in both directions. It slows down senior people on trivial work and it does nothing about a junior person sending something consequential, which is the actual risk.
Sorting by what happens if it is wrong is the version that holds. A reversible internal draft needs nobody. A client deliverable needs a second reader regardless of who wrote it. This is the same logic as the release gate in our AI governance framework, applied at the level of a single document.
The line about “the AI wrote it” is there because somebody will eventually try it, and it is much easier to have settled that in advance than in the meeting after.
Why “nobody is disciplined for reporting a mistake quickly”
This is the clause that determines whether you find out about problems.
The person who pasted something they should not have is your best early warning system. They know exactly what happened, when, and into which tool. They will tell you only if telling you is survivable.
Make the consequence of a fast report punitive and you do not get fewer incidents. You get the same number of incidents and no reports, which is strictly worse, because now you have lost the ability to see them.
This is the whole reason we put humans first in how we design these systems, and it is a practical position rather than a sentimental one. A policy is not enforced by a document. It is enforced by people deciding, under pressure, whether the honest path is worth taking.
Every clause above is really a bet about human behavior: that a named person beats a process, that a stated timeframe beats a vague promise, and that somebody who trusts you will tell you what went wrong while you can still fix it. Get the human incentives wrong and the best-drafted policy in your industry governs nothing at all.
The distinction between an honest mistake and deliberate concealment has to be in the text. Without it, the clause reads as blanket amnesty and leadership will not sign it. With it, people know precisely where they stand.
Not sure where you stand?
Take the 90-second AI readiness read — five dimensions, a scored result, and a clear next step.
Take the readiness read →What we deliberately left out
This is the section no template includes, and it is the one that will save you the most time, because it tells you what you can stop worrying about.
Model-specific rules. No clauses about which underlying model may be used, temperature settings, or approved architectures. Your team does not choose models, they choose tools, and the model behind a tool changes without telling you. A rule pinned to a model name is out of date within a quarter.
A vendor due diligence process. Real and necessary at scale, and genuinely overhead at sixty people. The tools clause handles it in practice: somebody named approves new tools, and that person can do the diligence proportionate to the risk.
An incident escalation matrix. Tiered severity levels, notification windows, an escalation tree. If you have a security function, you already have one and AI incidents belong inside it. If you do not, a matrix invented for this document will not be followed during an actual incident, when people will call whoever they trust.
Intellectual property assignment language. Your employment agreements and client contracts already handle ownership of work product. Restating it here creates a second version that can drift out of alignment with the first, which is worse than not restating it.
A prohibition on “unethical use.” It sounds essential and it governs nothing. Nobody has ever paused mid-task to consider whether their use was ethical in the abstract. Specific named prohibitions work. General moral language is decoration.
Everything on that list is defensible. None of it is load-bearing at your size, and each one adds a page that reduces the chance anybody reads the four things that matter.
If you grow into needing them, add them then. Growing into a clause is easy. Recovering a policy nobody reads is not.
The problem nobody warns you about: what is already happening
The moment you publish this policy, some portion of your team is already in breach of it. Not hypothetically. Right now, before you send it.
Somebody has a personal ChatGPT account with three months of client work in it. Somebody has been pasting candidate CVs into a summarizer. Somebody built a genuinely useful thing on a tool that is not going to make the approved list.
Every template on the internet ignores this, because a template is written as though the company begins at the moment the policy is adopted. Yours does not.
You have two options and only one of them works.
The version that fails is to publish the policy and let people quietly reconcile themselves to it. What happens is that the existing usage does not stop. It goes further underground, because now it is a policy violation rather than an unaddressed habit. You have converted visible risk into invisible risk and called it governance.
The version that works is a stated amnesty, with a deadline.
Say it explicitly when you send the policy: for the next two weeks, tell us what you are using and what has gone into it, and nothing happens to you. After that, the policy applies normally.
That paragraph does three things at once. It gets you an inventory of actual tool usage that no audit would have surfaced. It tells you which data has already left, which is the thing you genuinely need to know and would otherwise learn from a client. And it establishes, at the moment of introduction, that reporting is safe, which is the norm the whole policy depends on.
The inventory you get back will be uncomfortable and it will be useful. Expect at least one tool nobody in leadership knew about, and at least one category of data somewhere it should not be. That is not a sign the policy is failing. That is the policy working before it has even taken effect.
One caution. Do not run an amnesty you are not prepared to honor. If somebody reports something serious and is disciplined for it, you have taught your entire company that the reporting clause is decorative, and you will not get another honest answer for years.
Adapting it to your business
The five parts do not change. The specifics inside them do, and the data clause is where almost all the variation lives.
Professional services and agencies. Your sharp edge is client material under NDA, and your risk is that the useful thing and the prohibited thing are the same document. The brief you want to summarize is the brief you are not allowed to paste. Be specific about which client materials are excluded, and be honest that this is the clause people will most want to route around. If your sanctioned tool sits inside your own tenant, say so here, because it changes the answer.
Companies with a hiring function. Candidate material deserves its own line rather than being folded into “personnel.” Screening and evaluation carry obligations in several jurisdictions that ordinary business data does not, and the person doing the screening is often not the person who read the policy.
Regulated industries. Health, financial and biometric data all sit under regimes that predate AI and apply to it regardless. Your existing data rules already cover this. The AI policy should point at them rather than restate them, because a second version will drift out of alignment with the first.
Companies with European clients or staff. The EU AI Act became generally applicable on 2 August 2026. Its scope extends to providers and deployers sitting in a third country, in the Regulation’s own words, “where the output produced by the AI system is used in the Union.” That is about where your work lands, not where your company is incorporated. The AI governance framework covers what that means in practice.
Where this breaks
Four failure modes, each with a specific cause.
The policy is published and nothing changes. Almost always the tools clause. There is a sanctioned list but no real route for anything else, so the first person who needs something new finds the honest path closed and takes the other one. Fix the route, not the list.
Everyone asks about everything. The opposite failure, and it means the data clause is written in principles rather than categories. When people cannot tell on their own whether something is allowed, they either ask constantly or stop asking entirely, and the second group is larger. Name the categories.
The second reader becomes a rubber stamp. The release clause exists, the review happens, and the reviewer approves everything in nine seconds. This usually means the tiering is wrong: too much is landing in the high tier, so review became a formality. Tighten what actually reaches a client and the remaining reviews get real attention.
Nobody reports anything and everything seems fine. The most dangerous one, because it reads as success. If you have had zero reported near misses in six months across a team actively using AI, the likeliest explanation is not that there were none. It is that reporting does not feel safe, or that nobody knows where to report. Both are fixable, and neither fixes itself.
Rolling it out so it is followed
Writing the policy is an afternoon. Making it real is the part that gets skipped, and it takes about a week.
Send it as a document, not a link in a handbook. Something in a handbook has been formally distributed and functionally hidden. Send it, in the body of the message, and ask people to reply with one question or one case it does not cover. You will get real questions, and the questions tell you which clause is ambiguous.
Answer the first new-tool request within your stated timeframe. The policy’s credibility is decided by the first request, not by the document. If the first person to ask waits two weeks, everybody watching learns what the route is actually worth.
Say the release rule out loud in a meeting where it applies. People adopt norms from watching them enforced once, far more than from reading them. The first time somebody says “that is client-facing, can you give it a read,” the rule becomes real.
Revisit it when something surprises you, not on a calendar. An annual review produces a document that is eleven months stale for most of the year. A near miss produces a specific, correct revision. Let the edge cases write the next version, which is exactly the loop the governance framework runs on.
How you know it is working
Most companies never find out whether their policy did anything, because they measure the wrong thing. Adoption of the document is not the metric. Everybody clicked acknowledge. That tells you nothing.
Three signals are worth watching, and none of them require a dashboard.
New-tool requests are arriving. This is the leading indicator and it is counterintuitive, because a request looks like friction. It is the opposite. A steady trickle of people asking about tools means the route is credible and being used. Zero requests over a quarter, in a team actively using AI, means people have concluded that asking is pointless and are deciding alone.
Near misses get reported without drama. Somebody says “I nearly pasted the wrong thing” in a normal tone, in a normal meeting, and nothing bad happens to them. That is the reporting clause working. It is also the only mechanism by which you learn what the policy did not anticipate.
The awkward cases reach the named person instead of being resolved privately. The test is not whether people follow the clear rules. It is what happens at the edges the policy did not foresee, because those are the cases where the document is silent and the person has to choose between asking and guessing.
If all three are absent after a quarter, the policy is not being followed regardless of what the acknowledgment log says. The most likely cause is the tools clause, and specifically the timeframe: somewhere between writing it and living it, the promised answer stopped arriving on time, and people adjusted.
That is a fixable problem, but only if you are looking at the right three things.
Where this fits
This policy is one artifact, not a governance program. It answers two of the four questions a full framework settles: which tools may be used, and what data may go into them.
The other two, who is accountable and what gets reviewed over time, need the wider structure. If you want that, the AI governance framework covers all four layers, plus the honest answer on which of ISO 42001, the NIST AI Risk Management Framework and the EU AI Act actually bind a company your size. The short version on the last one: the EU AI Act became generally applicable on 2 August 2026, and it can reach a US company where the output of an AI system is used in the Union.
Two neighboring pieces worth reading if this is a live problem for you. The case against personal accounts is made properly in the hidden liability of personal AI accounts, which is the argument behind the company-account line in the tools clause. And if your issue is that people are not using AI rather than using it wrongly, that is a different problem with a different fix, covered in who owns AI adoption.
Adapt This Policy to Your Company in One Sitting
Paste this into your AI assistant along with the policy text above. It interviews you about how your company actually works and returns a version in your language, with your categories and your names in it.
Context: I am adapting a one-page AI acceptable use policy for a [INDUSTRY] company with [NUMBER] people. We do not have a legal department. The goal is a document somebody reads once and remembers, not a document that survives an audit. Interview me one question at a time and push back when my answers are vague or when I describe a process we do not actually run.
Step 1. The data categories: Ask me what kinds of sensitive material actually move through my business. Push me past “confidential” until I give you specific named categories a colleague would recognize on sight. Ask for one borderline example and how I would decide it.
Step 2. The tools and the route: Ask which AI tools we already use, including ones people use without asking. Then ask who approves a new tool and how long that genuinely takes today. If there is no route, say so plainly instead of inventing one.
Step 3. The release line: Help me sort our work by consequence rather than by job title. For the tier that reaches clients, ask who the second reader is by name. Do not accept a role if no specific person holds it.
Step 4. The reporting promise: Ask me whether I am actually willing to commit that fast reporting is never punished. If I hesitate, tell me so, because a promise the leadership will not keep is worse than no promise.
Step 5. Rewrite it: Produce the policy in my language, under 400 words, with my names and timeframes filled in. Then list separately everything I could not answer, marked UNDECIDED.
Output: The finished one-page policy, plus the UNDECIDED list kept apart from it, plus a short note on which clause you think is most likely to be ignored in my company and why.
That last item is worth asking for. The clause most likely to be ignored is usually the one where the policy and the way your company actually runs are in quiet disagreement. See where you stand →
One honest caveat
This is a starting point written by practitioners, not lawyers, and it is not legal advice.
If you operate in a regulated industry, employ people across multiple jurisdictions, or handle health, financial or biometric data, have counsel look at it before you adopt it. The structure will hold. Some of the wording will need to change, and there may be sector obligations that this document does not touch.
For most companies, the risk is not that the policy is imperfect. It is that there is no policy at all, and everybody is guessing separately.
Sources
- Regulation (EU) 2024/1689 (the AI Act) (EUR-Lex): Article 2 scope and Article 113 application dates
- ISO/IEC 42001:2023 (ISO): AI management system requirements
- NIST AI Risk Management Framework (NIST): voluntary framework, four core functions
Frequently Asked Questions
What should an AI acceptable use policy include?
At minimum, four things: which AI tools are approved and on which accounts, what categories of data may never go into them, who may send AI-assisted work outward without a second reader, and what happens when someone makes a mistake. Published templates add vendor due diligence, incident escalation matrices and intellectual property language. Those are genuinely useful at scale and mostly overhead in a company without a compliance function.
How long should an AI policy be?
Short enough that somebody can recall it during the moment they need it, which in practice means about one page. Most published templates are written by security vendors, HR bodies and law firms for adversarial readers such as auditors and courts, which rewards completeness over recall. Your reader is an employee under deadline pressure, and length is the most common reason a policy gets filed and never followed.
Can employees use personal AI accounts for work?
The safer answer is no, and the reason is not the model but the account. A company account keeps the work inside the agreements your company has signed, where a personal account does not, which means the data leaves your control and you cannot audit or retract it. This is why the tools clause specifies the account and not only the tool.
Is an AI acceptable use policy legally required?
Generally no, not as a standalone obligation for most companies. Some sector regulators and some contracts require documented AI controls, and the EU AI Act creates obligations that can reach non-EU companies where the output of an AI system is used in the Union. Independent of any requirement, a policy is what lets you demonstrate you had a control in place if something goes wrong, and it is what stops your team guessing individually in the meantime.
How do we get people to actually follow the policy?
Make following it easier than working around it. That means providing a sanctioned tool before prohibiting the unsanctioned one, answering new-tool requests within a stated timeframe you actually meet, and making it safe to report a mistake quickly. A policy that is slower than the deadline will lose to the deadline, every time, and not because anybody decided to ignore it.
How often should we update our AI policy?
When something surprises you rather than on a fixed calendar. An annual review produces a document that is eleven months stale for most of the year, while a near miss or an awkward edge case produces a specific and correct revision. Let the real cases write the next version.
Turn scattered AI into a system your company runs on.
CompanyOS is the AI operating system your whole company runs on — governed accounts, real adoption, and visibility you own.
See CompanyOS → Not sure where to start? Take the 90-second readiness read →
