AI Acceptable Use Policy: What to Include (Checklist)

Short answer: An AI acceptable use policy tells employees which AI tools they may use, what information they may put into them, how AI output must be checked, and who approves new AI uses. A useful policy covers about a dozen topics: scope, approved tools, data rules, prohibited uses, human review, accounts, intellectual property, vendor review, AI agents and integrations, incident reporting, training, and enforcement. Keep it short enough that people read it, and back it with an approved-tools list that you update as tools change.

Why do you need an AI acceptable use policy?

Most organizations already use AI, whether or not anyone approved it. Staff paste emails into chatbots, turn on AI features inside existing software, and connect assistants to their inboxes and files. Without a policy, three problems follow:

Data exposure. Customer data, contracts, source code, or regulated information ends up in tools nobody has vetted.
Unreliable output. AI-generated content goes to customers or into decisions without anyone checking it.
Questions you can’t answer. Customer security questionnaires now ask which AI tools you use and whether customer data is used to train models. “We don’t have a policy” is a weak answer.

A policy is also the starting point for formal AI governance. The NIST AI Risk Management Framework places policies and accountability in its Govern function, and ISO/IEC 42001 requires an AI policy as part of an AI management system.

The 12 sections to include

#	Section	What it should answer
1	Purpose and scope	Who the policy applies to (employees, contractors, interns) and what counts as “AI”: chatbots, AI features in existing software, coding assistants, and agents
2	Approved tools	Which tools and plans are approved, where the current list lives, and how to request a new one
3	Data rules	What data may go into which tools, mapped to your data classification
4	Prohibited uses	Uses that are never allowed, regardless of tool
5	Human review of output	When AI output must be checked, by whom, and before what
6	Accounts and access	Company accounts only, SSO and MFA, no personal accounts for work data
7	Intellectual property and confidentiality	Ownership of outputs, third-party content, and client confidentiality obligations
8	Vendor and tool review	What security, privacy, and data-use checks happen before a tool is approved
9	AI agents and integrations	Rules for tools that take actions or connect to email, files, code, or business systems
10	Incident reporting	What to report (such as data pasted into the wrong tool) and to whom
11	Training and acknowledgment	Who must be trained and how acceptance is recorded
12	Enforcement, exceptions, and review	Consequences, how exceptions are approved, and who updates the policy

What should the data rules say?

This is the most important section, so make it concrete. Tie it to the data categories you already use:

Data type	Example rule
Public	Allowed in any approved tool
Internal	Allowed only in approved business tools with data-use protections
Confidential / customer data	Allowed only in tools approved for that data, under contract terms that rule out model training on your data
Personal information (PII)	Only where an approved use case and legal basis exist; minimize what you share
Regulated data (CUI, health information, payment data)	Not allowed unless the tool and its hosting environment are specifically approved for that data

Defense contractors need to be especially careful. Controlled Unclassified Information (CUI) may only go into systems that meet your contractual safeguarding requirements, such as NIST SP 800-171 under DFARS 252.204-7012. Most consumer and standard business AI tools aren’t set up for that. See what CUI is if you’re unsure what’s covered.

What uses should be prohibited?

Typical prohibited uses include:

Entering passwords, API keys, or other credentials into AI tools.
Using personal AI accounts for company or customer work.
Making final decisions about people (hiring, firing, credit, benefits) based solely on AI output.
Presenting AI-generated content as verified fact, legal advice, or professional advice without qualified review.
Generating content that is deceptive, discriminatory, or infringes others’ rights.
Bypassing security controls or using AI to access systems or data you’re not authorized to use.

How should AI agents and integrations be handled?

AI agents don’t just answer questions. They read email, browse, write code, and take actions. That changes the risk. The OWASP Top 10 for LLM Applications lists risks such as prompt injection (hidden instructions in content the AI reads) and excessive agency (an AI system with more permissions than it needs). Your policy should require:

Approval before connecting an AI tool to email, file storage, code repositories, CRM, or other business systems.
Least privilege. Agents get only the access the task requires, ideally read-only by default.
Human approval for consequential actions, such as sending external messages, making payments, deleting data, or changing production systems.
Logging, so you can reconstruct what an agent did.
A named owner for each agent or integration.

If you’re building AI features into your own products, the policy is only a start. Those systems need a secure design review against the OWASP lists. Our AI Security & Governance page explains how that works.

How do you roll the policy out?

Inventory current use. Ask teams which AI tools and features they actually use. You’ll find more than you expect.
Decide on approved tools and publish the list where people can find it.
Write the policy with short, plain rules and examples.
Train and collect acknowledgments. A 20-minute session with real examples works better than a long document.
Make requests easy. If approval is slow, people use unapproved tools anyway.
Track AI risks in your risk register alongside your other cybersecurity risks.
Review regularly. AI tools and features change quickly. Review the policy and tool list on a set schedule and whenever a major new tool or use case appears.

Frequently Asked Questions

Should we ban AI tools instead of writing a policy?

Usually not. Bans tend to push use onto personal accounts, which is harder to see and riskier. A policy with a short list of approved tools gives people a safe option and gives you visibility.

Is an AI acceptable use policy the same as an AI governance policy?

No. An acceptable use policy tells employees how to use AI tools. A broader AI governance policy also covers how the organization selects, builds, deploys, and monitors AI systems, including risk assessments and accountability. Many small and mid-sized organizations start with the acceptable use policy and expand from there.

Do we need a separate policy, or can we add AI to our existing policies?

Either works. Smaller organizations often add an AI section to their acceptable use policy. A standalone policy is easier to update as tools change, and it’s easier to point to when customers ask.

Which frameworks should the policy align with?

The NIST AI Risk Management Framework and its Generative AI Profile (NIST AI 600-1) are practical, free references. If customers expect a certifiable AI management system, ISO/IEC 42001 requires a documented AI policy. See our frameworks overview for how these fit together.

How USCIBER can help

USCIBER’s AI Security & Governance service helps you inventory the AI tools already in use, write an AI acceptable use policy that fits how your team works, assess AI risk, and prepare for frameworks such as the NIST AI RMF and ISO/IEC 42001. AI governance can also be part of an ongoing vCISO engagement. AI work is scoped after a short call. Engagements are led by security leadership holding CISSP, CISA, and CISM credentials.

Sources

This article is general information, not legal advice.

AI Acceptable Use Policy: What to Include