Policy approval is the start, not the end
Treat AI policy approval as the start of governance work, not the end — operating procedures, impact assessments, tool-specific guidelines, training, and the approved-tools register all ramp up after the policy is signed.
Organisations often treat AI policy approval as the closure of a governance project: the document is signed, the deliverable is complete, the workstream can be retired. This is exactly backwards. Policy approval is the gate that opens the operational governance work, not the gate that closes it. Most of the actual labour follows.
The shape of that labour is reasonably consistent. Operating procedures translate the policy into the steps people will actually follow. Impact assessments need to be conducted for each new AI tool or expanded use case, and assessment templates need to be designed and tested with worked examples before they can be used routinely. Tool-specific guidelines — the front-line artefact staff actually consult — need to be written for each approved tool. Training has to be developed and delivered. An approved-tools register has to be created, populated and maintained. Each of these takes more time than the policy did.
Two things make this worse than expected. First, AI is now embedded in many tools that were not previously AI tools — note-takers, search interfaces, document editors, CRM platforms — so the approved-tools register grows fast and is never finished. Second, each tool-specific guideline requires real engagement with the tool’s behaviour, not just a restatement of the policy, and that engagement is what surfaces the operational questions the policy left implicit.
The heuristic for advisors is to set client expectations explicitly: the post-approval work programme is larger than the policy-development one, and the policy itself remains a draft in operational terms until the first impact assessment, the first tool-specific guideline and the first training delivery have happened. See Start AI governance imperfect; iterate rather than wait — the iterative posture this depends on extends through all the post-approval gates, not just the policy text.
What lands well in practice is making the post-approval programme visible at the time of policy approval — a short sequenced list of the gates that follow, with named owners and rough timing. This converts an implicit “we’ll deal with operational matters later” into an explicit work programme, and it prevents the common pattern where the approved policy sits in a folder and the operational governance never starts.