Why an AI policy should open with specific permissions, each naming the task, the safeguard and the data boundary in one sentence, instead of leading with a list of prohibitions staff will route around.
An earlier piece in this series argued that a ban is a measurement failure: prohibiting AI use does not stop the use, it just stops the organisation from seeing it, and the work migrates to personal accounts and unlogged tabs instead. That argument settles what a policy should not lead with. It does not settle what a policy should say instead. This piece opens a short run on actually writing an AI policy, starting with the single structural decision that shapes everything after it: which section comes first, the list of what is permitted or the list of what is forbidden.
Most draft policies default to prohibition first, because prohibition is the part everyone feels most urgency about writing down. That default is the mistake. The permissions section has to come first, and it has to be specific enough to be usable, not a paragraph of reassurance sitting ahead of the real content.
A reader forms an impression of a policy document from whatever comes first, and that impression is what they act on later, not the caveats buried in section four. A document that opens with a list of prohibitions reads as a document about what not to do, and staff respond to that framing exactly as they would to any other list of don'ts: they route around it rather than through it. A document that opens with a list of what is actually permitted reads as a document about how to do the work, and the prohibitions that follow read as the boundary of an enabling structure rather than as the entire point of writing the thing down.
A permission that reassures without specifying anything is worse than no permission at all, because it gives staff the confidence to act without giving them the boundary that makes the action safe. "AI tools may be used where appropriate, with appropriate care" commits the organisation to nothing and tells a programme officer nothing about what she can actually do on Monday morning. A usable permission names the task, names the safeguard, and states both as an instruction, not a hedge.
A policy that only says what is forbidden teaches people to avoid the document. A policy that says what is permitted teaches people to use it.
A permissions section this concrete is slower to write than a general reassurance, and it dates faster: naming specific tools and tasks means the document needs revisiting as tools change, which a vaguer permission would have avoided by saying almost nothing. The honest answer is that this cost is the actual cost of writing a policy that gets followed rather than filed. A vague permission ages better only because nobody is using it to make a real decision; a specific one needs a standing review cycle, which this series will return to, but it is the version staff can actually act on in the meantime.
Write the permissions section first and make every entry in it name both the permitted task and its safeguard in one sentence; a policy that leads with prohibitions gets routed around, and a permission vague enough to avoid revision is too vague to be used.
If this is the question on your desk, a thirty-minute call tells you whether the service fits, or that you do not need us yet.