SELINA.ai
Sign in
ai acceptable use policy

How to Write an AI Acceptable Use Policy That Actually Works

An AI acceptable use policy is the document that stands between your organization and a slow-moving disaster. Not a hypothetical one. The kind where an employee pastes customer records into a chatbot, the provider's terms say submitted data may be used for model training, and you find out about it during an audit. Or from a regulator. The policy itself is straightforward to draft. The hard part is making it enforceable, specific enough to survive contact with real workflows, and durable enough to outlast the next model release cycle. This piece covers how to do all three.

Key Takeaways

Why Do You Need an AI Acceptable Use Policy Right Now?

Because your employees are already using AI tools whether you have a policy or not. A 2026 PagerDuty survey of 1,250 office professionals at companies with over $500 million in revenue found that 66% had used AI tools at work despite believing those tools were not permitted by company policy. Verizon's 2026 Data Breach Investigations Report found shadow AI detections rose fourfold in a single year, with 45% of employees now regular AI users on corporate devices. Nearly 98% of organizations have employees using unsanctioned AI tools or apps.

The legal environment has caught up. Texas, Illinois, California, Colorado, and the EU all have enforceable AI laws imposing requirements around transparency, data protection, and accountability. Penalty structures vary sharply by state: Utah starts at $2,500 per violation, Colorado allows up to $20,000, California scales by number of affected individuals, and New York permits civil penalties up to $1 million for a first violation and $3 million for subsequent ones. A documented, enforced AI acceptable use policy is the baseline evidence regulators and auditors look for.

And then there is the training-data problem. Many AI tools only keep submitted data private under specific contract terms. Without a negotiated data processing agreement, anything your employees type into a prompt may end up in the provider's training pipeline. Your policy needs to account for this, because your employees will not read the provider's terms of service. You know this.

What Should an AI Acceptable Use Policy Actually Contain?

It should contain specific, auditable rules. Not principles. Not aspirations. Rules that a confused employee at 4:30 PM on a Friday can follow without calling legal. Here is what belongs in the document, section by section.

Scope and Applicability

Define what counts as an "AI tool" for the purposes of the policy. This sounds obvious, but it is not. Autocomplete in an email client, a spreadsheet formula suggestion, a code assistant integrated into the IDE, a standalone chatbot: your employees interact with AI at different layers, and the risk profile differs for each. State which categories are covered. State who is covered: employees, contractors, interns, vendors with access to company systems.

Data Classification Tiers

This is the section most templates get wrong or skip entirely. Before you can tell someone which tools they may use, you need to tell them which data they may share. A three-tier model works for most organizations:

Color-code them if you want. The point is that every employee should be able to look at a piece of data and know its tier in under five seconds. If they cannot, the classification scheme is too complicated.

Tool Tiers: Approved, Tolerated, Banned

Maintain a living list. "Approved" tools have negotiated contracts, verified DPAs, and confirmed data-handling terms. "Tolerated" tools are permitted for public-tier data only, pending formal review. "Banned" tools have been evaluated and rejected, or have terms that allow training on submitted data without adequate contractual protections. Update the list quarterly at minimum.

Human Review Requirements

Specify which AI-generated outputs require human approval before they reach a customer, a regulator, or a public channel. A useful one-page policy framework proposes a single sign-off rule: no AI-generated content reaches a customer without human approval. That is a clean, memorable rule. Adjust the threshold to your risk tolerance, but have a threshold.

Prohibited Uses

Be explicit. Common prohibitions include: entering restricted-tier data into any AI tool without a verified DPA; using AI to make or materially influence employment decisions without disclosure (several states now require this); generating content that impersonates a real person; relying on AI output for legal, medical, or financial advice without qualified human review; circumventing technical controls to access banned tools.

Incident Reporting and Consequences

Describe what happens when someone violates the policy. Not in vague terms. State who to contact, what constitutes a reportable incident, and the range of consequences. If there are no consequences, you do not have a policy. You have a pamphlet.

Where Can You Find an AI Acceptable Use Policy Template?

Templates are everywhere. ISACA published one aligned to their governance frameworks. dope.security offers a free 2026 version with enforcement guidance. Strac's template maps to NIST AI RMF, ISO 42001, HIPAA, and SOC 2. FRSecure, centrexIT, Menturi, Lattice, MangoApps, AIHR, PurpleSec, and Adelia Risk all have downloadable versions. The Texas Department of Information Resources published its own as a PDF in April 2026.

The problem is not finding an AI acceptable use policy template. The problem is that most of them are written for organizations with a dedicated risk committee, a CISO, and a legal team that can customize 15 pages of boilerplate. If you are a 40-person company, you need something shorter. One recent approach proposes a one-page policy built around three components: a named list of approved tools, three color-coded data classes, and a single sign-off rule. That is a better starting point for most small and mid-size organizations than a 20-page enterprise framework they will never finish customizing.

