No law requires a private employer to have an AI acceptable-use policy. What the laws require is notice, documented risk assessments, records retention and, in one city, an audit. A policy is how you operationalize those. Here are the nineteen sections one needs, and what each has to decide.
The nineteen sections, and what each must establish
This structure is drawn from what recurs across published government, university and law-firm AI policies, with the gaps those policies share filled in. Policy text first. Cut the explanatory preamble; nobody reads it.
- Document control. Version, owner by role, effective date, review cadence, change log. At the top, not the back. Most published templates have a stub here or nothing.
- Purpose. Three sentences. Resist the essay.
- Scope. Who is bound: employees, contractors, temporary staff and vendors acting on your behalf. And which systems: chatbots, AI embedded in software you already buy, coding assistants, agents, meeting notetakers.
- Definitions. Only terms that change a rule. Do not define "artificial intelligence"; it consumes a review cycle and settles nothing.
- The permission matrix. Data classes against tool tiers. The load-bearing section, worked through below.
- Tool tiers. Defined by contract mechanism, never by product name.
- Allowable use. What staff may do without asking. Without this, your exception process becomes the shadow AI generator.
- Prohibited use. An enumerated list. Never write "use AI responsibly."
- Human review of outputs. Enumerate the triggers: external publication, code merged, customer-facing communication, any decision about a person, anything above a stated value.
- AI in employment decisions. Standalone, because this is where US exposure concentrates.
- Agents and autonomous actions. Blast-radius tiers, agent identity, named kill-switch owner.
- Coding assistants. Whether generated code may be committed, how it is tagged, whether agents may open pull requests unattended.
- Disclosure. Three separate decisions most templates conflate: external, internal, and the artifact convention.
- Shadow AI request path. How someone asks for a tool that is not yet approved.
- Exceptions. Named approver, decision deadline, maximum duration with automatic expiry, standing register.
- Incident reporting. What counts, to whom, how fast, and a non-retaliation clause.
- Roles and responsibilities, as a table. One row per role.
- Enforcement. Consequences proportionate to intent and data class, with manager accountability.
- Training, recorded. Map it to the EU obligation and to NIST's governance subcategory on workforce training, which reads: "The organization's personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures, and agreements." Note "and partners."
Two clauses to add that almost no published policy carries. A savings clause protecting employee communications about wages, hours and terms and conditions of employment, which is a labour-law protection under the National Labor Relations Act; employment counsel routinely include one, and the public-sector and university policies uniformly do not. And a bottom-up reporting duty, borrowed from the US General Services Administration, requiring staff to report unregistered AI use if they believe the system owner has not.
On ownership: in most mid-market organizations this document is drafted by whoever owns security policy, reviewed by legal and HR, and approved by whoever already signs the acceptable-use policy for IT. It is a two-week task if the tool inventory exists and a two-month task if it does not, which is the real reason these projects stall.
Our editable AI acceptable-use policy template has all nineteen drafted as clause text, with the enumerated prohibitions, the roles table and the exception register filled in.
The permission matrix
This is the section employees actually consult, and prose cannot express it because the rule has two dimensions. Your data classes are rows, your tool tiers are columns, and every cell is a yes or a no. Substitute your own classification scheme:
| Data class | Tier 1 (contracted) | Tier 2 (paid, admin-controlled) | Tier 3 (consumer / unapproved) |
|---|---|---|---|
| Public, already published | Allowed | Allowed | Allowed |
| Internal, non-sensitive | Allowed | Allowed | Prohibited |
| Confidential business (contracts, financials, unreleased plans) | Allowed | Prohibited | Prohibited |
| Personal data of employees or customers | Allowed only where the DPA covers the processing | Prohibited | Prohibited |
| Regulated or special category (health, payment, credentials, source code under license obligations) | Prohibited | Prohibited | Prohibited |
The bottom-left cell is the one that matters and the one nearly every template gets wrong. MIT's guidance is the only public policy I found that states it outright: do not use high-risk information with generative AI tools, "including MIT enterprise Generative AI tools," and contact security immediately if you already have. A contract that stops a vendor training on your data does not make that vendor an appropriate home for your most regulated records. Pair the rule with a named contact, as MIT does, because the value of that cell is entirely in what happens after someone breaches it.
For the version employees remember, the best published line is a test rather than a taxonomy. The UK's National Cyber Security Center puts it as not submitting queries "that would lead to issues were they made public." Fisher Phillips' sample policy has the blunter version: "Treat every bit of information you provide to an [sic] GenAI tool as if it will go viral on the Internet, attributed to you or the Company, regardless of the settings you have selected within the tool (or the assurances made by its creators)."
Define tiers by contract, not by brand
A list of approved products by name is wrong within months. The reason is worth showing rather than asserting.
Recently: Azure OpenAI became Microsoft Foundry, Vertex AI became the Gemini Enterprise Agent Platform, Microsoft 365 Copilot became Microsoft Copilot, and ChatGPT Team stopped appearing on OpenAI's own pages in favour of Business. Anthropic changed its consumer default in September 2025 so chats may be used for training where the user allows it, with retention moving from thirty days to five years. Google's Workspace AI privacy hub has been revised fifteen times since December 2024. And in 2025 a court order compelled OpenAI to retain consumer ChatGPT and API data in defiance of its own published thirty-day policy for five months, with Enterprise, Edu and zero-retention API customers explicitly exempt. When that order lifted in October 2025, OpenAI noted it still held limited historical data from the covered window.
A policy naming products inherits every one of those as a defect. Write the tiers by what the contract says instead:
- Tier 1, approved for regulated data. Signed data processing agreement, contractual commitment not to train on your data, single sign-on, defined retention and residency, current SOC 2 or ISO evidence. Our 50-question vendor questionnaire is the diligence set behind that tier.
- Tier 2, approved for internal non-sensitive data. A paid organizational account with administrative control, but without the full contract set.
- Tier 3, prohibited. Everything else, stated to include free and personal accounts of the same products that appear on the Tier 1 list.
That last clause does the work. The gap between an enterprise account and a personal one is contractual rather than functional, and employees do not intuit it. As of September 2026, consumer tiers of ChatGPT, Claude and Gemini may use your content for training, subject in Anthropic's case to a user setting and in Google's to activity history; the business and enterprise tiers of all three, plus the OpenAI API since March 2023, do not. Google's consumer guidance asks users not to "enter confidential information that you wouldn't want a reviewer to see or Google to use to improve our services," and human-reviewed Gemini conversations are retained for up to three years in a way that survives the user deleting them.
Three exceptions belong in your appendix because they surprise people. Both OpenAI and Anthropic carry a feedback trapdoor: even where training is off, submitting feedback on a conversation can put that whole conversation in scope. Anthropic's zero-retention option does not cover Claude for Work chat. And Microsoft 365 Copilot's web search queries fall outside the enterprise data protection terms, because Bing operates as a separate controller under consumer terms, so a BAA or an EU data boundary commitment does not reach them.
Put product names in an appendix that also records the underlying model, and review it quarterly. The policy body should survive a rename.
AI in employment decisions, where US exposure concentrates
If your reader is a US mid-market employer, this section matters more than everything the EU requires, and it is the one most templates compress into a bullet.
Four obligations are already fixed. New York City requires a bias audit before an automated employment decision tool is used, plus candidate notice ten business days in advance. Colorado's replacement statute, signed in May 2026, takes effect for covered duties on January 1, 2027 and requires point-of-interaction notice, a plain-language explanation of an adverse outcome within thirty days, human review on request, and records kept at least three years. California's ADMT regulations set a compliance date of January 1, 2027 and expressly treat hiring, work allocation, compensation, promotion, demotion, suspension and termination as significant decisions. And a separate California rule effective October 2025 requires anyone who supplies an automated decision system to an employer, or operates one on the employer's behalf, to retain the training set, the modelling, the assessment criteria and the outputs for four years following the last date that system was used. It applies to employers with five or more employees, which is a wider net than anything else here.
Then there is the part people misread as relief. The federal picture looks lighter than it did: the Equal Employment Opportunity Commission's 2023 Title VII and 2022 ADA guidance documents on AI both return a 404 today. Removed, though, is not the same as rescinded, and no rescission instrument exists. The executive order behind the change revokes only Title VI approvals, leaves Title VII and the Uniform Guidelines untouched, and states in its own text that it creates no enforceable rights. Private disparate-impact claims under Title VII are unaffected, and the Commission's amicus brief in Mobley v. Workday is still published on its site. Deprioritized federal enforcement is exposure redirected from the regulator to the plaintiffs' bar, not exposure reduced.
Two practical consequences for the document you are writing. Mobley reaches class certification on December 8, 2026, and its docket exhibits include the defendant's ISO 42001 audit certificate alongside bias-audit reports, which is a plain demonstration that your AI governance artifacts are discoverable. And a May 2026 ruling in that litigation, as reported by Norton Rose Fulbright, held that bias-testing data may attract attorney-client privilege where counsel meaningfully directed the work and results were not shared with regulators. The operational rule that follows is one no template gives you: run bias testing under counsel direction, or accept that it is discoverable.
Agents and autonomous actions
Policy writing has no standard to conform to here, and pretending otherwise would be dishonest.
Across the public policies reviewed for this piece, none contains language governing how an autonomous agent authenticates. The OWASP non-human identity list published in 2025 includes an entry for humans misusing machine identities; the inverse problem, machines running on human credentials, did not get its own entry until the agentic list in December 2025. NIST has no agent standard. The most practical control set available comes from the UK NCSC, and that guidance describes itself as interim.
It is still the best-evidenced starting position. Every agent should hold its own unique identity in a class distinguishable from human accounts, rather than borrowing an employee's login. Credentials should carry the shortest workable lifetime. NCSC's logging expectation is "chain of thought traces and transcripts from the AI agent" plus events from the surrounding environment; add tool-call records to that, because the tool call is what has an effect. Someone should be named as able to halt autonomous activity immediately, which NCSC phrases as being able to "pull the plug." Their organizing test is the one to put in the policy: "If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment."
Then add the tier no framework gives you, because none of them names an action class or a monetary limit. Define blast radius yourself, and here is a defensible default rather than homework: read-only access needs no approval; writing to a sandbox is logged but unrestricted; writing to production or anything customer-facing requires a human approving that specific action class in advance; financial commitment requires a human at execution time, every time. Set a value threshold on the last one and review it.
On accountability, USC's policy has the clearest published language: covered individuals "remain responsible for all actions taken by Agentic AI systems operating on their behalf." The authorization architecture underneath this is a longer subject, which we cover in our LLM security guide.
Coding assistants
Three decisions belong in a software development annex, and there are five real published positions to borrow from.
Gentoo bans AI-generated contributions. NetBSD treats such code as "presumed to be tainted code" that "must not be committed without prior written approval by core." QEMU declines patches on suspicion. Linux permits it but requires an Assisted-by: tag and is explicit that "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." curl is permissive and puts the burden on the submitting author. Pick one and say which.
On copyright, the US Copyright Office's January 2025 report is careful to scope itself: "Based on the functioning of current generally available technology, prompts do not alone provide sufficient control." So substantially AI-generated code is unlikely to be copyrightable, on today's tools. The half that gets omitted, from the DC Circuit in Thaler, where certiorari was denied in March 2026, is that "the human authorship requirement does not prohibit copyrighting work that was made by or with the assistance of artificial intelligence." Assistance is fine. Authorship by prompt is not.
One widely repeated instruction is now wrong. The advice that you must enable the public-code or duplicate-detection filter to keep GitHub Copilot's IP indemnity no longer holds: Microsoft's own documentation states that as of April 3, 2026 "there are no additional required mitigations" and that the duplicate detection filter "is no longer required for CCC coverage," CCC being the Customer Copyright Commitment under which Microsoft defends customers against IP claims over AI output.
The rule that does hold is about tiers again. Every vendor indemnity verifiable from published terms applies only to paid tiers under a commercial agreement, and several carve out modified output, which is what developers always produce. One ambiguity worth flagging rather than resolving: OpenAI's output indemnity runs to "Enterprise," a term its own agreement defines as Enterprise, Edu and Healthcare, while ChatGPT Business appears in the section heading but sits outside that definition. A developer on a personal or free assistant has no indemnity at all.
Shadow AI: what the evidence supports
The case against blanket bans is usually made with one statistic, and it deserves more care than it gets.
The KPMG and University of Melbourne study of 48,340 people across 47 countries found non-compliant AI use highest among employees who say their organization has banned generative AI, at 67%, against 56% where they say a policy exists and 33% where neither does. The authors hedge appropriately: this "suggests outright bans may be ineffective, and that simply having policies does not guarantee compliance." Two confounds are worth stating. Reverse causality is plausible, since organizations with a visible problem are likelier to ban. And there is an awareness effect: you can only report contravening a policy you know about, so part of that 33% is people unable to classify their own behavior. Fieldwork ran from November 2024 to mid-January 2025, with no later edition.
Behavioral data points the same way with fewer caveats. Netskope telemetry for the year to October 2025 shows the share of AI users on personal accounts falling from 78% to 47% while organization-managed accounts rose from 25% to 62%. People switching between the two grew from 4% to 9%, which Netskope attributes to approved tools not yet matching the convenience users want. In the same dataset, 90% of organizations block at least some AI applications, averaging ten. That population is Netskope's own customers, so it skews toward organizations that already have a sanctioned path.
So the evidence supports targeted blocking plus a working request path, not a blanket ban and not an empty blocklist. Two design details matter more than the policy language. Your exception process needs a decision deadline: across the competitor templates reviewed for this piece, seventeen of twenty-two mention exceptions and one attaches a service-level commitment to deciding. And your allowable-use lane should be wide enough that most people never need the exception queue. The US General Services Administration's four-tier use-case model is the most transferable version of this, opening with a lane for exploring and assessing AI tools "using only non-sensitive, public information and publicly available systems," then separating pre-approved low-stakes applications, research and development, and production. Most shadow AI is someone wanting to try something with no lane to try it in. Our shadow AI hub covers the discovery side.
One number to stop repeating: the $4.63 million shadow-AI breach figure does not appear in the IBM report it is attributed to. IBM's 2025 report puts it at $200,000 above the global average, or $670,000 comparing organizations with high shadow AI against those with little or none. The 2026 edition carries no shadow-AI figure at all.
Disclosure, and the one convention that is auditable
Three decisions get conflated here. Whether you tell the public, whether you tell your manager, and how the artifact itself is marked.
Seattle's policy has the only auditable convention I found: attribution must name the AI system and carry an assertion that a human reviewed it, naming the reviewing department. Source code is attributed "via comments in the source code and in product documentation." That turns disclosure from decorative into checkable, which is what makes it survive an audit.
For the lighter default, Fisher Phillips requires informing your supervisor when a tool was used and prohibits presenting AI-generated work as your own original work. Most organizations can start there and tighten later.
What the law actually requires
The closest thing to a written-policy mandate in the EU AI Act is Article 17, binding providers of high-risk systems from December 2027 for systems under Annex III and August 2028 for AI embedded in regulated products. It does not reach a company whose staff use ChatGPT. In the US, no federal or state law obliges a private employer to publish an internal AI policy.
Two AI Act provisions do reach you as a deployer, which is the Act's term for an organization using an AI system rather than building one. Providers build and place systems on the market; deployers use them. Most templates assign these duties to the wrong party.
Article 4, AI literacy, binds providers and deployers, and the Commission's FAQ extends it to contractors, service providers and clients. It has applied since February 2, 2025, with national authorities supervising and enforcing from August 2, 2026. The Digital Omnibus, in force since July 2026, rewrote what it asks: providers and deployers must now "take measures to support the development of AI literacy of their staff … taking into account their technical knowledge, experience, education and training," and the current text adds a sentence almost no commentary carries: "This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual." The superseded wording, still quoted nearly everywhere, said organizations must "ensure, to their best extent, a sufficient level of AI literacy." The Commission's FAQ also states that "there is no one size fit all when it comes to AI literacy and no strict requirements or mandatory trainings are imposed." Article 4 is not among the articles enumerated in the Act's headline penalty tier, but Member States are required to lay down their own penalty rules, and authorities can sanction Article 4 infringements from August 2026. So: record who was trained on what, scaled to role. Do not buy a certification programme.
Article 50, transparency, has applied to deployers since August 2, 2026 and does sit in the headline penalty tier. Two duties land on you. Disclose when content is a deepfake, meaning image, audio or video that has been artificially generated or manipulated. And disclose AI-generated text "published with the purpose of informing the public on matters of public interest." That second duty carries its own escape hatch, which is the most useful sentence in the Act for a policy author: it does not apply where "the AI-generated content has undergone a process of human review or editorial control and where a natural or legal person holds editorial responsibility for the publication of the content." A named human reviewer is the compliance route the statute itself supplies. On the penalty, the headline figure is €15 million or 3% of worldwide turnover, whichever is higher, but small and medium enterprises are capped at whichever is lower.
One retired document still circulating: the UK government's "Generative AI Framework for HMG" was withdrawn in February 2025. If your draft cites it, that citation is two years stale.
Where to start
Write the permission matrix first. It forces the tier definitions, it is what employees will actually consult, and filling it in exposes how little you know about which tools are in use, which is the real starting problem. Everything else is either scaffolding around that matrix or a control that presumes you have it.
Then settle the agent question before you need it. Most organizations will deploy something with write access to a production system within the next year, and this is much easier to decide in the abstract than with a team waiting on approval.
Then keep the tool appendix on a quarterly review, because that is where the churn is, and put a visible verification date on the document so readers know how current it is.
Enforcing the matrix is a different problem from writing it. Workforce AI Governance is our implementation: discovering which tools are actually in use, classifying what goes into them at the prompt level, and producing the evidence that the policy was applied. That said, the policy has to exist first, and the version that works is the one your own teams helped write, because they are the people who know which lane was missing.
Questions teams ask when writing this
Does any law actually require us to have an AI policy?
Not as a private employer. But one law lets a policy satisfy a duty: for promotion candidates under New York City's rule, the required notice may be delivered through a written policy or procedure rather than individually. Elsewhere the laws require notice, documented assessments, retention and in New York City an audit, all of which are far easier to evidence if a policy exists.
Should we ban AI tools outright?
The evidence argues against it. The largest survey found non-compliant use highest where employees say their organization bans it, though that is self-reported and cross-sectional. Network telemetry supports the same direction: approved tools displace personal accounts when they are good enough, and most organizations block a small targeted set rather than everything. A blocklist plus a working request path is the defensible position.
Do we need a separate policy for AI agents?
A section rather than a separate document, but it has to exist. The distinguishing questions are whether the agent holds its own identity rather than an employee's, what it may write to, and who can stop it. No published corporate policy covers this yet, so you will be writing ahead of the field rather than copying it.
How often should this be reviewed?
Quarterly for the tool appendix and the jurisdiction list, annually for the body. The appendix is where the churn is: four major products were renamed recently, and at least one vendor changed its consumer training default and retention period in the same period.
Legal and vendor terms in this article were verified against primary and named secondary sources on September 12, 2026. Vendor data-handling terms change frequently; check the current page before relying on any tier distinction described here.