What does an AI acceptable-use policy actually need to say?
Eight things: which tools are approved, what data may never go into them, who approves AI output before it reaches a customer or a production system, how AI use is disclosed, who owns the policy, how incidents are reported, what the training expectation is, and how the policy changes. One page for staff, an appendix for engineers. Anything longer will not be read.
- What AI users say about their own work
- What they say about their organization
- AI lets me spend more time on high-value work
- I fear falling behind if I do not use AI
- I am producing work I could not a year ago
- It feels safer to focus on current goals than redesign work
- Leadership is clearly and consistently aligned on AI
- I am rewarded for reinventing work with AI, even when results miss
Organizational factors explained more than twice the reported AI impact of individual ones (67% versus 32%). The bottleneck is rarely the tool.
Source: Microsoft, 2026 Work Trend Index: Agents, human agency, and the opportunity for every organization (2026). 20,000 full-time workers in 10 countries, 18 February to 7 April 2026, fielded by Edelman Data x Intelligence.
Data table
| Item | Group | Value |
|---|---|---|
| AI lets me spend more time on high-value work | What AI users say about their own work | 66% |
| I fear falling behind if I do not use AI | What AI users say about their own work | 65% |
| I am producing work I could not a year ago | What AI users say about their own work | 58% |
| It feels safer to focus on current goals than redesign work | What they say about their organization | 45% |
| Leadership is clearly and consistently aligned on AI | What they say about their organization | 26% |
| I am rewarded for reinventing work with AI, even when results miss | What they say about their organization | 13% |
What an AI acceptable-use policy must cover
Why most AI policies fail
They are written to protect the company from its employees, and employees can tell. Microsoft’s 2026 survey of 20,000 workers found that 65% of AI users fear falling behind if they do not use AI, while only 13% say they are rewarded for trying to reinvent their work with it. A policy that only says “do not” lands on people who are already using the tools, quietly, on their own accounts. The useful policy says what is allowed, clearly enough that people stop hiding it.
The second failure is length. A twelve-page document is a legal artifact, not a working rule. One page for everyone, with an engineering appendix, is the format that gets followed.
The eight sections
1. Approved tools. Name them. “ChatGPT Enterprise, Microsoft 365 Copilot, GitHub Copilot, and the internal knowledge assistant” is a policy. “Approved AI tools” is not. Include how to request a new one and who decides.
2. Data that never goes in. Customer personal data, credentials and keys, unreleased financials, anything under NDA, source code for named systems, and health or payment data. List the categories, then give the one-line test: if you would not paste it into a public web form, do not paste it into a model that is not on the approved list.
3. Approval before it reaches the outside world. AI can draft. A named person approves anything AI-produced that goes to a customer, into a contract, into production code, or into a regulator’s hands. Say who, by role.
4. Disclosure. When AI-generated material goes to a client or the public, whether and how that is disclosed. The answer varies by industry; the policy has to give one.
5. Ownership. One named role owns the policy and the tool list. Committees own nothing.
6. Incidents. What counts as one (data pasted where it should not have been, an AI-produced error that reached a customer, a tool used outside the list), where to report it, and the explicit statement that reporting is expected and not punished. Without that line nobody reports anything.
7. Training. What everyone completes, what engineers complete, and by when. Keep it short and specific to the tools on the list.
8. Change. How often the policy is reviewed, who can change it, and where the current version lives. Quarterly is right for 2026; the tools change faster than annual review can follow.
The engineering appendix
For software teams the one-pager is not enough, because the risks are different. The appendix covers what AI may generate without review (tests, documentation, scaffolding), what always gets human review (anything touching authentication, payments, data migration, infrastructure), what AI agents may execute on their own and what they may not, which repositories are in scope, and how AI-authored changes are marked in commits so they can be measured.
A template outline
1. Purpose, one paragraph
2. Approved tools, and how to request one
3. Data that must never be entered
4. Approval before external or production use
5. Disclosure
6. Owner
7. Incidents: what, where, no blame
8. Training expectations
9. Review cadence and version
Appendix A: engineering rules
Appendix B: tool-by-tool notesMapping to the frameworks
If a client or auditor asks, the eight sections map to the four functions of the NIST AI Risk Management Framework: Govern (owner, review, training), Map (approved tools, data categories), Measure (incident reporting, commit marking), and Manage (approval gates, disclosure). ISO/IEC 42001 asks for the same things as a management system, with documented evidence that the policy is followed. Writing the policy this way means the evidence already exists when the question arrives.
What we do not recommend
Blocking the tools at the network level as the whole policy. It fails on the first personal phone, and it tells the people who were going to use AI well that the organization would rather they did not. Govern the use; do not pretend it is not happening.
Sources
If this is your situation
The three-week assessment is where we work out which of these applies to you, in writing, before anyone builds anything. Talk to us.