Back to blog
Templates

AI Acceptable Use Policy: What to Include (With Template)

Govarna Editorial Team Published May 8, 2026 Updated July 13, 2026 12 min read
AI acceptable use policy document showing allowed, restricted, review, and reporting sections
Disclaimer: The template text below is provided as an open-source baseline under the MIT License. It does not constitute formal legal advice. You must customize all placeholders and review the completed policy with qualified legal counsel before adoption.

TL;DR — Key Takeaways

  • An AI acceptable use policy is your first governance artifact: It defines which AI tools employees may use, what data may enter them, and how AI output must be reviewed — before you build risk registries or tackle framework compliance.
  • Tiered tool catalogs beat blanket bans: Classify tools as Approved / Restricted / Prohibited with a fast approval path for new tools. Bans just push usage into shadow AI on personal accounts.
  • The EU AI Act makes this urgent: Article 4 AI literacy obligations have applied since February 2, 2025. Under the May 2026 political agreement, rules for systems in certain high-risk areas—including related Article 26 deployer duties—are scheduled for December 2, 2027, with product-integrated high-risk rules scheduled for August 2, 2028.
  • Nine sections cover the essentials: Purpose & scope, tool tiers, data isolation, code review, new-tool approval workflow, incident reporting, training, review cadence, and enforcement.
  • Free template below: The full policy text is MIT-licensed — copy it, replace the bracketed placeholders, and have counsel review before adoption.

What is an AI acceptable use policy?

An AI acceptable use policy is an internal document that defines which AI tools employees and contractors may use, what data may be entered into them, how AI-generated output must be reviewed before use, and what happens when the rules are broken. It is the foundational artifact of an AI governance program — the piece everything else builds on.

Before you build a complex AI risk registry or tackle EU AI Act compliance, you need basic alignment on employee behavior. If your engineers are pasting customer code or sensitive API payloads into unvetted public LLM helpers, your company faces immediate data leakage risk — and an awkward silence when an enterprise buyer's AI security questionnaire asks "Do you have a documented policy governing employee use of AI tools?"

A good policy is short enough to be read (2–3 pages), specific enough to be followed (named tools, concrete data categories), and maintained enough to be trusted (a named owner and a review cadence). The template later in this article gives you all three.

Why do you need an AI acceptable use policy now?

Three forces converge in 2026: Article 4 AI literacy obligations already apply, Article 50 transparency obligations apply from August 2, 2026, enterprise buyers routinely ask for an employee AI policy, and unmanaged "shadow AI" usage keeps growing. A written policy is the cheapest, fastest response. Under the May 2026 political agreement, high-risk rules are scheduled later; the revised dates are not yet part of the original Regulation text. (Source: European Commission AI Act overview)

In more detail:

  • EU AI Act — AI literacy (Article 4): Since February 2, 2025, providers and deployers must ensure a sufficient level of AI literacy among staff dealing with AI systems. An acceptable use policy plus training and acknowledgment records is the standard way to evidence this.
  • EU AI Act — deployer obligations (Article 26): If any tool your team uses qualifies as a high-risk system under Annex III (e.g., AI-assisted candidate screening), deployer duties include use per instructions, competent human oversight, and operation monitoring. Under the May 7, 2026 political agreement, rules for systems in certain high-risk areas are scheduled for December 2, 2027, while product-integrated high-risk rules are scheduled for August 2, 2028; final legal adoption is not yet complete. Your policy is where those duties get assigned to real people. Non-compliance with high-risk obligations can draw fines of up to EUR 15 million or 3% of global annual turnover (Article 99(4)). (Source: European Commission high-risk guidance)
  • Buyer due diligence: AI sections in vendor security questionnaires increasingly ask for the employee AI policy by name. Having a versioned, approved PDF ready shortens security review cycles; scrambling to write one mid-deal extends them.
  • Shadow AI: Without an approval path, employees adopt AI tools on personal accounts where you have no visibility, no data processing agreement, and no retention guarantees. A policy with a fast Tier system channels that demand into vetted tools.
  • Framework alignment: ISO/IEC 42001 requires a documented AI policy as part of the management system, and the NIST AI RMF GOVERN function starts with exactly this artifact. Writing it now gives you a head start on both.

What should an AI acceptable use policy include?

A complete AI acceptable use policy contains nine sections: purpose and scope, a tiered catalog of approved tools, data isolation rules, code generation review requirements, an approval workflow for new tools, incident reporting procedures, training and acknowledgment, a periodic review cadence, and enforcement consequences. The table below explains what each section does and the mistake teams most often make with it.

