AI policy template: a free starting point for your company
A practical structure for a company AI usage policy, covering approved tools, data handling rules and enforcement — not just a document nobody reads.
by Elias Mahdavi · Published on · 8 min read
An AI policy template gives a company a starting structure for its AI usage rules: which tools are approved, how data is classified, and how the policy is enforced. A document listing only good intentions is not a policy; UK GDPR and the EU AI Act (Regulation (EU) 2024/1689) both expect rules that are actually followed.
Key takeaways
- An AI policy template should cover approved tools, data classification rules, prohibited uses, ownership, review cadence and enforcement, not just a values statement.
- A policy nobody can point to a specific rule in is not enforceable, and offers no real protection if something goes wrong.
- The template below is structured as eight adaptable sections, ready to fill in with your organisation's specific tools and thresholds.
- Enforcement works best when backed by technical controls, such as governed access to approved models, not the document alone.
- A policy needs a named owner and a fixed review cadence, tied to legal or compliance sign-off on the data classification and enforcement sections specifically.
Contents
What should an AI use policy include?
An AI use policy should state, in specific and checkable terms, which AI tools employees may use, what data can and cannot go into them, who owns the policy, and what happens when it is breached. Anything vaguer than that is a values statement, not a policy.
The most common failure is a policy written entirely in principle: "employees should use AI responsibly." That sentence cannot be enforced, audited, or even understood consistently by two different employees. The Information Commissioner's Office is direct about this in its <a href="https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/" target="_blank" rel="noopener">guidance on AI and data protection</a>: accountability means being able to show what a system actually does, not what a document says it should do. A usable policy names real tools, real data categories and a real consequence, which is exactly what the template below is structured to do.
Free AI policy template
Copy the eight sections below and adapt the bracketed detail to your organisation. Each section is written the way it should appear in the finished document, not as abstract advice about what a policy needs.
1. Purpose and scope
State what the policy governs and who it applies to. "This policy governs the use of artificial intelligence tools by all employees, contractors and external consultants of [Company name] in the course of their work, including AI features embedded in existing software."
2. Approved AI tools and models
List the specific tools and model providers employees are permitted to use, and state clearly that anything not on the list requires approval before use. "Approved tools: [list]. Any AI tool not listed here requires review and sign-off from [role] before use on company data." This is the section that most directly prevents shadow AI, and it needs a fast review process attached, not just a static list.
3. Data classification and handling rules
Define your data categories and state, category by category, what is and isn't permitted to be entered into an AI tool. "Public data may be used freely. Internal data may only be used with [approved tier/tool]. Confidential and regulated data may never be entered into any AI tool without [specific control, e.g. masking or an on-premise model]."
4. Prohibited uses
List specific actions that are banned outright, not general categories. "Employees may not: enter customer personal data into a consumer-tier AI account; use AI output as the sole basis for a hiring, credit or disciplinary decision without human review; connect an AI tool to company systems without IT approval."
5. Roles and ownership
Name who owns the policy and who employees escalate questions to. "This policy is owned by [role/name]. Questions about whether a specific use is permitted should be directed to [role/team] before proceeding, not after."
6. Review and update cadence
State a fixed schedule, not "as needed." "This policy is reviewed every [quarter/six months] and updated whenever the approved tool list changes. The current version is dated and superseded versions are archived."
7. Enforcement and consequences
State what happens when the policy is breached, proportionate to severity. "Breaches are handled under [existing disciplinary process]. Repeated or severe breaches, including entering regulated data into an unapproved tool, may result in [specific consequence]." A policy with no stated consequence is read as optional.
8. Employee acknowledgement
Require a dated, recorded acknowledgement, not an assumption that people read the intranet. "All employees confirm they have read and understood this policy on [onboarding/annual cycle], recorded in [system]." This record is what demonstrates the policy was actually communicated if it is ever tested.
Common mistakes that make an AI policy unenforceable
Most AI policies fail for a small, repeatable set of reasons rather than one dramatic gap. The table below pairs each common mistake with the fix.
| Mistake | Why it fails | Fix |
|---|---|---|
| Written entirely in principle ("use AI responsibly") | Nothing specific to check compliance against | Name actual tools, data categories and consequences |
| No named owner | Nobody is accountable for updates or enforcement | Assign a specific role, not "IT" in general |
| No fast-track for new tool requests | Employees route around a policy that can't keep up | Build a review process that can approve a low-risk tool in days |
| Policy exists only as a document | No technical control checks whether it's followed | Pair the policy with governed access so approved tools are the easy path |
| No review cadence | Rules go stale the moment a new model or tool appears | Fix a review date and tie it to the tool list, not a calendar guess |
| No enforcement consequence stated | Read as optional by employees | State a specific, proportionate consequence for breach |
How to roll out and enforce the policy
A policy earns credibility once employees notice the approved path is genuinely usable, not merely permitted on paper. Publish the document with the tool list visible, require the section-eight acknowledgement at onboarding and on a fixed cycle, and give people a named contact for a fast answer when a tool isn't yet listed.
Enforcement holds up best when it does not depend entirely on employees remembering the rules. Technical controls, such as routing all model access through one governed gateway and restricting network egress to an approved allow-list, mean the policy is backed by what the system actually permits, not only by what the document says. This matches the UK government's <a href="https://www.gov.uk/government/publications/ai-cyber-security-code-of-practice" target="_blank" rel="noopener">AI Cyber Security Code of Practice</a>, developed with the National Cyber Security Centre, which frames security as a baseline responsibility of the organisation deploying an AI system, not an optional extra left to individual judgement. The operational structure that keeps a policy enforced day to day, including approval flows and escalation paths, is covered in <a href="/en/blog/ai-governance-framework-guide">how to build an AI governance framework that holds</a>.
Who should own the policy, and how often should it be reviewed?
The policy needs one named owner, typically a head of IT, security or compliance rather than a shared inbox, with a review cadence tied to events, not a calendar date: every time the approved tool list changes, the policy should be reviewed alongside it. A policy left untouched for a year, in a market where model providers change monthly, reads as neglect if it is ever produced during an audit.
Ownership without enforcement authority is largely symbolic. The owner needs standing to approve or reject a new tool request within days, because a policy that cannot keep pace with what employees want to use is the exact condition that produces <a href="/en/blog/what-is-shadow-ai">shadow AI in the first place</a>.
Frequently asked questions
What should an AI use policy include?
An AI use policy should state which tools are approved, what data can and cannot be entered into them, who owns the policy, a review cadence, and the consequences of a breach. Vague language about "responsible use" is not enforceable on its own.
Who should own a company AI policy?
A named individual, typically in IT, security or compliance, rather than a team inbox or a shared responsibility with no single accountable person. That owner needs the authority to approve new tools quickly, or employees will route around a policy that cannot keep pace.
How often should an AI policy be reviewed?
At a fixed cadence, commonly every quarter or six months, and additionally whenever the list of approved AI tools changes. A policy tied only to a generic annual review date will lag behind how quickly new models and tools become available.
Does an AI policy need legal sign-off before launch?
The data classification and enforcement sections benefit most from legal or compliance review, since those are the parts a regulator or auditor is most likely to test. The rest of the document can usually be drafted operationally and reviewed by legal rather than authored by legal from scratch.
What happens if an employee breaches the AI policy?
That depends entirely on what the policy itself states, which is why section seven of the template above exists: a specific, proportionate consequence tied to severity. A policy silent on consequences is read by employees as optional, regardless of its other content.
Is a written AI policy legally required under the EU AI Act?
The <a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj" target="_blank" rel="noopener">EU AI Act (Regulation (EU) 2024/1689)</a> does not mandate a single-document "AI policy" by that name, but its risk-based obligations on providers and deployers of AI systems are far easier to demonstrate compliance with when an organisation can point to a documented, enforced policy covering exactly what tools are used, on what data, and by whom.
Turning this template into an enforced policy
A template solves the drafting problem. The harder, more valuable problem is enforcement: making sure the tools people actually use match the tools the policy names, without relying on memory or goodwill. That distinction is explored fully in <a href="/en/blog/what-is-ai-governance">what AI governance means and how it works in practice</a>, which sets out the difference between a policy that exists and a policy that holds.
To see how DevKira pairs a policy like this one with governed model access, so the approved tools in section two are also the only ones technically reachable, <a href="/en/book-a-demo">book a DevKira demo</a>.
