How to Write an AI Acceptable Use Policy

An AI acceptable use policy needs six sections: an approved-tool list, data rules mapped to your existing classification tiers, prohibited uses, human-review requirements for AI output, a vetting path for new tools, and one named owner. It should fit on two pages. As of August 2026 it is also the AI control most organizations still do not have: ISACA's 2026 AI Pulse Poll of more than 3,400 digital trust professionals found 38 percent with a formal, comprehensive AI policy, up from 28 percent the year before, while 25 percent had no active policy at all and 90 percent believed employees were already using AI in their organization. ISACA sells AI governance training and certifications, so the gap is a gap it benefits from naming, and it is still a large gap. The contrarian part is that the policy nobody reads is not the failure mode here: the failure mode is a policy so broad that no employee can tell whether a specific tool is allowed, which produces the same shadow usage as having no policy while looking like governance on an audit list.

Below: what each of the six sections has to say, the two-page discipline and why it matters, what makes a policy fail in practice, and when writing one is not your first problem.

Key takeaways

• Six sections, two pages: approved tools, data rules, prohibited uses, human review, a vetting path, and a named owner.
• Name specific tools. A policy that describes categories rather than products cannot be complied with, because the employee cannot resolve it.
• The policy is the cheapest AI control that answers to three audiences at once: auditors, enterprise customers, and regulators.
• Adoption is the gap, not awareness. ISACA's 2026 poll puts formal comprehensive policies at 38 percent against 90 percent believing employees already use AI.
• Human review is the section that carries the most risk and gets the least attention. Write it around consequence, not around tool.

Why this is the first artifact, not the last

Three separate audiences ask for an AI policy before they ask for anything else, and only one of them is a regulator.

An auditor asks because governance documents are where a management system starts. The NIST AI Risk Management Framework, which NIST publishes for voluntary use, opens with a GOVERN function whose first category covers, in the words of AI RMF 1.0 itself, "policies, processes, procedures, and practices across the organization"; the AI RMF Playbook breaks that category into subcategories covering legal and regulatory understanding, the integration of trustworthy AI characteristics into policy, risk tolerance, ongoing monitoring, AI system inventories and safe decommissioning. An enterprise customer asks because "what AI governance framework do you follow" is now a standard security-review question, and the policy is the first attachment that makes the answer credible. And ISO/IEC 42001's Annex A opens with a control objective on policies related to AI, so anyone heading toward certification writes this document early regardless.

That is an unusual amount of leverage for two pages. It is also why the temptation to make it comprehensive is so strong, and why resisting that temptation is the whole craft.

Section one: the approved-tool list

Name products, not categories. "Approved generative AI tools" is not a rule an employee can apply; "ChatGPT Enterprise, GitHub Copilot Business and the AI features in our Google Workspace tenant" is.

The list needs three columns and no more: the tool, what it is approved for, and the data tier it may see. That last column is the one that does the work, because most real-world questions are not "may I use this tool" but "may I use this tool for this". A tool approved for drafting internal documentation is not thereby approved for pasting a customer's incident report into.

Two failures to avoid. A list out of date within a quarter is worse than no list, because it teaches people the policy does not describe reality. And a list naming only paid enterprise tools, while everyone quietly uses the free consumer versions from a personal account, is the shape of the problem rather than a solution to it. Microsoft and LinkedIn's 2024 Work Trend Index, a survey of 31,000 people across 31 countries, found 78 percent of AI users bringing their own tools to work. That figure is from 2024 and Microsoft sells AI products, so treat it as directional, but the direction has not reversed.

Section two: data rules mapped to tiers you already have

Do not invent an AI-specific data classification. Map to the tiers your data classification policy already defines, because a second scheme that only applies to AI guarantees the two will diverge.

The rule that has to be unambiguous is which tier may never enter a tool where your organization does not control retention and training. In most companies that line sits above customer data, regulated data, credentials and source code, and below public marketing copy and internal drafts. State it as a sentence an employee can recall under time pressure, not as a matrix.

