AI governance guide
A one-page AI policy
Long policies do not get read, and an unread policy is not a control. Here is the short version, and what each part is for.
Why most AI policies fail
They are written to satisfy an auditor rather than to guide a decision. "Exercise appropriate caution when using AI tools with sensitive information" tells a member of staff nothing actionable, so they fall back on their own judgement — which is precisely the situation the policy was meant to remove.
A working policy answers one question: can I put this into that tool? Everything that does not help answer that is padding.
The structure that works
- Data classes, named in your terms. Four is enough: public, internal, confidential, restricted. Use real examples from your business — "client contracts", "patient records", "supplier pricing" — not abstract categories.
- Approved tools, listed. By name. A policy that says "approved tools" without listing them is not a policy.
- The routing table. Which class may go into which tool. This is the whole policy; everything else supports it.
- What is never permitted, concretely. Credentials, personal data of customers, anything under a specific restriction.
- What to do when unsure. Name a person. Not a mailbox.
- Verification requirements. Which outputs need checking before use, and how.
- Disclosure. When to tell a customer AI was involved.
Worth saying: One page. If it runs longer, you are writing for an auditor rather than for the person deciding whether to paste a contract into a chat window.
The routing table is the policy
Everything else is context. A member of staff holding a document should be able to find its class, find the tool, and get a yes or no in fifteen seconds.
Where the answer is no for a confidential class and the work genuinely needs doing, that is the business case for a private deployment. A policy that forbids useful work without offering a compliant route creates shadow usage rather than preventing it.
Keeping it alive
- Review when a tool is added, not on a calendar.
- Make policy sign-off part of purchasing, so new tools cannot arrive unreviewed.
- Re-read vendor terms annually. They change.
- Revisit after any incident or near miss, and write down what you changed.
Questions people actually ask
Before you call
Can we just use a template?
As a skeleton, yes. The routing table and the data examples have to be yours — a generic template fails precisely at the point where a member of staff needs an answer about a specific document.
Who signs it off?
Whoever can say no and make it stick. In a smaller business, an owner.
Do we need staff training on it?
A short session, on real examples from your own work. Handing out a document achieves very little. Corporate training covers this properly.
Still have the question?
Ask us directly. We answer these on calls all day.