Policy SectionPurposeCommon Mistake
Purpose & scopeStates who is covered (employees, contractors, third parties) and which activities the policy governsCovering only employees and forgetting contractors and agency staff, who often have the same system access
Approved tool tiersClassifies tools as Approved / Restricted / Prohibited so people know instantly what they may useListing specific tools with no named owner to update the catalog, so it's stale within a quarter
Data isolation rulesDefines exactly what data may never enter restricted tools (customer data, credentials, PII, source code)Writing a vague "no sensitive data" rule with no concrete examples, leaving judgment to each employee
Code generation & reviewRequires human review of AI-generated code before merge and assigns responsibility for the outputAssuming license and IP provenance risk is the coding assistant vendor's problem — the merged code is yours
New-tool approval workflowGives employees a fast, defined path to request tools, with vetting criteria and a decision deadlineOmitting this section entirely — bans without an approval path manufacture shadow AI
Incident reportingTells people what to do when data is accidentally exposed to an AI tool, and by whenPunitive framing that discourages self-reporting; you want incidents surfaced within hours, not hidden
Training & acknowledgmentRequires AI literacy training and a signed acknowledgment — your Article 4 evidence trailOne mention during onboarding with no records; auditors and buyers ask for acknowledgment logs
Review cadenceCommits to reviewing the policy on a schedule and after trigger events (new tools, incidents, regulation changes)Publishing version 1.0 and never touching it again — a 2024-dated AI policy signals neglect in 2026
EnforcementStates consequences for violations so the policy has teethStating consequences that are never applied, which teaches the team the policy is decorative

Corporate AI Acceptable Use Policy Template (MIT-Licensed)

Copy and adapt the template below. Replace all bracketed items [like this] with your company details, then have qualified legal counsel review before adoption.

### [COMPANY] — Employee AI Acceptable Use Policy Version: 1.1 Last Updated: [Date] Policy Owner: [Security/Legal Officer] Approved By: [Executive Sponsor] 1. Purpose The purpose of this policy is to define the guidelines and restrictions governing [COMPANY]'s employees and contractors using artificial intelligence (AI) tools, Large Language Models (LLMs), and automated assistants in their professional workflows. 2. Scope This policy applies to all employees, contractors, and third-party personnel who access [COMPANY]'s systems, source code, or process customer payloads, regardless of whether they use company-managed or personal devices for work tasks. 3. Approved AI Tooling Categories Personnel may only use AI tools that have been explicitly cataloged in [COMPANY]'s internal software directory: a) Tier 1 (Fully Approved): Tools with enterprise-level, zero-data-retention API contracts (e.g., [COMPANY]'s internal chat bot, or enterprise-tier Microsoft Copilot). b) Tier 2 (Restricted): Public consumer tools (e.g., standard ChatGPT, Claude, Gemini). Data uploaded here MUST NOT contain customer production data, proprietary source code, or personally identifiable information (PII). c) Tier 3 (Prohibited): Unapproved browser extensions, shadow coding assistants, and any system using uploaded payloads for foundation model training. Any AI tool not listed in the directory is Tier 3 (Prohibited) by default until approved under Section 6. 4. Data Isolation & Security Safeguards Under no circumstances shall personnel input the following into Tier 2 (Restricted) tools: - Customer database payloads or backups. - Private encryption keys, passwords, API tokens, or system configurations. - Personally Identifiable Information (PII) of clients, staff, or users. - [COMPANY] proprietary source code or product blueprints. - Contents of documents marked Confidential or Restricted under [COMPANY]'s data classification policy. 5. Code Generation & Human Review If engineers use approved coding assistants (e.g., GitHub Copilot Enterprise), they must manually verify all generated code before merge. Personnel are fully responsible for the integrity, security, licensing, and performance of any AI-derived deliverables. AI-generated code is subject to the same code review standards as human-written code. 6. Requesting Approval for New AI Tools Personnel who wish to use an AI tool not yet cataloged must submit a request to [SECURITY CONTACT] including: (a) the vendor and product name, (b) the intended use case and data categories involved, (c) the vendor's data retention terms, and (d) whether uploaded data is used for model training. The Policy Owner will assign the tool to a Tier and respond within [5] business days. Until a decision is issued, the tool remains Prohibited. 7. Incident Reporting Personnel who become aware that restricted data (Section 4) was entered into a Tier 2 or Tier 3 tool — by themselves or others — must report it to [SECURITY CONTACT] within [24] hours of discovery. Reports must include the tool used, the data involved, and the approximate time of exposure. Good-faith self-reporting will not, by itself, result in disciplinary action; concealment of a known incident will. 8. Training & Acknowledgment All personnel in scope must complete [COMPANY]'s AI acceptable use training within [30] days of hire and annually thereafter, and must sign an acknowledgment of this policy. The Policy Owner maintains training and acknowledgment records. 9. Policy Review Cadence The Policy Owner will review this policy at least every [6/12] months, and additionally upon any of the following triggers: adoption of a new category of AI tooling, a material change to an approved vendor's data handling terms, an incident under Section 7, or a relevant regulatory change. Each review is recorded with date, reviewer, and version number. 10. Violations & Enforcement Violation of this policy may lead to disciplinary action, up to and including termination of employment or contract. --- License: This policy text is released under the MIT License. You may copy, modify, and use it freely, including commercially, without attribution.

