Two pages, not forty. Copy it, cut what does not apply, and put a name against every clause.
Most published AI governance material is written for organisations a hundred times the size of the ones asked to adopt it. The result is a document that is approved, filed, and never consulted — which is worse than having none, because it creates the appearance of control.
This is the version we would write for a company of thirty people. It is deliberately short, it assumes you are buying AI rather than building it, and every clause is one somebody can actually be held to. Take it, change it, and put your own name on it. There is nothing to fill in and nobody to email.
Everything below is the document. Square brackets are the decisions only you can make.
This policy applies to everyone at [Company], including contractors, when they use any tool that generates text, code, images, audio or decisions from a model — whether the company pays for it or not. Personal use on personal accounts and personal devices is out of scope, unless company information is involved, in which case it is in scope.
Why The unpaid clause is the one that matters. Most AI use in a company of your size is on somebody's own free account.
The tools approved for company work are [list]. Anything else requires approval from [name] before company information goes into it. Approval is usually quick; the point of asking is that somebody knows what is in use.
We will keep this list current rather than complete. If a tool you need is missing, ask — a policy that makes the useful thing forbidden gets routed around instead of followed.
Why A list, not a principle. "Use approved tools" without naming them approves everything.
Do not put any of the following into a tool that is not on the approved list, and check the terms before putting them into one that is:
If you are unsure whether something belongs on this list, it does. Ask [name].
Why Written as a list of things rather than a category, because "confidential information" is not a test anyone can apply at speed.
A person is accountable for every output that leaves the company or changes a record. Model output is a draft until somebody has read it.
Review must be by someone competent to judge the output. A person who cannot evaluate the code, the analysis or the legal position is not review; they are a signature.
These uses require review by [name or role] before they take effect: [anything customer-facing, anything financial, anything that changes access or permissions, anything published].
Why The competence clause is the one that gets skipped, and it is the one that prevents rubber-stamping.
We tell customers when they are interacting with a model rather than a person, at the point of interaction and not in a footer.
We do not present model-generated material as the individual work of a named person where the distinction would matter to the reader — a reference, an assessment, an apology.
Where a customer contract or a regulator requires more specific disclosure, that requirement wins over this policy.
Why Short because the honest version is short. Most disclosure failures are a decision to be vague, not a gap in the rules.
[Name] owns this policy and the approved-tools list.
Any new AI system that touches customer data, money, or a hiring decision is approved by [name] before it is deployed, and the approval records what the system does, what it is permitted to do, and who to contact when it misbehaves.
This policy is reviewed on [date] and whenever an approved tool materially changes what it does with inputs.
Why One name, not a committee. If nobody is named here the policy has no owner and will be out of date within a quarter.
If a model produces something harmful, if confidential information reaches a tool it should not have, or if an output caused a decision that has to be undone, tell [name] the same day.
We treat these as system failures rather than individual ones. A policy that punishes the person who reports the mistake guarantees the next one is concealed, and concealment is the part that turns an error into an incident.
Why The no-blame clause is not softness. It is the only way you find out.
If the policy raises questions about the purchase.
Writing one of these tends to surface the decision underneath it — whether to adopt at all, which vendor, and who is accountable when it is wrong.
AI advisory →