Whichever template you start from, treat it as a skeleton. The value is in the specifics you add: your data classification scheme, your actual approved tools, your actual DPA status with each provider, your actual reporting chain. A template with "[INSERT COMPANY NAME]" placeholders that ships unchanged is not a policy. It is a liability.

How Do You Enforce an AI Use Policy When Shadow AI Is Everywhere?

You enforce it with technical controls, not memos. A common framing in 2026 puts it plainly: a rule against pasting PHI into a chatbot without a technical control to block it is a wall with no gate. The policy is the easy part. Enforcement is the hard part.

Technical enforcement typically involves some combination of:

None of these are perfect. A determined employee on a personal device on a personal network is outside your technical perimeter. This is why the policy also needs a cultural component: employees need to understand why the restrictions exist, not just that they exist. Fewer than half of employees even understand the AI usage policy that is supposed to govern their behavior. If the policy is unread, it is unenforced by definition.

Is Shadow AI a Discipline Problem or a Procurement Problem?

It is mostly a procurement problem. Consider the demand side: employees adopt unsanctioned AI tools because the sanctioned alternatives are worse, slower, or nonexistent. Surveys consistently show that a majority of knowledge workers use their own AI tools because they prefer the independence, and a significant minority say IT simply does not offer what they need. Banning tools without providing a credible alternative is a policy that incentivizes its own violation.

The practical implication for your AUP: pair every "banned" designation with a "use this instead" recommendation. If you ban a particular chatbot, name the approved alternative and confirm it actually works for the use case. If no approved alternative exists, that is a procurement task, not a policy task. Fast, privacy-safe procurement of AI tools, including DPA negotiation and data-flow verification, is the operational prerequisite for a policy that holds.

How Should the Policy Address Where Data Actually Goes?

This is the section nearly every template undersells. Approving a tool is not the same as understanding its data flow. When an employee submits a prompt to an AI service, that data may be processed in a jurisdiction you did not choose, retained for a period you did not negotiate, and (absent contractual terms to the contrary) used to train the provider's next model.

Your policy should require, for each approved tool:

  1. A verified data processing agreement that specifies retention terms, training opt-out status, and data residency.
  2. Documentation of which data tiers are permitted for that tool, based on the DPA terms, not on marketing claims.
  3. A named owner (a person, not a department) responsible for re-verifying the DPA at each contract renewal or terms-of-service change.

This is more work than maintaining a simple approved/banned list. It is also the only version that survives an audit. When a regulator or an insurance underwriter asks "how do you know restricted data did not enter an unauthorized training pipeline," you need to show the data-flow map and the contractual controls, not just the policy document.

What Does the 2026 Regulatory Landscape Mean for Your Policy?

It means the policy is no longer optional and the requirements are not uniform. New AI laws in Texas, Illinois, California, Colorado, and the EU impose enforceable requirements around transparency, data protection, and employee accountability. These are not aspirational frameworks. They carry penalties.

A few specifics worth tracking:

Connecticut's SB 5, signed in May 2026, rolls out in two phases. By October 2026, employers must disclose AI-related mass layoffs to the state Department of Labor. By October 2027, employers must give written notice when automated decision tools are used in employment decisions. Your policy should already address employment-related AI use, because by the time the second phase hits, you want the policy to predate the requirement.

The ground is also still shifting. A federal court in April 2026 enjoined enforcement of the Colorado AI Act pending a preliminary-injunction ruling (xAI v. Weiser), which means even enacted laws may face implementation delays or modifications. Your policy cannot depend on a single regulatory snapshot. Build it around data classification and human review principles that hold regardless of which specific state provisions survive judicial review.

If you operate in multiple states, assume the strictest applicable standard as your baseline. Maintaining separate policies per jurisdiction is a maintenance burden that will collapse within two quarters. One policy, written to the highest bar, is more durable.

How Do You Structure the Policy for Audits and Compliance Frameworks?

Think of the AI acceptable use policy as an evidentiary artifact, not an HR document. If you are pursuing SOC 2 Type II, preparing for ISO 42001 certification, or aligning to the NIST AI Risk Management Framework, the policy needs to map to specific control objectives.

Concretely, this means:

The gap most organizations fall into is what you might call "policy vs. proof." The policy exists, but there is no evidence it was followed. An auditor does not care that you wrote a rule against pasting customer data into a chatbot. They care whether you can demonstrate the rule was enforced, detected when violated, and corrected. The policy document is necessary but not sufficient. The enforcement artifacts are what close the loop.

What Mistakes Do Organizations Make When Drafting AI Policies?

The most common ones, in order of how much damage they cause:

Writing the policy for the legal team instead of for the employee. If the person most likely to violate the policy cannot understand it without a glossary, it will not be followed. Write at the reading level of your median employee. Use examples. "Do not enter customer names, email addresses, or support ticket contents into any AI tool not on the Approved list" is better than "Restricted data as defined in Section 3.2(a) shall not be processed by any system not enumerated in Appendix B."

Listing approved tools without verifying their data terms. Approval without DPA verification is theater. The provider's standard terms may change at any time. A tool that was safe to use last quarter may now retain prompt data for training. Approval must be tied to verified contractual status, reviewed on a schedule.

