Operating AI governance — the work that starts after the policy
Policies fail on response time, not on wording.
AI Tools Hub Editorial · published · updated
Why the document alone does nothing
Six months after publication, teams are using whatever they like again — not because it was forbidden but because there was no request path, or the path was slow. What is needed is an answer within days.
Four roles to assign
| Role | Work | Cadence |
|---|---|---|
| First-line review | Check the request against the approved list | As needed, target 2 working days |
| Individual review | Risk-assess a new tool and decide | As needed, target 2 weeks |
| Exception approval | Permit out-of-policy use with conditions | As needed |
| Inventory review | Check usage and changed vendor terms | Once or twice a year |
Build an approved list
Individual review for every request does not scale. Publish a list of tools approved for stated purposes — and state the purpose. Not "Claude is approved" but "approved for summarising internal documents and drafting text; customer data must not be entered."
Design for exceptions
A policy with no exception path is a policy that gets ignored. Grant them with conditions and record them; the accumulated record shows you which part of the policy is wrong. Put exception authority at department-head level — centralising it in IT creates the queue.
What the inventory review looks for
- Approved tools nobody uses — cancel them
- Changed vendor terms
- Whether the assumptions at approval still hold
- Unrequested tools in the expense data
The last is the most informative. Treat what you find as evidence that the request path is inconvenient, not as misconduct.
FAQ
Do we need a dedicated owner?
Up to a few hundred people, a part-time owner works. What you need is the approved list and a stated response deadline, not a headcount.