Template
Company AI policy template
A short AI use policy your employees will actually read, with the reasoning behind each clause so you can adapt it rather than copy it blindly. Written for companies where people already use AI and the policy has to describe reality, not forbid it.
By Botnea editorial team · Updated
What makes an AI policy work
Policies that get followed tend to share four traits:
- One page. If it needs a summary, it is already too long.
- Written as decisions, not principles — 'do not paste client contracts' beats 'use AI responsibly'.
- Backed by configuration wherever possible, so the easy path is also the allowed path.
- Owned by a named person, with a review date on the document itself.
The template below is deliberately permissive about using AI and strict about the two things that cause real damage: sending the wrong information out, and sending unchecked output out. Everything else is guidance.
The template
Copy the text below into your own document and replace the bracketed parts. Each clause is followed by a note explaining the intent so you can adjust it with your legal advisor.
- Purpose and scope. "This policy covers use of AI assistants for [Company] work by all employees and contractors. It applies to any tool that sends company information to an AI model, on any device." — Intent: close the personal-device gap explicitly, because that is where unmanaged use lives.
- Approved tools. "Company work must be done in [approved workspace or tool]. Personal AI accounts must not be used for company work. Requests to add a tool go to [owner] and are answered within [5] working days." — Intent: pair the restriction with a fast, real route to say yes, or the restriction will be ignored.
- Information you must not send. "Do not send: customer or employee personal data, credentials or keys, signed contracts, unreleased financial information, or anything a customer has asked us to keep confidential." — Intent: a specific list beats 'confidential information', which every person interprets differently.
- Information you may send. "Internal process documents, drafts, published material, and anonymised examples may be used unless a customer contract says otherwise." — Intent: state the permitted side explicitly, otherwise people assume everything is forbidden and go around the policy.
- Checking output. "You are responsible for anything you send out. AI output that leaves the company — to customers, publicly, or as a formal internal decision — must be reviewed by a person first, including any facts, figures, names and quotations." — Intent: locate accountability with the sender, not the tool.
- Disclosure. "[Describe when AI assistance must be disclosed, for example in client deliverables or recruitment.] If a customer contract restricts AI use, that contract wins." — Intent: contracts routinely override internal policy; say so once, here.
- Visibility. "Usage in the approved workspace is recorded by workspace, member and model, and reviewed [quarterly] to decide on access and budget. Conversations are not read for performance management." — Intent: describe both what is recorded and what it is not used for; the second half is what earns trust.
- Leaving the company. "Workspace access is removed on your last working day by [owner]." — Intent: make offboarding a step someone performs, not an assumption.
- Ownership and review. "This policy is owned by [name, role]. Next review: [date]. Questions and exceptions go to [channel]." — Intent: an unowned policy is a document, not a control.
Rolling it out without killing adoption
- Decide before you announce. Have the approved tool ready on the day the policy lands, so the first reaction is not 'what am I supposed to use instead?'.
- Send the one page, not a deck. Ask for a reply acknowledging it. Keep the replies; that is your record.
- Answer the first requests fast. The first two or three tool requests set the reputation of the whole process.
- Review on the date you wrote down. A quarterly review with the usage record in front of you takes under an hour.
Common mistakes
- Forbidding AI entirely while everyone continues using it privately — this removes visibility rather than risk.
- Listing forbidden data as 'confidential information' without examples.
- Requiring approval for every use, which produces either a bottleneck or quiet non-compliance.
- Promising monitoring you cannot actually perform, which destroys trust the first time it is tested.
- Publishing without an owner or a review date.
What this page does not claim
- This template is operational guidance, not legal advice, and it is not tailored to any jurisdiction, sector or contract. Have a lawyer review your final policy.
- It does not claim compliance with any regulation, standard or certification scheme.
- The visibility clause describes what Botnea records — activity by workspace, member and model. If you use a different tool, rewrite that clause to match what it truthfully provides.
See the security and data handling page for what Botnea does and does not attest to.
Questions buyers ask
- How long should a company AI policy be?
- One page. Anything longer gets skimmed, and the clauses that matter — the forbidden data list and the review requirement — are the ones that get skipped.
- Do we need a separate policy per team?
- Usually no. One company policy plus team-level workspace instructions covers most cases: the policy sets the boundary, the workspace configuration handles how each team works.
- Should the policy name specific AI models?
- Name the approved workspace or tool, not individual models. Model lists change far more often than policies get rewritten.
- What if a customer contract forbids AI use?
- The contract wins, and the policy should say so explicitly so nobody has to work it out under deadline pressure.
Give the policy somewhere to apply
A policy holds when the approved path is also the easiest one: one workspace, roles matching who may use AI, a model list matching the approved tools, and a usage record for the review clause.