A starter AI governance and responsible-use policy for a growing team

The question we hear from operations and compliance leads is usually some version of: “our people are already using AI tools — what is the minimum we should put in writing?” The answer is a two-to-three page document covering four things: what tools are allowed, what data may go into them, where a human must check the output, and who decides when something new comes up.

That is genuinely enough for a first version. The failure mode we see is not the policy that is too thin — it is the twenty-page policy that took eight months, arrived after shadow usage was already entrenched, and is too abstract for anyone to apply on a Tuesday afternoon.

Nothing here is legal advice. It is a practical starting structure to hand to whoever owns risk in your organisation, so that the first draft takes a week rather than a quarter.

Every workable AI policy, regardless of length, answers four questions unambiguously enough that an employee can act without asking. If your draft leaves any of them to interpretation, that is where the incidents will come from.

1. May I use this tool? A named list of approved tools, and a stated route for requesting an addition. “Use good judgement” is not an answer.
2. May I put this data in? A short data classification with concrete examples from your own business, not abstract tiers.
3. Can I act on the output directly? Named checkpoints where a human must review before anything is sent, published, filed or executed.
4. Who do I ask? A named role — not a committee, not an inbox nobody owns — who can give an answer within a working day.

Write the answers for the people who will read them. A policy phrased for auditors and not for staff is complied with on paper and ignored in practice.

Acceptable-use sections fail when they read as principles. Make them lists. Principles require interpretation under time pressure; lists do not.

Encouraged, no approval needed

• Drafting and editing internal text where the author reviews before sending.
• Summarising material the employee already has legitimate access to.
• Explaining concepts, generating options, brainstorming, rewriting for clarity.
• Writing and reviewing code in approved development environments.

Allowed with a named review step

• Anything that will reach a customer, a regulator or the public.
• Anything that feeds a financial figure, a legal position or a filed document.
• Analysis that will inform a decision above a stated monetary threshold.
• Code that will reach production systems.

Not permitted without explicit written approval

• Any use that materially determines an outcome for an individual — hiring, promotion, credit, disciplinary action, clinical or eligibility decisions.
• Uploading restricted data to any tool not on the approved list.
• Generating synthetic media of real people, or content presented as human-authored where that representation matters.
• Connecting an AI tool to a production system with write access.

The middle list is the one that does the work. Most organisations write only the first and third and leave the large, genuinely useful middle undefined.

Your existing information classification probably predates AI tools and was written for documents at rest, not for text pasted into a chat box. You do not need a new scheme — you need a mapping from the one you have to a single decision: may this go into a prompt, and into which tool?

Four tiers is enough. Give each one three or four examples drawn from your own operations; the examples are what people actually remember.

• Tier 1 — Public. Already published or publishable. Any approved tool. No restriction.
• Tier 2 — Internal. Ordinary business material with no personal or contractual sensitivity. Approved enterprise tools only — those with a contractual no-training commitment.
• Tier 3 — Confidential. Personal data, customer records, commercial terms, unreleased plans, security detail. Only into tools explicitly cleared for it, with retention and residency terms recorded. Redact identifiers where the task does not require them.
• Tier 4 — Restricted. Regulated categories, credentials, and anything under a contract that forbids third-party processing. Never into a general-purpose tool; only into a specifically approved and documented system.

One practical instruction is worth more than the whole tier table: before pasting, ask whether you would be comfortable sending this text to an external contractor under a standard non-disclosure agreement. If the answer is no, it is Tier 3 or above. Tool selection against these tiers is where the provider evaluation framework connects to the policy — the data-handling gate there is what makes a tool Tier 3 eligible here.

“A human must review all AI output” is the most common sentence in these policies and among the least effective. Universal review is ignored within a month, because most output does not warrant it and people correctly notice that.

Scale review to consequence. A simple two-factor test — reversibility and reach — produces a defensible answer without a decision tree.

• Reversible and internal. No mandated review. The author owns the output as they would their own draft.
• Reversible but external. Author review before it leaves the organisation, with a record that it happened.
• Hard to reverse, or affects an individual. Review by a second qualified person who is accountable for the outcome — not the person who wrote the prompt.
• Regulated, contractual or safety-relevant. Review by the role that would have owned the decision without AI, with the AI contribution logged.

Make review mean something

State what the reviewer is responsible for checking: factual claims and figures traced to a source, no fabricated citations or references, tone and commitments appropriate to the relationship, and no confidential material inadvertently included. A reviewer who does not know what they are looking for provides accountability theatre rather than control.

The accountability sentence to include verbatim, in some form: the named human remains responsible for the output regardless of how it was produced. That single line resolves most of the arguments that follow an incident.

A growing company does not need a formal model risk management function. It needs a short register and a repeatable intake question set, so that adding a tool is a decision rather than a download.

Intake questions for any new AI tool

1. What business problem does this solve that an already-approved tool does not?
2. What is the highest data tier that will realistically be entered into it?
3. Does the vendor commit in writing that inputs are not used for training, and what is the retention period?
4. Where is data processed, and does that satisfy our contractual and legal position?
5. Who is the named internal owner, and who else has administrative access?
6. What happens to our data and our workflows if this vendor changes terms, is acquired, or shuts down?
7. How is it paid for, and does anyone see the aggregate spend?

Keep a one-row-per-tool register with the tool name, owner, approved data tier, renewal date and last review date. Review it quarterly. That register is also what makes an eventual security questionnaire or customer audit a short exercise rather than an archaeology project. Where this sits alongside broader technology governance, our IT consulting work usually starts from the same register.

Nine sections, two to three pages. Written for staff, reviewed by whoever owns legal and risk, approved by a named executive. This is a hypothetical structure offered as a starting point, not a compliance product — adapt it to your own obligations.

1. Purpose and scope. Who it applies to (including contractors), what counts as an AI tool, and what it does not cover.
2. Principles. Four or five sentences, not a page. Human accountability, data protection, honesty about AI involvement where it matters, fairness, and proportionate oversight.
3. Approved tools. The current list and the data tier each is cleared for. Maintained as an appendix so it can change without re-approving the policy.
4. Data rules. The four tiers with your own examples, and the contractor test.
5. Acceptable use. The three lists — encouraged, review required, prohibited.
6. Human review. The reversibility-and-reach table, and the reviewer's checklist.
7. Disclosure. When AI involvement must be stated — to customers, in deliverables, in regulated submissions, in recruitment.
8. Incidents. What to do if restricted data was entered somewhere it should not have been, or an AI-derived error reached a customer. Who to tell, within what timeframe, and an explicit no-blame framing for prompt self-reporting.
9. Ownership and review. The named role that answers questions, the approval route for new tools, and a review date.

Rolling it out

• Ask what people already use before you publish. A policy that bans the tool half the company relies on, without a replacement, teaches people to hide usage.
• Pair publication with a short practical session rather than an acknowledgement checkbox — the examples are what change behaviour, and structured training makes the difference between a read policy and an applied one.
• Give the approval route a real service level, or shadow usage returns immediately.
• Revisit in six months with actual usage data. The first version will be wrong in interesting ways, and that is the point of dating it.