Then say what happens at the boundary. Can regulated data go into an approved enterprise tool under a contract that excludes training? Sometimes, and whichever way your answer lands, write it down, because the policy that bans everything is the policy people route around. What the answer cannot rest on is the training term alone. Excluding training removes one risk; it does not clear the others that travel with regulated data, which include purpose limits, the processor or business associate terms the regime demands, retention and residency, the security commitments your own customer contracts already made, and any approval a specific customer's data carries. So write the rule as a conjunction: the tool is approved for that data tier, and the processing satisfies everything else attached to it. The distinction that matters is not sensitive versus not sensitive, it is whether you hold contractual and configuration control over what the provider does with the input and whether that particular use was cleared.

Section three: prohibited uses

Short, specific, and about consequences rather than technology. The ones worth writing down for almost every organization:

• Putting customer data, regulated data, credentials or source code into a tool not on the approved list.
• Presenting AI output as reviewed human work when nobody reviewed it.
• Using AI output as the sole basis for a decision about a person, including hiring, discipline, credit, pricing or access.
• Using AI to generate code that ships without the review your normal process requires.
• Signing up for a new AI tool with a company email or a company card without going through the vetting path.

That last one is the operative control on shadow usage, and it is the one most policies omit. The others describe misuse; that one describes how misuse arrives.

Section four: human review, written around consequence

This is the section that carries the most legal and operational risk and it is usually one sentence long. Make it three, and organize it by what the output touches rather than by which tool produced it.

The useful frame is a three-tier one. Output that only informs an internal draft needs no formal review. Output that reaches a customer, a regulator or a public channel needs a named human reviewer before it goes. Output that influences a decision about a person needs a named human reviewer with the authority and the information to reach a different conclusion, which is a materially higher bar than a rubber stamp.

That top tier is where regulation is converging. State privacy regimes increasingly reach automated decision-making through opt-out and assessment duties, and Colorado's SB 26-189 puts explicit disclosure, explanation and human-review duties on deployers of automated decision-making technology from January 2027. Writing the tier now is cheap. Retrofitting it after a system is in production is not.

It is worth noting that the practice is not exotic. Microsoft's 2026 Work Trend Index, a survey of 20,000 knowledge workers who use AI at work across ten markets, reports 86 percent saying they treat AI output as a starting point rather than a final answer. Most of your people are already doing the thing; the policy exists so that the ones who are not can be corrected by reference to something.

Section five: the vetting path

Every policy that prohibits unapproved tools needs to say how a tool gets approved, and it needs to be fast enough that people use it.

Three fields and a named reviewer is enough for most companies: what the tool does, what data it would see, and whether it can take an action rather than only suggest one. That third field is the one that catches the tools worth worrying about, and it is the axis most vendor intake forms still do not have. The deeper questions that follow once a tool clears that bar belong to vendor risk review rather than to the policy, and they are a separate exercise with a separate owner.

Commit to a turnaround. A vetting path with no service level is a queue, and a queue is a reason to skip the process. Two business days for a low-risk tool is a reasonable promise and it buys more compliance than any amount of prohibition.

Section six: the named owner

One person, by name, with the policy review date on their calendar. Not a committee, not a function.

The AI RMF Playbook's GOVERN 2 category is about exactly this: accountability structures with documented roles, responsibilities and lines of communication, so that the appropriate people are empowered, responsible and trained. In a company under a few hundred people that is usually whoever already owns security policy, and the honest reason to name them is that reviewers check. An owner field reading "Security Team" tells a reviewer nobody owns it.

Review the tool list quarterly and the policy body annually. The tool list is the part that goes stale, and it goes stale fast.

Two pages, and what to leave out

The single most common defect we see is a fifteen-page AI policy that reads like a standard. Leave out the definitions unless a term genuinely changes behavior, leave out the philosophy, and leave out the aspirational commitments to fairness and transparency that carry no operative rule, because they create obligations you cannot evidence and push the real rules onto page nine.

