# An AI policy short enough to be read. 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. ## How to use it - Read it once and delete every clause that does not describe your company. A policy containing rules nobody follows teaches people that the rest are optional too. - Put a name — a person, not a department — against approval, review and incidents. An unowned policy is a wish. - Set the review date before you publish it. This field moves faster than your policy will. - Circulate it as two pages. If it needs a summary, it is too long. ## The template Everything below is the document. Square brackets are the decisions only you can make. ### 1. Scope 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._ ### 2. Approved tools 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._ ### 3. What must not go into a model 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: - Personal data about customers, staff or candidates. - Anything covered by a confidentiality obligation to a third party. - Credentials, keys, tokens or production configuration. - Unreleased financial information, and anything that would move a market. - Source code, where the tool's terms permit training on inputs. 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._ ### 4. Human review 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._ ### 5. Disclosure 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._ ### 6. Ownership and change [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._ ### 7. When it goes wrong 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._ ## What this does not do - It is not legal advice, and we are not lawyers. Where a regime such as the EU AI Act applies to you, this policy is a reasonable starting position and not a compliance assessment. - It assumes you buy AI rather than build it. If you are training or fine-tuning models on your own data, you need more than this — start with who owns the outputs and what happens to the training set. - It says nothing about which tools are any good. That is a different question, and the one [we are usually asked](https://www.notacompany.com/services/ai-advisory). ## 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: