There are two kinds of AI policy. One runs to thirty pages, was approved by a lawyer and hasn't been opened since. The other doesn't exist: everybody does their own thing, and whoever does it well does it well on their own authority.
The first policy is safe on paper. It just isn't read, so it isn't followed. The second is safe for nobody.
Why policies usually don't work
The cause isn't length; that's a symptom. A policy gets long when it describes instead of deciding. It explains what AI is, lists the risks, refers to legislation and warns about all sorts of things. But the colleague who wants to run a quote through a model on Monday morning can't find out from it whether that's allowed.
A work policy has one job: for every situation someone meets in the course of a week, say what happens. Is this allowed? Who looks over it? What gets recorded? Anything that doesn't answer those questions belongs in an appendix, or nowhere.
What goes in: the phases of SEAL
The content is mostly known once you've sorted a workflow. If you haven't, it's worth doing that first. SEAL gives the backbone.
SEAL describes the four phases knowledge work goes through: Source, Edit, Approve, Launch. In every phase the traceability of a source can be lost, and the weakest phase determines what the work is worth.
A policy that covers those four phases isn't missing anything essential, because for each phase it says who signs for what. And that's what a policy has to be able to show after an incident.
The six blocks
One A4 page has room for six blocks of three or four lines. There's no more space than that, and that's the point.
1. With what. Which systems are allowed, by name. Not "AI tools" but the three or four the team actually works with. A system that isn't listed needs permission first.
2. Allowed. The steps AI may do on its own, with an example for each. This is the bin where the result can quickly be set next to something and a mistake costs little.
3. Allowed with a check. The steps where AI produces the work and a person sets every claim next to the source. Say who does it and what gets ticked off. Without those two, "with a check" is a wish.
4. Not allowed. Short, and with the data that never goes in: personal data, client documents under non-disclosure, anything that mustn't leave under contract. Plus the steps that stay with a person: the judgement, the release.
5. What you record. One line saying what trail a step with AI leaves and where it's kept. What belongs in that trail is covered in the article on what to record when you work with AI.
6. When in doubt. A name, not a department. Who decides, how quickly, and that the new answer goes into the policy. Plus a date when the policy is reviewed, and by whom.
Filling in a block
A made-up example, to show how concrete it can be. A small educational publisher, block 3:
Allowed with a check. Rewriting a lesson sheet to a different level. The editor sets every factual sentence next to the source text and ticks off the passage. A rewritten sentence needs a new tick. Final editor (Sanne) signs off the release.
That's three sentences, and a new colleague knows what has to happen on Monday. Note what's missing: no explanation of language models, no reference to ethics, no "to the best of our ability".
Two writing rules help keep it that way:
- Every line starts with a verb or a step. "Rewrite lesson sheets" works. "Handle generative AI responsibly" doesn't, because you can't check against it.
- Every "who" is a name, or a role held by one person. "The organisation", "the team" and "one" don't sign for anything.
Why it has to be one page
One page forces a choice. What doesn't fit isn't a decision, it's background. And one page hangs above a desk, goes along to a first meeting and gets handed to a new colleague on day one. A thirty-page document doesn't.
One page also goes out of date quickly. That's why it needs a review date. For most teams an annual rhythm is enough. If something significant changes sooner, such as a new system or an incident, it's revised sooner. The policy follows the work, not the other way round.
A test with three situations
You won't find out whether the policy works by rereading it. You find out by giving it to someone who didn't write it.
Take a colleague who doesn't know it yet. Put three situations to her from last month's work, say a summary of a report, an email to a client and a list of CVs. For each, ask: is this allowed, who looks over it, what gets recorded? If the colleague can answer all three within a minute, you have a usable policy. If she has to search, a block is missing or a line is too vague.
What you can do this week
- Sort one workflow into three bins: yes, yes with a check, no. The article on sorting a workflow shows how.
- Make one A4 page with the six headings. Fill each block with four lines at most.
- Put a name rather than a department in blocks 3 and 6.
- Give the policy to a colleague who hasn't seen it, with the three situations.
- Put a date in the diary for the first review.
Doesn't it fit on one page? Then there's still a line in it that's explanation, not a decision.