An AI usage policy exists to answer, in advance, the question an employee asks in front of the screen: can I paste this in? Any policy that does not answer that question operationally — with examples of data and of tools — is read once and forgotten.
The template below has ten sections. Each one has suggested wording you can copy and adapt, plus a note explaining why the clause exists and what it solves. Adapt it to your sector and have legal validate it before publishing.
Before writing a single line: you need to know what is already in use. A policy written over an un-inventoried environment describes the company you imagine having. If you have not done the survey yet, start with detecting Shadow AI and come back.
1. Purpose and scope
This policy establishes the rules for using artificial-intelligence tools in the course of professional activities at [COMPANY]. It applies to all employees, interns, contractors and service providers with access to company information, on any device — corporate or personal — when used for work purposes.
Why it reads this way: the extension to personal devices is the most forgotten clause and the one that matters most. Without it, the policy only covers where the company already had control, and all the usage that migrated to the phone falls outside scope — which is exactly where usage migrates once you block the desktop.
2. Definitions
AI tool: any service, application, extension or feature that uses artificial-intelligence models to generate, transform, classify or analyse content. This includes AI features embedded in already-approved tools.
Why it reads this way: the last sentence closes the most common gap. When an already-approved vendor turns on an AI feature in an update — meeting transcription, email summaries, autocomplete — without this definition the policy does not reach the new processing, and nobody reassesses anything.
3. Roles and responsibilities
Information Technology is responsible for maintaining the inventory of AI tools in use and for operating the detection controls. Privacy / the Data Protection Officer is responsible for assessing the legal basis and for the record of processing activities. Each area manager is responsible for knowing the tools used by their team. Every employee is responsible for observing this policy.
Why it reads this way:the manager’s line is what makes the policy work. If responsibility stops at “IT monitors” and “employees comply”, nobody with business context is judging whether a given use is appropriate. The manager is the one who knows whether that data was allowed to leave the area.
4. Tool classification
AI tools are classified into three categories: ALLOWED, freely usable within the data rules of this policy; RESTRICTED, whose use requires prior authorisation from the manager and from Privacy; and PROHIBITED, whose use is forbidden. The current list is published at [LOCATION] and reviewed monthly.
Why it reads this way: three categories, not two. A binary list forces every new tool to be prohibited by default until someone reviews it — which in practice means people use it anyway. The restricted category creates a legitimate, traceable path for the middle case.
The list should not live inside the policy PDF, but somewhere updatable. A policy is revised every six months; the tool list changes every week. Our public catalog classified by risk can serve as the starting point for that list.
5. Data rules — the section that matters
It is prohibited to enter, into any AI tool not expressly approved for the purpose: personal data of customers, employees or third parties; sensitive personal data; credentials, keys or secrets; proprietary source code; information under a confidentiality agreement; non-public contractual documents; and undisclosed financial information. When in doubt about how a piece of information is classified, consult your manager before entering it.
Why it reads this way:this is the only section employees will actually consult, so it has to be a list of concrete things, not a principle. “Do not enter confidential information” helps nobody decide: almost nobody correctly classifies what is on their screen as confidential in the moment, in a hurry.
A useful test while drafting: take the five most common AI uses in your company and check whether the section answers “allowed or not” for each one without requiring interpretation. If it requires interpretation, the wording is still too abstract.
6. Human review and attribution
All content produced with AI assistance must be reviewed by a responsible person before external use, publication or incorporation into a business decision. AI-generated content may not be the sole basis for a decision producing legal effects or a significant impact on people, including recruitment, performance evaluation, credit decisions and support prioritisation.
Why it reads this way: the second sentence is Brazil’s LGPD article 20 — the right to review of automated decisions — translated into operational language. It also anticipates the core of the EU AI Act and of ISO/IEC 42001, both of which turn on human oversight proportional to impact. Writing it now avoids rewriting the policy when a large customer makes it a contractual requirement.
7. Requesting new tools
Requests to use an AI tool not yet classified must be submitted through [CHANNEL], stating the purpose, the type of data involved and the requesting area. The assessment will be answered within [N] business days and will consider data risk, processing jurisdiction, the policy on training with customer data, and the existence of an adequate contract.
Why it reads this way: the deadline is what determines whether the clause works. A process with no deadline is indistinguishable from a ban, and people route around bans. If the answer takes three weeks, the tool is already in use by the time it arrives.
8. Monitoring and employee privacy
The company operates mechanisms to detect the use of AI tools on corporate assets, for the purpose of maintaining the inventory required by its governance and compliance policy. Monitoring records which tool was accessed, when, and on which workstation. The company does not collect the content of conversations, commands, prompts or files sent to the tools.
Why it reads this way: stating the limit of monitoring is not a courtesy, it is what makes the programme accepted. Announcing detection without saying what is not collected generates internal resistance, back-channel communication and, frequently, migration of usage to personal devices — the opposite of the goal. Transparency about the processing of the employee’s own data is also a requirement of LGPD article 9.
9. Non-compliance
Non-compliance with this policy subjects the employee to the disciplinary measures set out in [INTERNAL RULES], proportionate to severity and recurrence. Identified situations will first be addressed through guidance and correction, with more severe measures reserved for cases of intent, recurrence or actual harm.
Why it reads this way: the second sentence exists for practical, not humanitarian, reasons. A policy whose first step is punishment turns every detection into a conflict, and the immediate side effect is that managers stop reporting. The goal of the first year of such a programme is the map, not the disciplinary process.
10. Effective date and review
This policy takes effect on [DATE] and will be reviewed every six months, or whenever there is a regulatory change, a material incident or a significant change in the set of tools in use. Version [X.Y], approved by [OWNER].
Why it reads this way:the version and date are what allow you to prove, months later, which rule applied when something happened. Without versioning, an employee’s acknowledgement record proves nothing — they agreed to “the policy”, and there is no way to know which text that was.
After publishing
The document is the easy part. What turns a policy into demonstrable compliance is the cycle around it:
| Step | What to do | Evidence produced |
|---|---|---|
| Communicate | Publish and announce to everyone, highlighting the data section. | Delivery and read records. |
| Collect acknowledgement | Electronic acknowledgement with date and text version. | List of who signed and who is pending. |
| Train | A short session with real examples from the company's day-to-day. | Attendance record. |
| Monitor | Continuous detection of what is in use. | An up-to-date inventory. |
| Remediate | A prohibited tool detected becomes a task with an owner and a deadline. | History of actions taken. |
| Review | Six-month cycle, or event-driven. | Version history. |
It is the right-hand column that an audit asks for. The published policy answers “do you have a rule?”; the evidence answers “is the rule followed?” — and the second question is the one that fails you.
Five recurring mistakes
- Banning everything. Creates a contradiction between document and practice, and the document is what the auditor reads.
- Listing tools inside the PDF. The list goes stale before the policy does. Reference an updatable location instead.
- Writing “do not enter confidential information” and stopping there. Without a concrete list, each person classifies on their own, in a hurry.
- Not saying what monitoring does not collect. Generates resistance and pushes usage out of reach.
- Publishing without collecting acknowledgement. With no record of who read it, the company has a file, not a policy in force.
Frequently asked questions
What should an AI usage policy contain?
At minimum: purpose and scope, definitions, roles and responsibilities, classification of tools as allowed, restricted or prohibited, rules on what kind of data may be entered, rules on human review and attribution of generated content, a process for requesting a new tool, monitoring and privacy, consequences of non-compliance, and a review cycle.
Does an AI usage policy need to be signed by employees?
A signature is not required by law, but it is the evidence that closes the loop. Without a record of who read and agreed, the company has a published document and no proof of communication — which is exactly what auditors and frameworks such as ISO/IEC 42001 ask for. An electronic acknowledgement with a date and a version number solves it.
Should the policy prohibit AI use?
It should not. A prohibitive policy in a company where people use AI creates a contradiction between the document and the practice — and the document is what the auditor reads. It is more defensible to classify tools by risk, define what kind of data may go into each category, and monitor compliance.
How often should an AI usage policy be reviewed?
Every six months at minimum, and whenever something material changes: a newly widespread tool, a change in the terms of a vendor in use, an incident, or a regulatory change. The annual cycle inherited from traditional security policies is too slow for how fast the AI market moves.