Answer seven questions about your company and the tools your team uses. The generator writes a complete AI use policy in eight sections, and the sentences change with your answers rather than swapping your name into fixed text.
An AI policy generator turns a few answers about your company into a written AI use policy: which tools staff may use, what data may go into them, who checks the output before it reaches a customer, and who to tell when something goes wrong. This one was built by Oleg Sotnikov, a fractional CTO who runs AI systems in production, and it writes eight numbered sections whose wording follows the answers you give. Everything happens in the browser, so nothing is uploaded and there is no email gate. The result is a starting point to adapt with your own counsel, not legal advice.
Seven answers. The document below rewrites itself as you change them.
Approved AI tool categories
Anything left unchecked is written into the policy as not approved.
May customer data be pasted into AI tools?
May source code be shared with AI tools?
Human review before AI output goes outside the company
Turn this off only if you mean it. The policy then says the sender carries the whole responsibility.
Policy review cadence
Nothing is sent anywhere. The generator runs in your browser, and your answers leave with the tab.
AI Use Policy
Section 01
[Company] allows AI tools where they make the work faster or better. This policy sets out which tools may be used, what may be put into them, and who answers for what comes out. It exists so that the data we hold stays protected and the work we deliver stays accurate.
We build and ship software, so AI reaches source code, customer environments, and product decisions. The rules below are written for that.
Section 02
This policy applies to everyone who does work for [Company]: employees, contractors, freelancers, and anyone with an account on our systems. It applies on company devices and personal ones alike.
It covers every AI tool used for company work, whether or not [Company] pays for it: standalone assistants, AI features inside software we already use, and AI we put into our own products. Using a personal account does not move the work outside this policy.
Section 03
The categories below are approved. [Owner] keeps the list of specific products inside each category and decides what gets added.
General chat assistants may be used for drafting, summarising, research, translation, and rewriting. Treat what they produce as a draft from someone who has not checked their facts.
AI coding assistants may be used for writing, explaining, reviewing, and testing code. Whoever accepts a suggestion owns it exactly as they own code they typed themselves.
Company work happens under an account that belongs to [Company], on a paid business or enterprise plan. Personal logins may not be used for company work, and neither may free tiers that train on what we enter. To add a tool, send [Owner] the name, what it is for, and what data it would see; [Owner] answers within five working days.
Section 04
AI tools may not decide anything about a person on their own: hiring, dismissal, promotion, credit, or a customer's claim all need a named person who reviews the case and owns the outcome. They may not be used to produce something misleading, to impersonate anyone, or to get around a security control.
Passwords, API keys, access tokens, and production credentials never go into an AI tool, in a prompt or in a file attached to one.
Customer data may only be entered once the identifying details are gone. Names, emails, phone numbers, account numbers, and addresses come out first, and if removing them leaves the example useless, invent one instead.
Source code may go into approved coding assistants only. It may not be pasted into consumer chat tools, translation sites, or any assistant that is not on the approved list.
AI image and media generation is not approved for [Company] material. AI transcription and note-taking assistants are not approved. Meetings are not to be recorded or transcribed by an AI tool.
Section 05
Anonymising means removing everything that points at one person or one company: names, emails, phone numbers, addresses, account and order numbers, and free-text notes that identify someone by context. Replacing a client name with "a client" is usually enough, but a rare condition, an unusual order, or a distinctive job title is not anonymous just because the name is gone.
Code shared with an approved assistant must carry no secrets. Keys, tokens, and connection strings belong in the secret store, not in the file the assistant reads.
Production databases, customer environments, and anything covered by a customer's confidentiality terms stay out of AI tools, approved ones included. Internal architecture documents and incident write-ups need [Owner]'s approval first.
Before a tool is approved, [Owner] establishes who the vendor is, where the data is stored, whether our input trains their models, how long they keep it, and whether they publish a security report such as SOC 2 or ISO 27001. Access goes through single sign-on where the vendor supports it and is removed on a person's last day with their other accounts.
Section 06
Nothing produced with AI reaches a customer, a regulator, the public, or production until a person who understands the subject has read it and corrected it. Facts, figures, names, quotes, and citations get checked before they leave [Company]. A confident invented number is the most common way this goes wrong.
AI-written code goes through the same review, tests, and pipeline as code a person typed. The engineer who submits it answers for what it does, and pointing at the assistant is not an explanation.
Whoever asked the AI for something owns the result. Responsibility does not move to the tool, the vendor, or the person who approved the tool.
Section 07
Tell [Owner] at [contact] the same working day you realise that restricted data went into an AI tool, that AI output with a serious error reached a customer, or that an AI account or API key may have been exposed.
Where personal data is involved, [Owner] follows [Company]'s existing data-breach procedure and its notification deadlines. Report first and establish the extent afterwards, because time spent checking quietly comes out of the notification window.
Reporting a mistake in good faith carries no penalty here; hiding one does. [Owner] records what happened, decides who else needs to know, and amends this policy where the same thing could happen again.
Section 08
[Owner] reviews this policy and the approved-tools list every six months.
A review also happens sooner when a vendor changes its terms, when a new tool becomes central to how the team works, when an incident exposes a gap, or when the law changes in a country [Company] operates in.
Everyone reads this policy when they join and again after each revision. Questions and proposed changes go to [Owner] at [contact].
This document is a starting point, not legal advice. What you actually owe depends on your industry, your client contracts, and the countries you operate in. Have a lawyer read it before you adopt it.
The brackets left in the text are the two decisions the form cannot make for you: who owns the policy, and where incidents get reported. Fill them in before you circulate it.
To keep it as a file, print this page (Ctrl+P or Cmd+P) and choose Save as PDF. The copy button puts the same text on your clipboard as plain text.
Four things decide whether a policy gets followed or filed. The generator writes all four into the document.
A policy with nobody's name on it drifts within a month. One person keeps the approved-tools list, answers requests for new tools, and takes the incident reports. Name them in the document itself.
People follow the list when it is current and the approval path is quick. Where a request sits for three weeks, the work moves to a personal account and out of sight.
Most of the risk sits in one question: what may be typed into the box. Say which categories are forbidden outright, which are fine once identifying details are gone, and who decides the borderline cases.
Vendor terms and model behaviour change faster than internal documents. A date in the policy, plus the events that trigger an earlier look, keeps it from describing a stack the company stopped using.
Which tools are approved and what account they must be used under, what data may never be entered, who reviews AI output before it reaches a customer, who to tell when something goes wrong, and when the document gets looked at again. Everything else is refinement on top of those five. The generator on this page writes them into eight numbered sections, and a small company can adopt the result with light edits.
Not on its own. It becomes binding on your staff once your company adopts it and communicates it, the same way an expenses or security policy does. It is not legal advice: your obligations depend on your industry, your client contracts, and the countries you operate in, so treat the generated document as a starting point and have a lawyer read it before you adopt it.
Every six months suits most companies, quarterly while AI use is still changing shape, once a year when it has settled. The triggers matter more than the calendar: review it when a vendor changes its terms, when a new tool becomes central to the team's work, or after an incident. The generator writes the cadence you pick into the last section, along with those triggers.
Usually yes, on a company account, with a clear rule about what may be typed into it. A ban moves the same work to personal logins where you cannot see it and consumer terms apply, which is a worse position than supervised use. The controls that do the work are the data rule, a named owner, and a fast path to get a new tool approved.
The policy is a document that tells staff what they may do. Governance is the layer underneath it: an inventory of the AI systems you run, a risk assessment for each, controls with evidence behind them, and someone accountable when a customer or an auditor asks. A policy is enough until AI sits in the product itself or a buyer sends a security questionnaire with an AI section, and after that you need the governance work, which is what ISO/IEC 42001 sets out.
Three ways to take this further, all of them free.
A document answers what staff may do. When a customer's security questionnaire, an auditor, or your own product needs more than that, the next layer is an inventory of the AI systems you run, a risk map, and controls with evidence behind them. That is the governance work I do with clients.
The generator stays free and open on this page, with no form in front of it.
AI governance, adoption, and what changes once a team uses AI every day.
