Insights
What does an AI policy need to say?
Enough to be followed, and little enough to be read. The most common failure in AI governance is not the absence of a policy — it is a forty-page one that no one has opened, which offers all the protection of no policy at all while feeling like diligence. A useful AI policy fits on a page, answers the handful of questions employees actually have, and gets kept in people's heads rather than a shared drive.
This is what that page needs to say.
Keep it to a page people will read
Length is not rigour. A policy people can hold in their heads gets followed; one they have to look up does not, and one they have never read protects nothing. The goal is a document short enough that a new joiner reads it once and remembers the shape of it: what they may use, what they must never do, and who to ask. Everything that does not serve that goal belongs in a reference appendix, not the policy.
The essentials
Strip it to what changes behaviour, and five things earn their place.
| Section | The question it answers | The essence |
|---|---|---|
| Approved tools | What am I allowed to use? | A named list of sanctioned tools, and how to request a new one |
| Data rules | What can I put into these? | The categories of data that must never go into any external AI tool |
| Requesting new tools | How do I get something added? | A route that is fast enough that people use it instead of going around it |
| Disclosure | When must we say AI was involved? | When to tell a customer they're dealing with AI, and to label AI-generated content |
| Accountability | Who owns this, and what if I get it wrong? | A named owner, and the reassurance that using a sanctioned tool as intended is safe |
Two of those deserve emphasis. The request route has to be genuinely quick — the moment sanctioned access is slower than opening a personal account, people route around the policy, and you are back to shadow AI. And accountability has to reassure as much as it warns: if using an approved tool correctly can still get someone blamed, they will use it in the shadows or not at all.
The data line is the one that matters most
If the policy gets only one thing exactly right, make it the data rule. Be concrete about the categories that must never go into an external AI tool — personal data, client-confidential material, unreleased numbers, anything under a confidentiality clause — because that single line prevents the failures that actually hurt: the GDPR breach, the leaked forecast, the contract term shared with a model. Vague guidance like "use good judgement" is not a rule; name the categories, and name where the sanctioned, safe route is for each.
Tie it to the tiers
A policy does not sit on its own — it should line up with the risk tiers you are already governed by. Uses that touch consequential decisions about people (hiring, credit, and the like) may be high-risk under the EU AI Act and warrant more than a one-line mention. The policy is where the abstract obligation becomes a concrete instruction: here is what you may do, here is what needs sign-off, here is what is off-limits, sorted by how much risk the use carries.
A policy is a starting point, not the finish
The document is the easy part. It earns its keep only if the request route is quick, the approved tools are genuinely good enough that the unapproved ones lose their appeal, and the whole thing is revisited as the tools and the regulation move — which they do, constantly. A policy written once and filed is a policy already going stale. Write it to be short, keep it current, and pair it with a sanctioned on-ramp people actually want to use.
Writing an AI policy that fits on a page, ties to the risk tiers, and comes with a sanctioned on-ramp people will actually use is part of the governance groundwork Firestarter runs in its six-week accelerator — reviewed against the EU AI Act, and written where it is absent.