When a board or an ExCo decides it's time to "do something about AI governance," the instinct is almost always to write a policy. Get something on paper, circulate it, tell people what they can and can't use. It feels like progress. It usually isn't, because it skips the step that makes the policy enforceable at all: knowing what's actually happening today.
By the time governance becomes a board-level conversation, staff have typically been using AI tools for a while already: a chatbot for drafting, a coding assistant, a summarisation tool bolted onto email. Writing a policy before establishing what's in use is writing rules for a system you can't see. It also puts you in the position of banning things that people are already relying on to do their jobs, which tends not to work.
The more durable starting point is visibility: an honest inventory of what tools are in use, by whom, for what, and what data touches them. This is rarely a comfortable exercise. It usually surfaces more shadow use than anyone expected, but it's the only way to write a policy that reflects reality rather than an idealised version of it.
From there, the second thing that actually matters is accountability, not enthusiasm for the technology itself. Who signs off a new AI tool before it touches customer data? Who owns the register of approved tools? Who's responsible when a vendor's AI feature changes behaviour without notice? These are governance questions, not technical ones, and they need an owner before the first policy document is even drafted.
Only once visibility and accountability exist does a usage policy become something people can actually follow, rather than a document that sits in a folder while shadow use continues unchanged underneath it. The policy also needs less reinvention than most organisations assume: a workable starting framework can draw on existing information security and data protection controls rather than inventing an entirely new discipline from scratch.
The organisations moving fastest and most safely on this aren't the ones with the most sophisticated policy language. They're the ones that treated the underlying visibility problem as the actual project, and the policy as the output of solving it, not the other way around.