An AI acceptable use policy template gives leadership a ready structure for the rules employees follow when they use AI tools at work: what is allowed, what is off limits, which data can go where, and who checks the output. The fastest route to a usable policy is to work through each section in order, make the decisions that section requires, then adapt short example wording. This guide does exactly that.
What an AI acceptable use policy is, and what it is not
An AI acceptable use policy is a short, employee-facing document. It tells people how they may use AI tools, including generative AI tools that write text, summarize documents or produce code, in the course of their work. Some organizations call it an AI usage policy for employees or a generative AI policy for companies. The name matters less than the content: it is a rulebook for behavior.
It is often confused with two other documents:
- A general IT acceptable use policy. That covers devices, email, internet use and accounts. It rarely addresses what happens when an employee pastes a client contract into a chatbot, or whether AI-drafted work needs review. Reference the IT policy, but give AI its own rules.
- An AI governance framework. That is the management system above the policy: how the company inventories AI use, assesses risk, approves tools and reports to the board. The NIST AI Risk Management Framework organizes this work into four functions: Govern, Map, Measure and Manage. The acceptable use policy is one output of governance, not a substitute for it.
If you are still building the approval side, our article on how to govern AI tool use covers it. This piece focuses on the policy document itself.
Four decisions to make before anyone drafts
AI policies usually stall because wording is drafted before leadership has settled the underlying questions. Decide these first:
- Posture. Is AI encouraged with guardrails, permitted only for approved uses, or restricted pending review? An enabling policy reads very differently from a restrictive one.
- Tool tiers. Which categories of tools exist in your environment: approved tools under company contract, public consumer tools, and AI features built into software you already use?
- Data classes. Which data categories does the company already recognize? Reuse them rather than inventing new ones.
- Owner. Which named executive owns the policy, answers questions and approves exceptions?
The AI acceptable use policy template, section by section
If you are asking what to include in an AI policy, the fourteen sections below are a practical answer. Each gives its purpose, the decisions leadership must make, and example wording to adapt. Replace bracketed items with your own terms.
1. Purpose
Why it exists: to state in two or three sentences why the policy matters. Decision: whether the tone is enabling or restrictive.
[Company] supports the use of AI tools to improve the quality and speed of our work. This policy sets the rules that protect our clients, our data and our reputation while we do so.
2. Scope
Why it exists: to define who and what is covered. Decisions: whether contractors, vendors and temporary staff are included, and whether personal devices and personal AI accounts are covered when used for company work. One public-sector model, Newfoundland and Labrador's responsible AI policy, applies to everyone working on behalf of government, including vendors and third-party service providers.
This policy applies to all employees, contractors, consultants and temporary staff, and to any AI tool used for [Company] work, whether accessed on a company or personal device. Personal AI accounts may not be used for company work unless the tool appears on the approved list.
For vendors who handle your data, add a matching clause to their contracts. The policy binds your people; the contract binds theirs.
3. Definitions
Why it exists: to remove ambiguity. Define only the terms the policy uses. Decision: whether AI features embedded in existing software count as AI tools. They should.
AI tool: any software that generates text, images, code, audio or analysis in response to prompts, including AI features inside otherwise approved applications. Approved AI tool: a tool listed in the AI tool register maintained by [owner]. Output: anything an AI tool produces.
4. Permitted uses
Why it exists: to tell people what they can do, so the policy is not read as a ban. Decision: which everyday tasks you want to encourage.
Employees may use approved AI tools for drafting and editing, summarizing documents they are authorized to access, research, brainstorming and coding assistance, subject to the data and review rules in this policy.
5. Prohibited uses
Why it exists: to draw a few bright lines. Decision: the short list of uses that are never acceptable, regardless of tool.
Employees must not use AI tools to make final decisions about hiring, compensation, discipline or eligibility without human review; impersonate a real person; produce deceptive, discriminatory or harassing content; bypass security controls; or process data in a tool not approved for that data class.
6. Data handling and classification
Why it exists: most AI risk comes from data going to the wrong place, so this is the section that matters most. Decision: map each data class to each tool tier. A table is clearer than prose.
| Data class | Examples | Public or personal AI tools | Approved company AI tools | |---|---|---|---| | Public | Published marketing, public filings | Allowed | Allowed | | Internal | Internal memos, process documents | Not allowed | Allowed | | Confidential | Client data, contracts, financials, unreleased strategy | Not allowed | Allowed for approved use cases | | Restricted | Personal data, health information, Controlled Unclassified Information, credentials, privileged legal material | Never | Only in tools specifically approved for that data, otherwise never |
Employees must not enter confidential or restricted information, including client data, personal information, credentials or non-public financial information, into any public or personal AI tool. When unsure of a classification, treat the information as confidential and ask [owner].
Also state whether chat history or training settings must be disabled in approved tools, and how employees should handle a prompt that accidentally included sensitive data.
7. Human review and verification
Why it exists: AI output can be wrong, fabricated or out of date while sounding certain. A named person must be accountable for anything that leaves their hands. Decision: which output types need a qualified second reviewer, not just the author.
The employee who uses an AI tool is responsible for the accuracy of its output. The following require review by a qualified second person before use: client deliverables; legal language or contract terms; financial figures, forecasts or filings; and code before it is merged into production. Citations, figures and quotations produced by AI must be checked against the original source.
8. Disclosure
Why it exists: to set when AI use must be disclosed internally and to clients. Decisions: whether existing client contracts already restrict or require disclosure of AI use, and what your clients expect.
Employees must tell their manager when a work product is substantially AI-generated. AI use must be disclosed to a client where a contract requires it, where the client has asked, or where the deliverable represents professional judgment the client is paying for.
9. Intellectual property
Why it exists: to protect your IP and avoid infringing others'. Decision: whether counsel should advise on ownership of AI-assisted work, especially for anything you sell.
Employees must not enter proprietary source code, unreleased designs or third-party copyrighted material into AI tools unless the tool is approved for that use. AI output intended for publication, sale or inclusion in products must be reviewed for similarity to existing protected work.
10. Accountability and ownership
Why it exists: a policy without a named owner decays. Decisions: who owns it (often the senior security, technology or legal leader), who approves it (the CEO or executive team, with the board informed), and what managers are responsible for. Federal agencies offer a precedent: the OMB draft memo on agency AI use proposed that each agency designate a Chief AI Officer. You do not need the title, but you do need a name.
This policy is owned by [title], who maintains the AI tool register, answers questions and approves exceptions. It is approved by [CEO or executive team]. Managers are responsible for their teams' compliance.
11. Exceptions
Why it exists: legitimate needs will fall outside the rules. Decision: who can grant exceptions and for how long.
Requests to use an unapproved tool or process a restricted data class must be submitted in writing to [owner], stating the business need, the data involved and the duration. Exceptions are time-limited and recorded.
12. Training and acknowledgment
Why it exists: people follow rules they understand. The Newfoundland and Labrador policy pairs its rules with mandatory training for the same reason. Decision: timing and frequency.
All personnel must complete AI use training before using AI tools for company work and annually thereafter, and must acknowledge this policy in writing.
13. Enforcement and incident reporting
Why it exists: to make consequences predictable and encourage early reporting. Decision: how to treat honest mistakes versus deliberate violations.
Report suspected misuse or accidental disclosure of data to [contact] immediately. Prompt self-reporting will be treated as a mitigating factor. Violations may result in loss of AI tool access and disciplinary action under [existing policy].
14. Review cadence
Why it exists: AI tools change faster than most policies. NIST itself describes its AI framework as a living document to be reviewed regularly. Decision: a fixed interval plus triggers. Given the pace of change, every six months is a sensible default.
This policy is reviewed at least every [six] months and whenever a significant new AI tool, client requirement or regulation affects it.
Rolling out the policy so it is followed, not filed
- Brief leadership first. Executives who use AI informally need to model the rules.
- Publish it with the approved tool list. People need to know what they can use, not only what they cannot.
- Train with your own examples. Show a realistic prompt that breaks the data rules and a compliant version of the same task.
- Collect acknowledgments. Record them at rollout, at onboarding and at each major revision.
- Open a question channel. Name where questions go and answer them quickly. Unanswered questions become workarounds.
- Treat early good-faith mistakes as coaching. Consistent, proportionate enforcement builds trust in the policy.
- Check in at 90 days. Ask teams what is unclear and update the policy and tool list.
If AI use is already happening outside approved tools, address that alongside rollout. Our article on writing a shadow AI policy covers that problem.
Common mistakes that make AI policies ineffective
- Vagueness. Instructions such as "use AI responsibly" give employees nothing to act on. Name the data, the tools and the review steps.
- Banning AI outright. Use moves to personal accounts and devices, where you have no visibility.
- No named owner. Questions go unanswered and the tool list goes stale.
- No approved tool list. Employees cannot comply with a policy that never says yes.
- Copying a template unchanged. Generic data categories rarely match your contracts or your clients. Any AI policy for business template, including this one, is a starting point.
- Ignoring embedded AI. AI features inside existing software process company data too.
- Never reviewing it. A policy written for last year's tools will not fit this year's.
How the policy connects to contracts and regulation in Northern Virginia and DC
This is not legal advice, but several obligations common in this region shape the policy's data and disclosure sections.
Federal contractors often handle Controlled Unclassified Information and are bound by contract clauses on where that information may be stored and processed. Entering it into an AI tool is processing it, so the data table should reflect those clauses. Our article on government contractor cybersecurity covers the wider picture.
Federal buyers are also setting expectations for AI itself. OMB memorandum M-26-04 applies to large language models procured by federal agencies and calls for outputs that are truthful and acknowledge uncertainty. It governs agency procurement of models, not contractors' internal policies, but firms delivering AI-assisted work to agencies would be wise to show how that work is checked. The human review section is where that lives.
Client confidentiality obligations in NDAs, master service agreements and professional rules for legal, accounting and advisory firms may restrict AI use or require disclosure. Have counsel review the data, disclosure and intellectual property sections against your key contracts before you publish. For the broader governance context the policy sits within, see our AI governance page.
Decide first, then write
A good AI acceptable use policy is short, specific and owned. Settle posture, tool tiers, data classes and ownership before drafting. Then work through the sections above, adapt the example wording to your own data and contracts, and pair publication with an approved tool list, training and acknowledgment. Review it on a fixed schedule. The writing is the easy part; the decisions behind it are what make it work.
If you want help assessing your exposure, start with the free AI risk assessment. It takes five minutes and gives you a baseline score right away.
For the field guide version of what I publish here each week, pick up a copy of Exposed: Inside Risks and the New Architecture of AI Defense on Amazon.
NightFortress works with executives, founders and leadership teams in Northern Virginia and the DC metro area to assess exposure, govern risk, and build security programs that match the actual threat landscape. Contact us to start a conversation.
The information in this article is for educational and informational purposes only. It is not intended as legal, compliance, or professional cybersecurity advice for any specific organization. Consult qualified professionals before making security or compliance decisions.