AI Acceptable Use Policy: A One-Page Starter

An AI acceptable use policy fails in one of two ways: it never gets written, or it gets written at a length no one finishes. The second is the one I would worry about, because it is the harder one to see. A twelve-page document filed in a wiki looks like the problem is solved.

What follows is short enough to fit on one page, deliberately. Copy it, cut what does not apply, and put your own names in it.

One caveat before the template. This is a starting point, not legal advice, and I am not a lawyer. Anything with contractual, regulatory or employment consequences needs review by someone qualified in your jurisdiction. Practitioners who publish these templates say the same thing, and they are right to.

How long should an AI acceptable use policy be?

The length is not a stylistic preference. A policy is only useful at the moment somebody is about to do something, and at that moment they will not open a document and scroll. The test is whether a new joiner can read it in ninety seconds and then make a correct decision without asking anyone.

That constraint forces a useful discipline. You cannot cover every scenario, so you have to decide what carries the weight, which is usually four things: what data, which tools, who checks the output, and what to do when the rules do not fit.

Tie it to what you already have rather than building a parallel system. If you have a data classification scheme, use its words. A policy that invents new categories creates a second thing to learn, and the second thing loses.

Copy this AI acceptable use policy and edit it

Everything in square brackets is yours to fill in.

AI acceptable use, [Company] Owner: [name]. Last reviewed: [date]. Questions and exceptions: [name or channel].

1. Approved tools. You may use [tool A] and [tool B] for work. Both are covered by a company agreement. Anything else needs a request first, at [link]. We will say yes to most of them.

2. What may go in. Public and internal material is fine. Do not put the following into any AI tool, approved or not: credentials and API keys, customer personal data, [regulated category relevant to you], unsigned contracts, and anything a client agreement requires us to keep confidential.

3. You own the output. AI drafts, you decide. Anything that leaves the company or reaches a customer, ships to production, or informs a decision, gets read by a person first. If it is wrong, it is wrong in your name, not the tool’s.

4. When in doubt, ask. If a job would be easier with a tool or a data type this policy does not cover, ask at [link] rather than guessing. Asking is never the wrong move here, and it is how this page gets updated.

That is the whole thing. Four clauses, a name, and a date. Clause 2 is the one people ask about most, and what to check before you upload company data to AI is the longer version of it.

Two notes on why it is shaped that way. Clause 1 says “we will say yes to most of them” on purpose, because a request path people expect to be refused is a request path they stop using. Clause 4 exists because the alternative to asking is not compliance, it is a quiet decision you never hear about.

Name an owner and a request path for your AI policy

A policy with no name on it belongs to no one, and the first hard case will prove it. NIST’s AI Risk Management Framework asks that “roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization.” It is a voluntary framework rather than a rule, and note what it does and does not ask for: responsibilities that are clear, not a particular person’s name in the document.

That distinction has a practical form, and the objection to naming individuals is a fair one. People change teams and leave, and a policy you have to reopen every time somebody moves is a policy that goes stale instead. So put the role in the document and the current holder somewhere you can update without an amendment, an appendix or a short register. What you are avoiding either way is the department as owner. “IT owns it” is how something ends up owned by no one at all. On a team small enough that titles are fuzzy, a person’s name is simply the clearer way to say the same thing. If your organisation already has a security policy, the gaps agents open in it are a separate and larger job than this page.

The request path matters just as much, and it is the part most templates leave out. When there is no way to ask, some of that demand goes to personal accounts instead, where there is no record of it at all. Shadow AI at work covers what that costs. The point of a visible, low-friction request path is to give that behaviour somewhere legitimate to go.

When a request arrives, the questions to ask are narrow: what data would go into it, is there an agreement covering that data, and what can it reach. Vendor terms differ in ways that matter here, and they differ product by product inside a single vendor. OpenAI will execute a Data Processing Addendum for ChatGPT Business, ChatGPT Enterprise and the API, and states that business data is not used to train its models by default. HIPAA coverage is narrower than that: a Business Associate Agreement is available for the API, and for ChatGPT only to Enterprise or Edu customers on a sales-managed account, with ChatGPT Business excluded outright. The gap between those two lines is the point. Read the terms for the specific plan you are on, not the vendor’s reputation.

Publishing an AI use policy is not the same as it working

The gap between a published policy and a followed one is measurable, and a first pass at it is closer to a two-week look than a project. How long a real one takes depends on what visibility you already have.

