Governance work has an unhelpful reputation as the thing that delays the rollout. Done at the wrong depth it is exactly that. The useful version is small: a handful of decisions made before launch because they are costly to reverse, and a deliberately short list of everything else, deferred on purpose.
Decide before launch
1. Which data classes are allowed in
Not a list of banned words. A short classification your staff already recognise — public, internal, confidential, regulated — and a plain statement of which of those may be used with the platform. Two sentences that a person can hold in their head beat six pages nobody opens.
2. Who owns the output
When an AI-assisted document goes to a client, someone signs it. Say who, and say that the assistance does not transfer responsibility. This sounds obvious and is the single most common gap in the policies we see, because it is the one question the technology does not raise for you.
3. What is logged and for how long
Retention is hard to apply retroactively: you cannot recover detail you did not keep, and you cannot un-keep transcripts a works council later objects to. Decide the period, decide who may read the log, and write both down before there is a log.
Three decisions. Everything else on the usual governance checklist can be made in month two with better information than you have today.
Defer on purpose
Approved use cases, per-department model policy, prompt review, cost allocation — all of these are real, and all of them are easier to get right once you can see actual usage. Writing them in advance means guessing, and a guess written as policy is harder to change than a gap.
State the deferral explicitly. "We will review model access by department after ninety days" is governance. Silence is not.
The rollout shape that works
- Start with two or three departments that have a real, named task, not with the departments that volunteered.
- Give them the training in the workspace, not a separate system, and make it about their task.
- Wait sixty days. Read the usage. Find out what people actually did, which is never what the pilot proposal predicted.
- Then write the second layer of policy, informed by that, and widen.
Who owns this
Rollouts stall on ownership more often than on policy. AI touches security, legal, IT, procurement, learning and every operating department, which means six functions each hold a veto and none holds the plan.
The arrangement that tends to work is one accountable owner with a real budget, and a standing group of the others that meets monthly rather than approving serially. A committee that must reach consensus before anything ships produces the safest possible plan, eighteen months late, for a technology that will have moved.
Name the owner in writing. If the answer to "who decides" is a department rather than a person, it has not been answered.
The works council conversation
In jurisdictions with formal employee representation — and in plenty without — the audit log is the part that raises objections, and the objection is legitimate. A complete transcript of every query is, among other things, a record of what individual employees did all day.
Going in having already decided the retention period, who may read the log, and under what circumstances, converts a confrontation into a review. Two commitments defuse most of it: that the log is used for security and cost investigation rather than individual performance management, and that access to it is itself logged. Both are easier to promise before launch than to retrofit after the first request to "just pull up what they were asking".
What the board will ask
Three questions, reliably. Where does our data go. What are we spending. What is it doing for us.
The first two should be answerable from an admin console in a minute — deployment model and residency for the first, seats and per-department usage for the second. The third is the one that needs preparing, because usage is not value. Pick two or three concrete outcomes from the pilot teams and describe them in their own terms: the report that now takes an afternoon, the response times that changed, the backlog that cleared.
The failure mode to watch
The most common way this goes wrong is not a breach. It is drift: a platform that was governed at launch and then accumulated a year of new departments, new integrations and new model options without anyone revisiting the three decisions above.
Put a date in the calendar for the review at the same time you put in the launch date. It is the cheapest control on this page.