There is a related trap in the template market. ISACA's own AI acceptable use policy template page is a fair example of the genre: the template is real and ISACA is a credible professional association, but the page is gated behind a download form and, as of August 2026, still reads "Only 28% of organizations say they have a formal, comprehensive policy in place for AI use", the figure ISACA's own 2026 poll had already moved to 38 percent. A template is a starting shape, not a decision.

When a policy is not your first problem

Three cases where we would tell you to spend the week differently.

Nobody uses AI on anything sensitive. If AI usage in your company is a marketing team drafting social posts and nothing else touches customer or regulated data, a paragraph in your existing acceptable use policy is proportionate and a standalone document is theater.

You cannot answer the tool question. If you genuinely do not know which AI tools are in use, writing rules about them is premature. Build the list first; our piece on building an AI system inventory covers how, and a policy written against a real inventory takes an afternoon.

The policy would be your only control. A document that prohibits things nobody monitors and nobody enforces is a liability under discovery rather than a defense. If you write the human-review tier, someone has to actually check it occasionally. That is a small commitment and it needs to be a real one.

Where Top Floor fits

We write this document as a bounded piece of work rather than as the front end of a program: the inventory first, then the six sections against it, then the owner and the review cadence. Most companies do not need more than that, and saying so is easier for us than for a firm selling an AI governance platform. That work sits inside our vCISO engagements, where the same person owns the rest of the policy set, and it is where the policy stops being a document and becomes something with an owner who has hours.

Where the destination is a framework rather than a document, NIST AI RMF alignment is the cheaper of the two credible paths and the policy is its first artifact. Where the answer to who keeps the tool list current is nobody, compliance as a service covers the cadence, which is the part that decays.

For the broader question of which function in your company should own governance documents at all, Who Actually Owns Compliance? is the piece to read next.

How to decide this week

• Pull your expense reports and SSO logs for AI tool names. That list is your real approved-tool list whether you approved it or not.
• Write the one sentence about which data tier may never enter a tool you do not control. Circulate that sentence before you write anything else.
• Name the owner. If the name is contested, that is the finding, not a formatting problem.
• Write the human-review tiers around consequence: internal draft, customer-facing, decision about a person.
• Set the vetting turnaround at two business days and tell people the number, because the promise is what makes the path get used.

Frequently asked questions

What should an AI acceptable use policy include?

Six sections: a list of approved tools naming specific products, data rules mapped to your existing classification tiers with an unambiguous statement of what may never enter a tool you do not control, prohibited uses written around consequences, human-review requirements organized by what the output touches, a vetting path with a committed turnaround for new tools, and one named owner with a review date. Two pages is the right length. Anything longer pushes the operative rules past the point where employees read them, and a policy nobody can apply produces the same shadow usage as no policy at all.

How long should an AI policy be?

Two pages. The failure we see most often is a fifteen-page document written in the register of a standard, with definitions, philosophy and aspirational fairness commitments occupying the first third and the actual rules starting on page nine. Length also creates obligations you cannot evidence: a commitment to transparency with no operative rule behind it is something an auditor or a customer can ask you to demonstrate. Keep the body short, keep the approved-tool list as a separate page you can update quarterly without reissuing the policy, and put the owner on page one.

Do we need an AI policy if we do not build AI?

Usually yes, because the risk is your employees using other people's AI on your data rather than anything you build. Microsoft and LinkedIn's 2024 Work Trend Index, surveying 31,000 people across 31 countries, found 78 percent of AI users bringing their own tools to work, and ISACA's 2026 AI Pulse Poll found 90 percent of more than 3,400 professionals believing employees in their organization use AI. If nothing in your company touches customer or regulated data with an AI tool, a paragraph in your existing acceptable use policy is proportionate. Otherwise the standalone document earns its two pages.

Is an AI policy enough for enterprise security reviews?

It is the first artifact, not the only one. Reviewers typically want the policy, an inventory of your AI features and the models behind them, a sub-processor list that names your model providers, and a written statement of alignment to a named framework. Together those four usually clear a review without a certificate, provided each one is worded as a claim you can evidence rather than an aspiration. What does not clear a review is naming a framework with nothing attached to it, which invites the follow-up that costs you the week.