Pick a window and compare the document to reality. Which tools are people using, which of those are on your approved list, and what has been requested. A month with no requests is not evidence of compliance, and it is not evidence of a broken process either. It is a question with three candidate answers: there was no demand, or no one knows the path exists, or no one expects a yes. Where the tools in use do not match the list, my own first suspicion is the list rather than the people, because approved lists go stale without anyone noticing and the work does not wait for them.

Training belongs in the same loop. NIST’s framework asks that personnel “receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures, and agreements.” It does not say what that training looks like, and it is written for organisations of any size, so the scaling is yours to do. On a team of five, my version is reading this page out loud once and letting people argue with it. Treat that as a floor rather than a sufficient answer: where roles differ, or a regulator has an opinion, the training has to match.

If you want the framework scaffolding behind all of this, ISO/IEC 42001 is the international standard for AI management systems and is a reasonable outline to borrow from. Certification against it is voluntary, and for a team writing its first page, the outline is the useful part rather than the badge.

The request path in an AI acceptable use policy, showing how an unapproved tool request either becomes an approved tool or an unrecorded personal account

Which of these two paths your team is on is not something the document can tell you. That is what the two-week look is for.

I do not have one of these, which is an awkward admission to make underneath a template. No employer sets rules for me and there is no one to hand a document to. What I have instead is a handful of rules I follow without exception and have never written down: chat history stays off, numbers get rounded or swapped before anything is pasted, and the agents I run may read whatever they like but have to ask before they change a file. Each of those arrived on its own, after something specific made me think about it. Assembling this page is the first time I have seen them sitting next to each other, and what struck me is that I could not have handed them to anyone in that state. This post’s argument turns out to point at me too.

Should you ban AI tools instead of writing a policy?

The instinct when this feels risky is to block everything and revisit later. Understand why that tends to fail before choosing it.

Blocking the well-known tools removes the tools, not the demand behind them. Practitioners who have tried domain-level blocking describe what tends to happen next: the work moves to tools you have never heard of, on devices and accounts you do not control, which is the same data in less reputable places with no visibility at all. That outcome is not automatic, and a sanctioned alternative plus real network controls change it. It is common enough that a block on its own is a weak plan.

There are contexts where a restriction is genuinely the right call, usually regulated ones. Even then, treat it as a clause with the same requirements as any other: name what is blocked, say why, give an exception route, and offer a sanctioned alternative for the work people were trying to do. A ban with no alternative assumes the work stops. Sometimes it does, and sometimes it moves somewhere you cannot see.

FAQ

Do we have to disclose when something was written with AI?

That depends on the audience and any commitments you have made, so decide it deliberately rather than by default. Many teams require disclosure for external and published material and treat internal drafts as unremarkable, which keeps the rule usable. Where a client contract, a publisher, an academic body or a regulator has its own disclosure requirement, that requirement wins and your policy should point at it rather than restate it.

Can we just use an AI tool to write the AI policy?

For a first draft, yes, and plenty of people do. The limitation is that the hard parts of this document are not the wording, they are the decisions: which tools you will approve in practice, what your real data categories are, and who owns it. A generated policy tends to be fluent and generic, which is the exact failure mode of a policy no one follows. Use it to draft, then replace every generic clause with a specific one.

Does GDPR change what has to be in the policy?

It changes what you have to be able to show rather than the shape of the page. If personal data goes into a tool you need a lawful basis for it, and where the vendor processes that data on your behalf, Article 28 requires a contract with them, which is what a Data Processing Addendum is for. Not every vendor is a processor and not every plan offers a DPA, so this is a question per tool rather than a box you tick once. The practical consequence for a one-page policy is that clause 2 has to name personal data explicitly, and clause 1 has to mean something, because approving a tool that handles personal data without settling the contract is not much of an approval.

Is one page really enough?

For most small teams, yes, as the thing people read. It is not enough as the whole of your governance, and larger or regulated organisations will need more underneath it. The useful split is a short page everyone reads plus whatever detail your obligations demand, kept separately and maintained by the owner. A single long document tends to satisfy an auditor and change nobody’s behaviour.

Sources

This page is a starting point, not legal advice. NIST AI RMF and ISO/IEC 42001 are voluntary frameworks rather than regulation. Vendor terms cited are OpenAI’s published terms for its own business products as of August 2026 and are used as an example of what to check, not as an industry norm. Descriptions of what works in practice reflect ongoing practitioner discussion rather than survey data.

Written by Grace

I test AI tools and agents in my own workflow, and write down what I find, including the settings that surprised me. About Grace and how posts are verified