A usable AI acceptable use policy defines scope and terms, lists approved tools, sets data rules, requires human review of consequential output, says how to report problems, and explains how to request an exception. Keep it short enough that people read it, and link out for detail.
Start from the Playbook's policy list
NIST's Playbook, under GOVERN 1.2, lists what organizational AI risk policies should cover. Several items translate directly into an acceptable use policy: define key AI terms and scope, connect to existing governance and data controls, set testing and validation expectations, set monitoring frequency, outline change management, provide a way to report serious concerns, specify and trial incident response, and cover both deployed and third-party systems.
Section outline
1. Purpose and scope. Who the policy applies to (employees, contractors) and which tools it covers, including embedded features and personal accounts used for work.
2. Definitions. What you mean by AI system, generative AI, agent and sensitive data. Short and plain.
3. Approved tools and how to get a new one approved. Point to the inventory. Name the approval path and a target turnaround so people do not route around it.
4. Data rules. What may never be entered (credentials, regulated personal data, customer confidential material unless the tool is approved for it). Tie to your data classification levels.
5. Human review. Output used in customer communication, code merged to production, legal or financial decisions, or anything affecting individuals needs a named person to check it. NIST's profile treats over-reliance and automation bias as risks to plan for.
6. Intellectual property and attribution. Who owns output, and when to disclose AI assistance.
7. Reporting. One channel for incidents, near misses and concerns. Make clear that good faith reports are welcome.
8. Exceptions. A form, an approver, an expiry date.
9. Consequences and review. How violations are handled and when the policy is reviewed.
Writing tips
Use examples of allowed and not allowed behavior. A table of "yes, ask first, no" for common tasks works well. Avoid listing product names, since they change faster than the policy.
Roll out
Train on the policy, publish it where people work, and collect acknowledgments. Review after the first quarter based on exception requests: a flood of requests for the same tool means it should be evaluated.
Where Safeguard fits
Safeguard offers policies, gates and guardrails, and an MCP Guardrail for agent tool access, which can help enforce parts of a policy such as which tools an agent may call. A written policy still needs owners and training.
Quick check
Should we ban generative AI until the policy is ready?
That is a business decision. A ban without an approved alternative often pushes use to personal accounts, which removes visibility. A short interim policy with an approved tool is usually safer.
How long should the policy be?
Two to four pages for the policy itself, with procedures and standards linked separately.
Sources
- NIST, AI Risk Management Framework 1.0 (NIST AI 100-1)
- NIST, Playbook: Govern
- NIST, Generative AI Profile (NIST AI 600-1)
Last reviewed: 19 October 2026.
