Searching for AI policy examples mostly returns articles describing what a policy should contain, written by companies that would like to sell you help writing one. Very few show you what published policies actually say, and none that I could find had read a body of them systematically.
So I did. Twenty-four publicly readable AI policies and templates, fetched in full and coded clause by clause: security vendors, MSP blogs, HR software, a law firm, universities, and eight government bodies from a federal agency down to two city councils. Fourteen further candidates were excluded because they were form-gated, blocked, or turned out to describe a policy without containing one.
Here is what the set actually looks like, and what to take from each category.
The five kinds of policy you will find
Security and MSP vendor templates. The most numerous category in search results and the most repetitive. Several share a near-identical skeleton of prohibited tools, approved list, and request an exception, to the point where they appear to be circulating rather than being independently drafted. Typically short, competently written, and structured to demonstrate the vendor's expertise rather than to be adopted as they stand. Useful for the approved-tools structure and little else.
HR software templates. Longer, better written, and focused on conduct rather than data. Strong on disclosure and attribution obligations, notably weaker on the technical question of which data may reach which service. Worth borrowing the tone, which is more human than the security templates, and supplementing the data rules.
Law firm and audit firm publications. The most thorough on obligations and the most cautious. They tend to enumerate regulatory exposure comprehensively and stop short of telling you what to actually permit, which is understandable and limits their usefulness as a starting document.
Government policies. The most complete on two specific clauses. Seven of the eight in the corpus state an explicit default for tools not on the approved list, and disclose what is monitored. Those are the two clauses most private-sector documents omit, and government scores well on them almost certainly because a mandate requires it rather than because the drafters had better instincts. Strip the government documents out and the explicit-default figure drops from 67% to around 56%. They are also long, procedural, and written for organisations with a compliance function.
Actual company policies. Almost nonexistent as published documents. Of twenty-four, exactly one was a genuine primary-source policy from an operating private company. Several large firms are widely reported to have AI policies and almost none publish the text. If you feel you are writing yours without much prior art to look at, that is because you are.
What almost all of them get wrong
The pattern is consistent enough to be the headline finding. These documents are one-directional. They are lists of obligations flowing towards the employee, and they commit to almost nothing in return.
Fifty-four percent explain how to request a new tool. Eight percent say how long you will wait for an answer. Seventeen percent name a person with contact details, so most tell staff to ask when unsure without saying who to ask. Seventeen percent include a signature block, so most are not even acknowledged. Seventeen percent make any commitment back to the employee at all.
A second finding worth having: thirty-three percent sort rules by data sensitivity and thirty-three percent provide a concrete list of approved tools, and not one document did both. Organisations pick a governance axis and leave the other empty, which means every policy in the corpus answers either "is this tool allowed" or "is this data allowed" but never both. Those are different questions and staff hit both.
They are also not short. The median is around 1,550 words and the longest runs to 3,500, so the problem is not effort. It is that the effort goes into prohibitions rather than into the parts that make a policy usable.
Two cautions if you go looking yourself
The most complete documents in the corpus are not real policies. The two that scored highest against the clause checklist are governance-framework demonstrations published on GitHub by individual practitioners, using invented company names. They are good work and they are portfolio pieces. Do not read them as evidence of what companies do.
A lot of what ranks is not a policy. Fourteen of the thirty-eight documents I looked at could not be coded, because they were behind a form, returned a 403, or described a policy at length without containing one. Budget for that ratio if you go hunting.
What to take from all this
Borrow the approved-tools table from the vendor templates, the tone from the HR ones, and the explicit default and monitoring disclosure from the government ones. Then add the four things nearly nobody includes: a named owner with contact details, a committed response time on tool requests, a statement of what you will not monitor, and a signature block.
That combination does not exist in any of the twenty-four. It is written out in full here: the AI acceptable use policy template, with the decisions behind it if you would rather derive your own from your situation.
FAQ
They are surprisingly scarce. In an analysis of 24 publicly readable AI policies and templates, exactly one was a genuine primary-source policy published by an operating private company. The rest were vendor templates, HR software templates, law firm publications, university policies and government documents. Several large companies are widely reported to have AI policies without publishing the text, so anyone writing one is working with limited prior art.
They are one-directional. Across 24 documents, 54% explained how to request a tool but only 8% committed to a response time, 17% named a person with contact details, 17% included a signature block, and 17% made any commitment back to the employee. They are not short, with a median around 1,550 words, so the shortfall is not effort. The effort goes into prohibitions rather than into what makes a policy usable.
Both, and almost nobody does. In the 24-document corpus, 33% sorted rules by data sensitivity and 33% listed approved tools, but not one did both. Each answers a different question staff actually hit: whether a specific tool is permitted, and whether a specific piece of information may leave the organisation. A policy carrying only one axis leaves the other unanswered.
Partly. Government documents scored best in the corpus on two clauses most private-sector policies omit: seven of eight stated an explicit default for tools not on the approved list and disclosed what is monitored. Those are worth copying. They are almost certainly strong there because a mandate requires it rather than through better drafting instincts, and the documents are otherwise long, procedural, and written for organisations that have a compliance function.