Most AI governance advice is written for companies with a legal department, a risk committee and a compliance officer who owns a spreadsheet. If you have fifty people and one overworked ops lead, that advice is useless to you.
You still need a policy. Research suggests around 63% of organisations lack one entirely, and that 97% of AI-related breaches happened where proper AI access controls were absent. Those two numbers are related.
Start With One Page, Not Twelve
A policy nobody reads governs nothing. Your first version should fit on one page and answer four questions: what tools are approved, what data must never go into them, who decides on new tools, and what happens when someone gets it wrong.
Everything else is elaboration you can add once the basics are actually being followed.
The Four Rules Worth Writing Down
- An approved list, kept current. Name the tools people may use. Review it monthly, because a list that goes stale drives people straight back to unapproved tools.
- A data red line. Be specific. Customer personal data, credentials, unreleased financials and anything covered by a client NDA do not go into any AI tool, approved or not.
- A named decider. One person approves new tools within five working days. Slow approval is the single biggest cause of shadow AI, so treat the SLA as part of the control.
- A no-blame reporting route. If someone realises they pasted something sensitive, you need to hear about it that hour. Punishment guarantees silence, and silence is what turns a mistake into a breach.
Then Add the Agent Rules
Chat tools are the easy half. The moment agents can take actions in your systems, governance has to cover behaviour rather than just data.
- Every agent has a named owner. A human accountable for what it does, reviewed when they change role.
- Least privilege by default. Read-only unless a specific case justifies more, documented in one line.
- Irreversible actions need approval. Money, external communication and deletion always have a human gate.
- Every tool call is logged. If you cannot reconstruct what an agent did last Tuesday, you cannot govern it.
- Third-party servers are reviewed before install. Treat them as code you did not write, because that is what they are.
What to Measure Quarterly
| Question | Why it matters |
|---|---|
| How many unapproved tools appeared | Tells you if approval is too slow |
| How long approvals took | Your leading indicator for shadow AI |
| How many agents have no named owner | Orphaned automation is the classic audit finding |
| How many agents hold write access | Privilege creeps silently |
| Incidents reported voluntarily | A rising number here is good news, not bad |
The Mistake to Avoid
Do not write a policy that bans everything. Bans push usage underground, where you have no visibility and no controls at all. A permissive policy with a fast approval path and a hard data red line beats a restrictive one that everyone quietly ignores.
The goal is not zero AI use. It is zero AI use you cannot see.
Conclusion
Write one page. Name the approved tools, draw a hard line around sensitive data, appoint one decider with a five-day SLA, and make reporting mistakes safe. Add agent-specific rules the moment anything can take an action rather than just answer a question. Review it every quarter and count the approval delays, because that number predicts your shadow AI problem better than any scanning tool.
Frequently Asked Questions
Do we need this if we only use one AI tool?
You almost certainly use more than one. Between chat assistants, coding tools, meeting notetakers and features embedded in software you already pay for, the real count surprises most teams.
Who should own the policy in a small company?
Whoever owns IT security in practice, even if that is not their title. It needs one owner, not a committee, or nothing gets reviewed.
How often should the approved list change?
Monthly. This market moves fast enough that a quarterly list is a stale list, and stale lists get ignored.