Ignoring the personal-device problem. Corporate device controls do not cover what employees do on their phones. If your policy only governs corporate-managed endpoints, it has a hole large enough to drive a data breach through. The policy should address use of AI tools for company purposes on any device, and acknowledge that technical enforcement is limited on unmanaged hardware. The cultural and disciplinary components carry more weight here.

Treating the policy as a one-time project. The AI tool landscape changes monthly. A policy written in January that has not been updated by July is already stale. Bake in a review cadence. Assign an owner. If nobody owns the policy, nobody updates the policy.

How Should You Roll Out the Policy to Your Organization?

Do not email a PDF and consider it done. Rollout is a distribution and comprehension problem, not a publishing problem.

A sequence that works:

  1. Announce with context, not just the document. Explain why the policy exists. Use specific examples of risk. "A company in our industry was fined $X because an employee entered client data into an unapproved tool" is more persuasive than "AI governance is important."
  2. Require a signed acknowledgment. Digital is fine. The signature is your audit evidence that the employee received and (ostensibly) read the policy.
  3. Run a short training session. Fifteen minutes. Walk through the data classification tiers with real examples from your business. Show the approved tool list. Show one example of a prohibited action and the correct alternative. Record it for new hires.
  4. Make the approved tool list findable. Pin it in your internal wiki, your Slack channel, wherever people actually look. If finding the approved list requires navigating three levels of an intranet, people will skip it and use whatever is convenient.
  5. Revisit comprehension after 90 days. A short quiz, a spot check, a team-level discussion. If fewer than half your employees understand the policy (which is the norm), the rollout failed regardless of how polished the document looked.

How Often Should You Update the Policy?

The structural framework (data tiers, human review rules, incident reporting) should be reviewed annually. The approved/banned tool list should be reviewed quarterly, because the market moves faster than that. Any of the following should trigger an immediate out-of-cycle review:

Date every revision. Keep prior versions accessible. Auditors will ask for the version that was in effect at a specific point in time, not just the current one.

What Does a Minimal Viable Policy Look Like?

If you are a small team and need something operational by Friday, here is the minimum that qualifies as a real policy rather than a gesture:

  1. A named list of approved AI tools, each with a link to the relevant DPA or data-handling documentation.
  2. Three data tiers (restricted, internal, public) with two concrete examples in each tier drawn from your actual business data.
  3. One clear rule: no AI-generated output reaches a customer, a regulator, or a public channel without human review and approval.
  4. A reporting contact for policy questions and suspected violations.
  5. A signature line confirming the employee has read and understood the policy.

That is one page. It is incomplete by enterprise standards. It is also better than the 15-page template sitting in a shared drive that nobody has customized and nobody has signed. Start here. Expand when you have the capacity to enforce what you add.

You can build on top of templates from Tenable, ISACA, or any of the sources linked above. Strip out what does not apply. Add what does. Ship it.

The policy is not the destination. It is the floor. Build the floor, then build the enforcement, the training, the procurement pipeline, and the audit trail on top of it. The organizations that treat the AI acceptable use policy as a living operational document, rather than a compliance checkbox, are the ones whose employees actually follow it.

Start a free 7-day trial, no card required.

Frequently Asked Questions

Why do organizations need an AI acceptable use policy now?

Employees are already using AI tools regardless of official policy, 66% in one survey used AI tools they believed were against company policy, and nearly 98% of organizations have unsanctioned AI use. State and international laws also now impose real penalties, from $2,500 per violation in Utah to $3 million for repeat violations in New York, making a documented policy the baseline evidence regulators expect.

What sections should a good AI acceptable use policy include?

It should cover scope and applicability, data classification tiers (restricted, internal, public), tool tiers (approved, tolerated, banned), human review requirements, prohibited uses, and incident reporting with real consequences. The goal is specific, auditable rules rather than vague principles.

How should data be classified in the policy?

A three-tier model works for most organizations: restricted data (like PII, PHI, financial records, source code) never goes into external AI tools without case-by-case approval and a verified data processing agreement; internal data may be used only with approved tools; and public data can be used with any approved-list tool.

Where can I find an AI acceptable use policy template?

Templates are widely available from sources like ISACA, dope.security, Strac, FRSecure, centrexIT, Lattice, and others, plus a Texas Department of Information Resources version. However, most are built for large organizations with dedicated legal and risk teams, so smaller companies may do better starting with a simpler one-page approach using approved tools, color-coded data classes, and a single sign-off rule.

How do you actually enforce an AI use policy against shadow AI?

Enforcement requires technical controls, not just written rules, such as DNS/proxy blocking of banned tools, DLP rules to catch restricted data in outbound requests, browser isolation policies, and endpoint monitoring of installed AI apps. Since these controls can't cover personal devices, the policy also needs a cultural component so employees understand the reasons behind the rules, not just the rules themselves.

Sources & References

Michael C.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

Learn more about Selina.ai