Buyer asking for your AI policy right now?

If this template landed on your desk because an enterprise prospect sent an AI security questionnaire, try our free AI questionnaire tool — it drafts consistent, evidence-backed answers from your governance artifacts, including this policy.

Try the Free Questionnaire Tool

How do you roll out an AI acceptable use policy?

Rollout is a seven-step process: inventory current AI usage, customize the template, get legal and executive sign-off, announce it with training, collect acknowledgments, wire the approval workflow into an existing channel, and calendar the first review. Most mid-size teams complete this in two to three weeks.

  1. Inventory current AI usage first. Before writing tier lists, survey the team (anonymously if needed) about which AI tools they actually use. Policies written against imagined usage miss the real risks; you will almost certainly discover tools you didn't know about.
  2. Customize every placeholder. Name the exact tools in each tier, the real security contact, and concrete deadlines. A policy that still says [COMPANY] in paragraph three tells employees nobody read it — including you.
  3. Get formal sign-off. Have legal counsel review the customized text, then have an executive sponsor approve it. Record both approvals with dates; buyers and auditors ask who approved the policy and when.
  4. Announce with training, not just a link.A 20–30 minute session covering the tier system, the data isolation rules, and — critically — the approval path for new tools. This session doubles as your EU AI Act Article 4 AI literacy evidence.
  5. Collect signed acknowledgments. Use your HR system or document tool to track who has acknowledged the policy. Chase stragglers. An acknowledgment log is one of the first artifacts requested in enterprise security reviews.
  6. Make the approval workflow real. Create the actual request channel (a form, a Slack workflow, an email alias) and honor the response deadline in Section 6. If requests take a month, employees stop asking and shadow AI returns.
  7. Calendar the first review now. Put the 6- or 12-month review date in the Policy Owner's calendar before you publish. Then store the approved PDF in your evidence vault so it can be attached to questionnaire responses immediately.

How does this policy fit into your broader AI governance program?

The acceptable use policy is the first of several governance artifacts; it governs employee behavior, while an AI inventory, risk classifications, and framework mappings govern the systems themselves. Each major framework expects the policy and builds outward from it:

  • EU AI Act: The policy operationalizes Article 4 (AI literacy) and assigns the human oversight and monitoring duties in Article 26 for any high-risk systems you deploy. Next, classify every AI system you use against Annex III — our free deployer assessment walks through that in about 2 minutes — then work the full EU AI Act compliance checklist.
  • ISO/IEC 42001: The standard requires a documented AI policy as part of the AI management system, and several of the 38 Annex A controls (covering areas like resources for AI systems, impact assessment, and use of AI systems) assume one exists. See our ISO 42001 compliance guide.
  • NIST AI RMF: The GOVERN function calls for policies, processes, and accountability structures for AI risk — this policy is the natural first deliverable. Our practical NIST AI RMF guide shows where it slots in.
  • Sales enablement: Once approved, the policy becomes a reusable answer for the employee-AI-use section of every security questionnaire you receive.

Frequently Asked Questions

Is an AI acceptable use policy required by the EU AI Act?

Not by that name — the Act never mandates a document called an "acceptable use policy." But Article 4 (AI literacy) and, for deployers of high-risk systems, Article 26 (use per instructions, competent oversight, monitoring) are difficult to evidence without one. Regulators and auditors expect to see how obligations are assigned to people, and this policy is the standard vehicle.

Who should own the policy?

One named person — typically the security lead or CISO, or the CTO in smaller companies. The owner maintains the tool catalog, handles Section 6 approval requests, and runs the periodic review. Ownerless policies decay fast because nobody re-tiers new tools as they appear.

Can we just ban public AI tools entirely?

You can, but it rarely works. Employees who find AI genuinely useful will route around a ban with personal accounts and devices, and you lose all visibility. A tiered policy with a fast approval path converts that demand into vetted usage you can actually see and govern — and gives you a stronger questionnaire answer than "we prohibit it" (which sophisticated buyers read as "we don't know what our employees do").

Does this policy cover AI features we build into our product?

No — this template governs employee use of AI tools. AI features you ship to customers need separate treatment: risk classification under the EU AI Act, model documentation, Article 50 transparency where applicable from August 2, 2026, and the relevant provider or deployer obligations if high-risk. Under the May 2026 political agreement, rules for systems in certain high-risk areas are scheduled for December 2, 2027 and product-integrated high-risk rules for August 2, 2028. Start with the Annex III classification guide.

How often should we review it?

Every 6–12 months on schedule, plus after trigger events: a new tool category enters use, an approved vendor changes its data terms, an incident occurs, or regulation changes. Record every review with date, reviewer, and version number.

Generate and Map Policies Instantly

Govarna provides editable policy workflows for AI Acceptable Use, Incident Response, and Vendor Risk, mapping them to security controls and retaining acknowledgment evidence for review.

Get Started Free