The 40-page enterprise AI templates floating around are unworkable for a 200-person company. A six-page structure that maps to actual decisions employees make weekly: acceptable use, data classification, approved tools, human-in-the-loop triggers, incident reporting, model-card disclosure. Three clauses always get violated within 90 days.
Somewhere in your shared drive there is a 40-page AI usage policy. It came from a law firm, a bigger company, or the very tool it is meant to govern. Nobody has read it to the end, and the people who use AI every day could not tell you what it permits.
That is the state of play at most 200-person companies we meet. The box is ticked, and the actual behaviour is whatever each team worked out in its first weeks. The template assumes a legal department, a procurement function and a security team who can each own a chapter. At 200 people those are often the same person, who is also running payroll.
We think a usable policy is six pages, because six is the number of decisions an employee makes in a working week that the policy has to settle. Everything else is theatre: written to be shown to an auditor, never to be read by a marketer with a customer list open in one tab and a chatbot in the other.
Why do 40-page AI policies fail?
Because a policy is a set of answers to questions people have while working. The long templates answer what a regulator or a general counsel might ask: real questions, asked occasionally, by a single role. Employees ask different ones, constantly: can I paste this in, which tool do I use, do I have to check the output, who do I tell if it goes wrong. Bury those under the annual ones and people consult each other instead. The policy becomes folklore, and folklore cannot be enforced in a system.
The subtler failure is that the long template gets adopted because it looks defensible. A policy nobody follows is no defence under data protection law or the EU AI Act; it is evidence the organisation knew what good practice looked like and did not do it. Six pages that are followed protect you. Forty that are not do the opposite.
What are the six pages?
Each page maps to one decision. If a page cannot be summarised as 'when this happens, do that', it should be cut.
- Acceptable use. Decides what AI may be used for and what it may not, in terms of tasks rather than technologies. An internal memo is fine; anything about a named individual is not, whatever the tool.
- Data classification. Decides which categories of information may leave the company systems and which may never be pasted into anything, with employee and customer personal data in the top tier by default.
- Approved tools. Decides which products, on which accounts, with which settings, are permitted, and who can add one. A personal login on a free tier is a different tool from the same product on a company contract.
- Human-in-the-loop triggers. Decides which outputs a person must review before they leave the draft, the department or the building. The trigger is the type of output and who it affects, not how confident the model sounds.
- Incident reporting. Decides what counts as an incident (the wrong data pasted, an output acted on in error, a tool used off the list), who hears about it, and what happens to the reporter. If the answer to the last question is not 'nothing bad', nobody will report anything.
- Model-card disclosure. Decides where AI is doing work on behalf of people and who is told. Employees should know when a policy answer came from a model; customers should know when a first response was drafted by one.
Which three clauses get violated within 90 days, and why?
We have not seen a policy survive its first 90 days intact, and the breaches cluster in the same three places. That is not evidence the policy is wrong; it is evidence it asked for behaviour the tools made harder than the alternative.
- Data classification. Someone pastes a customer export or a candidate CV into a tool because the task needed it and the page said no without saying what to do instead. A prohibition without a permitted path is ignored under deadline.
- Approved tools. A new product launches, someone tries it on a personal email, and it is in daily use before anyone asks whether it is on the list. The list was correct the day it was written and stale within the month.
- Human-in-the-loop triggers. The first reviews are careful. A few weeks in, the reviewer has seen enough good outputs to approve on sight, and the review becomes a click. The trigger is still in the policy; it is no longer in the behaviour.
All three rely on an individual remembering a rule at the moment it is inconvenient. That is a design failure, not a character one. The fix is to move each clause into the system: a redaction step before any paste, a tool list that lives in your identity provider rather than a PDF, a review queue the send button cannot bypass.
A rule that lives only in a PDF is a rule you have decided not to enforce.
Where does a human have to be in the loop?
Less often than the 40-page templates say, and more reliably. We draw the line at consequence, not technology. Any output that affects a named person's employment, pay, performance record, health or legal position has a human decide, and the decision is recorded alongside what the human saw. A model can draft the letter; it does not decide who receives it.
Outside that line, the trigger should be about what leaves the company. A private draft needs no review. A first reply to a customer needs a look. A figure in a board pack needs a check against the source. We build HR policy answers on exactly this basis: the model answers a leave or expenses question from the handbook, cites the paragraph it used, and hands over to a person the moment the question turns on somebody's circumstances. One sentence in the policy; unavoidable in the system.
How do you keep the policy alive after month one?
The tools change faster than any document, and the practices that keep a policy alive are small. First, make the approved tools page a system of record: if the list lives in your identity provider or your HRIS, adding a tool is an admin action with an owner, and the policy is right by construction. Second, treat every breach of the three clauses above as a change request, not a disciplinary matter; it shows where the policy asked for something unrealistic. Third, review the six decisions on a fixed cadence with the people who make them daily, not the committee that approved them. The first review usually shortens the document.
What to do next
If you have a 40-page template and no behaviour, write the six pages from the decisions your teams are already making informally. If you have the six pages and still see the three clauses breached, the policy has done its job and the next step is engineering: turning each clause into a control inside the HRIS, the identity provider and the tools people already use, so the compliant path is the easy one.
That is the work we do. It starts with a 20 or 45-minute discovery call and, where the scope needs defining, a four-day Spec from €5,000 that turns your policy into a written brief you own outright. The build that follows ships in an average of eight weeks and puts the redaction step, the tool register, the review queue and the incident route into production on the systems you already run. The policy stays six pages. The controls do the rest.