Governance That Enables

Governance has to say what people can do as clearly as it says what they can't.

Most AI governance settles into one of two defaults. Either the organisation blocks the tools until it understands them, or it releases them and deals with what emerges. The first fails because staff have the same tools on their own phones, so a blanket no doesn't stop the work, it just stops your visibility of it. The second fails more slowly, as unmanaged solutions accumulate and each one becomes a small unexamined risk until one of them matters. Neither of those is governance. They're the two ways of not doing it.

We tried to do better than that, and what we found was that our early drafts still consisted almost entirely of controls. Assessment criteria, approval routes, who signs off what. All of it necessary, but all of it describing the moment something gets stopped or checked. Nowhere in those drafts was there a clear statement of what somebody in a corporate team could do that afternoon without asking anyone.

That gap matters more than it looks. If the only visible output of governance is the machinery that catches things, the message people take from it is that anything worth doing needs permission, and a lot of people who hear that message simply stop. They don't come and ask. They either do nothing, or they carry on quietly and you lose sight of it, which is the same failure as the blanket ban arriving by a longer route.

So the shape our thinking has landed on separates two kinds of activity and governs each differently.

The first is everything that's safe to do now with the tools we've enabled: summarising meetings, drafting, analysing documents you already have access to, writing and reusing prompts, building a personal agent that only touches your own work. We're calling this the permissive tier, a set of activities built around open, visible support for approved features beneath a threshold, so that people feel comfortable exploring freely within it. The controls that keep that space safe sit in the platform and in onboarding, so once someone has covered the basics, nobody fills in a form to try something.

The second is anything that starts to look viable, could scale, or would touch data beyond the person building it. That moves into the controlled tier, where there's a gate and an assessment before it goes further. The question at the gate isn't whether the idea is good, since plenty of good ideas should still be stopped for now, but whether the organisation can support a solution of that type at scale given where our maturity currently sits, and whether somebody in the receiving function can own it once it's built. A no from the gate should almost always be a not yet, with a description of what would change the answer.

The two tiers support each other and play different but equally important roles, and because widespread adoption is what underpins the broader organisational efficiencies we're after, they need equal focus. The permissive tier is where we explain what's safe, review what people are building and share what's working, and it's also where the gate gets manned. The people closest to everyday use are the ones best placed to develop early use cases, and regularly spot where these could become useful to the wider organisation, often the customers of their function. However, you need someone independent who is advising when doing so contains a level of risk the permissive controls were never designed to hold.

The clearest example we've seen is a personal agent that a team wants to open up to the whole organisation. Whilst it was personal, its outputs were reviewed by the person who built it, who knew what it was for and could tell when it was wrong. Once it becomes broadly accessible and other people start depending on its outputs, that safety net disappears, and the same agent now needs a far more thorough evaluation for a whole host of reasons, from the accuracy of what it produces to who's accountable when it's wrong and whether the data it draws on is appropriate for everyone who can now reach it. Nothing about the agent has changed, but its position has, and that's rightly what moves it into more comprehensive governance.

That handoff is what allows the permissive tier to be generous. A great many small experiments can run without individual review because anything that tries to become organisational gets caught and assessed, whereas without the gate the only responsible option would be to shrink the permissive space, and that would kill the exploration the whole thing depends on.

What we underestimated was how much the permissive tier needs beyond defining what's safe. A permission nobody knows about, or nobody feels confident acting on, changes nothing. So we're putting the same effort into that tier that we'd put into the controls: training aimed at the capabilities that move people along the ladder rather than at menus, people in each area who can answer the "am I allowed to" question in the moment, and a team rhythm where leaders ask what people tried and what they'd try next. Above all, the safe and useful work needs to be shown, visibly and often. When somebody builds a prompt that saves their team an afternoon a week, that story tells everyone else they're allowed to do the same, and it does so more effectively than any policy document could. We've started to think of that as a governance act, even if it doesn't look like one.

There's an instinct, and we've felt it ourselves, that the opportunity is large enough to justify moving quickly and tidying up later. The intent behind it is right. Governance should be supporting innovation, and a model that slows everything to the pace of the most cautious reviewer isn't protecting anyone. Where the instinct goes wrong is in treating speed as a general setting, when what's safe to move quickly on depends on which tools you actually have, which features are on, and how mature your controls and your people are at this moment. Those are knowable things, and once they're mapped the permissive space can be as wide as the evidence supports.

That map won't stay still. As readiness matures, features that needed an assessment last year become things anyone can do this year, and the space grows. So the governance has to move with it, reviewed on the same rhythm as the maturity reads it depends on. A framework written once and left alone will be too restrictive within a year, or too loose, and quite possibly both in different places.