Writing a company AI policy that actually governs agents
A practical template for an internal AI policy — the sections that matter, how to cover autonomous agents and Shadow AI, and how to keep it from becoming shelfware.
Definition
A company AI policy is an internal document that defines how an organization may build, buy and use AI — including approved tools, data handling, human oversight, and accountability. For agents it must address autonomy levels, tool access and the reality of Shadow AI.
A company AI policy is easy to write badly: a long document nobody reads, full of prohibitions that push people toward Shadow AI. A good one is short, specific, and makes the safe path the easy path. Here is the template that works.
Which sections actually matter?
Keep it lean enough to be read, complete enough to govern:
- Scope and definitions. What counts as AI here, who the policy applies to, and key terms — link a glossary rather than redefining everything.
- Approved tools and approval process. A named list plus a fast, clear route to get something new approved. Vagueness here is what creates Shadow AI.
- Data handling. What data may go into which tools, what must never leave the organization, and how personal data is treated under the GDPR.
- Human oversight by risk level. When human-in-the-loop is required, when supervision suffices, and what is never fully automated.
- Accountability. Who owns each AI system and who answers for its actions.
- Incident response. What to do when an agent misbehaves — including the kill switch.
Cover agents explicitly
Generic AI policies miss what makes agents different: they act. Add rules for autonomy levels (which actions an agent may take without approval), tool access (least privilege, no standing admin), and memory and data retention. A policy that only governs “using ChatGPT” does not govern an agent wired into your systems.
A useful way to make autonomy levels concrete:
| Autonomy level | What the agent may do | Human role |
|---|---|---|
| Suggest | Draft and recommend actions | Human executes everything |
| Act with approval | Prepare and queue an action | Human approves each one |
| Act within limits | Execute inside defined bounds | Human monitors, can intervene |
| Fully autonomous | Decide and execute | Human reviews after the fact |
Make Shadow AI the easy thing to avoid
Shadow AI — staff using unsanctioned tools — grows wherever the official answer is “no” without an alternative. The policy’s job is to provide the sanctioned path: approved tools, clear data rules, and a fast approval route. When compliance is easier than working around it, most people comply.
Keep it from becoming shelfware
A policy is intent; it governs nothing on its own. Three habits keep it alive:
- Map every rule to a control. “Least privilege” in the policy means scoped credentials in practice — see excessive agency.
- Review on a schedule. Models, tools and regulations move; an annual-at-minimum review keeps the policy current.
- Anchor it to a management system like ISO 42001, so the policy is part of an audited loop, not a one-off file.
Written this way, an AI policy is not paperwork — it is the human-readable layer over the technical controls that actually run your agents safely. Terms are in the glossary.
Frequently asked questions
What sections does an AI policy need?
At a minimum, six: scope and definitions, approved tools with an approval process, data-handling rules, human-oversight requirements by risk level, accountability and ownership, and incident response. For agents specifically, add two more — autonomy levels that say which actions an agent may take without approval, and tool-access rules that enforce least privilege. The hardest constraint is length: a policy long enough to feel thorough is usually too long to be read, and an unread policy governs nothing. Aim for something a new employee can absorb in one sitting, push detailed procedures into linked references, and resist the urge to legislate every edge case in the main document. The test of a good policy is not completeness on paper but whether the people it applies to can recall what it asks of them. Short, specific and actually read beats comprehensive and ignored every time.
How does a policy address Shadow AI?
By giving people a sanctioned path that is easier than the workaround, because Shadow AI thrives wherever the official answer is no without an alternative. When staff cannot get an approved tool quickly, they reach for whatever they found and paste sensitive data into it, which is the exact outcome the policy exists to prevent. A good policy therefore names approved tools, explains the data rules behind them in plain language, and provides a fast, visible route to get something new approved. The framing matters: a wall of prohibitions reads as an obstacle to route around, while a clear menu of allowed options plus an easy request process reads as help. You will not eliminate Shadow AI by banning it; you reduce it by making the compliant route the path of least resistance. Pair that with light monitoring so you can see what unsanctioned tools are in use and bring the popular, safe ones into the approved set.
Is a policy enough for compliance?
No — a policy is necessary but not sufficient, because it states intent while controls are what enforce it. A document that says least privilege governs nothing until scoped credentials exist in practice; a clause requiring human oversight is empty until an approval gate actually blocks the action. The reliable pattern is to map every rule in the policy to a concrete technical control and to a way of verifying that control is working: least privilege to scoped tokens, oversight to approval workflows, accountability to per-identity audit logs. Then anchor the whole thing to a management system such as ISO 42001 so the policy is part of an audited, reviewed loop rather than a file that ages quietly on a shared drive. Compliance lives in the gap between what the policy says and what the system actually does, and closing that gap — words mapped to enforced behaviour, reviewed on a schedule — is the real work. The policy is the human-readable layer, not the enforcement.
How is an AI policy different from a management system like ISO 42001?
An AI policy is a document that states what is allowed and required; a management system like ISO 42001 is the operating machinery that makes the policy real and keeps it honest over time. The policy is one artefact the system produces, alongside defined roles, risk treatment, internal audits and a continual-improvement loop. The distinction matters because a policy on its own is static: it captures intent at a point in time and then drifts as models, tools and regulations change, whereas a management system schedules review, assigns ownership, tests controls and corrects course. Think of the policy as the human-readable rules and the AIMS as the governance that enforces, audits and updates them. You can have a policy without a management system — many organisations do, and it slowly becomes shelfware — but you cannot have a credible management system without a policy inside it. For anything beyond a small team, anchoring the policy to a system is what stops it from quietly going out of date.