An AI acceptable use policy states what staff may do with AI at work, what they may not, and where to ask. It is the one governance document most people in an organization will ever read, which makes its length and its tone more consequential than its comprehensiveness.
This page sets out the decisions such a policy has to make. It does not provide model wording, and the reason is not caution for its own sake: a policy adopted from a template is a document an organization has not decided, and the first hard case exposes that.
Before writing: the disclaimer that is not boilerplate
Organizational policies should be reviewed against applicable legal, regulatory, contractual and sector-specific requirements with qualified counsel or compliance professionals. Nothing on this page is legal advice, and no page written by a technology supplier can tell you what your obligations are.
That is stated first rather than last because it changes how the rest should be read. Everything below concerns decisions that are yours to make within whatever constraints already apply to you, and identifying those constraints is a separate exercise that comes first.
Where it sits among your other documents
Most organizations need four short documents rather than one long one, and confusion about which is which is why AI policies get long.
The acceptable use position is for everyone. It answers what a member of staff may do today. It should be a page.
The data rule states which categories of information may not be entered into an AI system. It is often folded into the acceptable use position, and that is fine provided it is specific.
The procurement position is for people who buy things, and states what happens before an AI product is acquired or an AI feature enabled.
The human review position is for system owners, and states where a person must review output before it takes effect.
Only the first is written for the whole organization. Merging the other three into it is the most common reason an acceptable use policy becomes something nobody finishes reading.
Policy sits within the GOVERN function of the NIST AI Risk Management Framework, which treats accountability, roles and documented decision-making as cross-cutting rather than as a preliminary step. That is a useful corrective to the instinct to write the policy first.
The decisions the policy has to make
Twelve, and an organization that has answered all twelve has a policy whether or not it has written one.
Approved services. Which tools may be used for work. A named list, with a route to add to it. This is the decision staff most want an answer to, and the one most often left implicit.
Prohibited data. Which categories of information may never be entered. Specific enough to apply without asking: naming the categories your organization actually holds rather than saying confidential information.
Personal data. Whether personal data about identifiable individuals may be entered at all, into which services, and under what conditions.
Confidential and customer material. Whether material covered by an agreement with someone else may be used, which frequently has a different answer from your own confidential material.
Credentials and secrets. Almost always a flat prohibition, and worth stating explicitly because it is the one people breach casually while debugging.
Source code. Whether code may be shared with an assistant, and if so which repositories. Organizations with customer-owned code frequently need two answers.
Intellectual property in. Whether licensed or third-party material may be entered, given the terms you hold it under.
Externally published output. Whether AI-assisted material may go to customers or the public, and under what review.
Human review. Which outputs require a person's judgment before they take effect, keyed to consequence to an individual.
Autonomous action. Whether a system may act rather than draft, and whether that requires separate approval. Increasingly the decision that matters most, and one the NIST Generative AI Profile touches on in its treatment of human-AI configuration.
Account provisioning. Whether staff may create their own accounts with AI services, and whether personal accounts may be used for work. A policy silent on this has effectively permitted it.
Incident reporting. What to report, to whom, and the assurance that reporting is not punished.
Write it for the person who wants to say yes
The most common structural error is a policy organised around prohibitions. It produces a document that answers a question nobody asked and leaves the actual question, whether the thing I am doing is allowed, unanswered.
Lead with what is permitted. Name the approved tools. Say what they may be used for. Then state the limits, then the route to ask. An organization that publishes only restrictions gets undeclared use, which is covered further in AI inventory and use-case management.
Keep it to a page. The material that does not fit belongs in the other three documents, and length is not thoroughness: a policy nobody reaches the end of has failed regardless of what it says.
Tone, and the reporting clause
Two sentences do more work than the rest of the document.
The first states that the organization expects staff to use AI where it helps, and that the policy exists to make that safe rather than to discourage it. Without it, the document reads as disapproval and people stop mentioning tools.
The second states that reporting a mistake will not be punished. Almost every serious AI incident is preceded by somebody realising something has gone wrong and deciding not to say so. A reporting clause is cheap and it is the single most valuable sentence in the policy.
Three failure modes worth designing against
The policy that cannot answer a real question. Test the draft against three specific cases before issuing it: a member of staff wants to summarise a customer email; a manager wants to draft a performance note; a developer wants an assistant on a repository the organization does not own. If the policy does not answer all three without interpretation, it will generate a queue of exception requests that nobody has resourced.
The policy that governs a tool rather than a use. Naming approved products is necessary and insufficient. The same assistant may be fine for internal drafting and unacceptable for anything touching personal data, so permissions have to attach to what is being done as well as to what is being used.
The policy that assumes the reader knows what AI is. Staff frequently do not classify the features they use as AI, particularly where they arrived inside familiar software. A policy that says "AI tools" without examples will be read as not applying to the transcription in a meeting product or the summarisation in a mailbox. Name the categories in ordinary language.
The parts that need a lawyer, not a template
Four areas where organizations should not rely on a supplier's page, including this one.
Anything concerning regulated data in your sector. Anything concerning obligations to customers under existing contracts, which frequently constrain what may be shared with a subprocessor. Anything concerning employment, including monitoring of AI use and consequences for breach. And anything concerning rights in output, which varies by supplier, by tier and by jurisdiction.
The policy should state that these constraints apply and where to ask about them, rather than attempting to resolve them.
Test the draft on somebody outside the group that wrote it, and ask them one question: what does this tell you that you may do. If the answer is a shrug, the document is a restriction notice rather than a policy, however carefully it was drafted.
Keeping it current
An acceptable use policy dates faster than any other governance document, because the approved list changes and the capabilities of approved tools change underneath it.
Separate the two. Keep the policy stable and the approved list separate and current, referenced by the policy rather than embedded in it. That way adding a tool does not require reissuing a policy, which is what causes lists to go stale.
Review the policy itself annually and on trigger: a new category of tool, a significant capability change in an approved one, or an incident.
Where to go next
The policy is one domain of the AI governance framework and step five of the ten-step sequence, which is deliberately after the inventory and the risk classification. Writing it earlier means writing rules for an organization nobody has described.
To establish where you currently stand across all fifteen areas, the AI governance checklist is quicker than an assessment. Smaller organizations may find AI governance for small and midsize businesses better sized, and public bodies have four additional constraints set out in AI governance for public-sector organizations.
LABUSA develops AI policy sets with organizations as part of AI policy development, written to the decisions an organization has actually made rather than adapted from a template. We do not provide legal advice, and we say so in engagements as well as on pages. If you want to work through the twelve decisions with someone, start here.