Who controls the AI initiative?

Most government AI programmes are designed to fail. Not by intent, but by instinct.

When a public organisation decides to build an AI initiative, it does what public organisations always do with new things they do not fully understand: it builds controls around them. Governance committees. Approval gates. Reporting requirements. Risk registers. One layer of oversight for each layer of anxiety.

The result is a programme that can barely move. And barely moving is, for an AI initiative, fatal.

Tightening governance does not improve accountability. It often destroys it. The question worth asking, before the first committee is formed and the first template circulated, is not how much governance to apply. It is what kind.

I spent the first part of my career as an internal auditor. It is not the most obvious route into management and leadership. Auditors are trained to ask questions that make people uncomfortable: not "did you follow the procedure?" but "did the procedure achieve anything?" Not "is the control documented?" but "does it work?" That habit of mind does not leave you when you cross into management. You quickly discover that most governance problems are not problems of insufficient oversight. They are problems of misdirected oversight: controls designed to produce the appearance of managing risk rather than the reality of it. That is the problem at the heart of most public AI governance, and it is what this article is about.

Two kinds of bureaucracy

In 1996, Paul Adler and Bryan Borys published a paper that should be required reading for anyone designing governance for a public AI programme. They identified two fundamentally different kinds of bureaucracy.

Coercive bureaucracy uses rules and procedures as instruments of surveillance and compliance. It is opaque. It concentrates discretion at the top. Its implicit message to everyone inside the system is: we do not trust you to get this right.

Enabling bureaucracy uses rules and procedures as scaffolding. It is transparent. It distributes discretion. Its implicit message is: here is the support you need to do this well.

The difference is not cosmetic. Coercive systems attract compliance behaviour. People do what the rules require and nothing more. They avoid risk not because they are cautious by nature, but because the system punishes visible mistakes more sharply than it rewards initiative.

Enabling systems attract ownership. People stretch toward outcomes because the structure supports that stretch rather than constraining it.

An AI initiative needs ownership. Experimentation, iteration, and learning from failure are not nice-to-haves in AI development. They are the method. A governance structure that systematically suppresses them is not managing risk. It is manufacturing it.

Apply the auditor's question to a coercive AI governance structure and the answer is uncomfortable. The controls exist. The documentation is extensive. But what risk are they actually managing? The risk of visible process deviation, mostly. What risk are they manufacturing? The risk of building the wrong thing in the wrong direction, for years, with nobody genuinely accountable for the outcome. That is a poor control design. It fails the most basic test.

Where rigour belongs

There is a version of the enabling governance argument that is dangerously incomplete.

Freedom to experiment does not mean freedom to experiment carelessly. The enabling design applies to how an AI initiative governs its development process: who has authority, how decisions are made, how iteration is handled, how failure is learned from. It does not apply to the security and safety environment in which that experimentation happens. There, the standards are non-negotiable and must be genuinely rigorous, not documented-as-rigorous.

This matters especially for AI. Deep learning models are fundamentally opaque. The people who build them cannot fully predict their behaviour across all inputs or always explain a particular output. That opacity is not a flaw that better documentation will fix. It is a structural property of the technology at its current stage of development. The environment in which AI experimentation happens must therefore be built to be safe, not just certified as safe.

In practice: data must be isolated, access controlled, and the consequences of unexpected model behaviour contained before they reach citizens or critical systems. Adversarial testing and red-teaming before real user exposure. Honest internal reporting of unexpected behaviours, treated as information rather than liability. These are engineering requirements, not compliance checkpoints. This is the oldest argument in the audit canon: the question is not whether you have a control, but whether the control actually controls. A lock on the door is a control. A policy stating that the door should be locked is not.

The secure container and the enabling process are not in tension. They reinforce each other. Because the environment is genuinely safe, the people working inside it can move faster and take more risks with their approaches. The container is what makes responsible experimentation possible.

This is also where coercive governance most visibly fails even on its own terms. Coercive frameworks treat security as a documentation category rather than an engineering requirement. A risk register is not a safe environment. An approved data management policy is not a controlled data environment. What looks like rigorous security governance is often rigorous security documentation, and the two are not the same thing.

For AI specifically, that gap is more consequential than in most other technology domains. If the secure container is not genuinely built, the freedom to experiment inside it is not freedom. It is recklessness with paperwork.

The accountability illusion

Coercive governance does not produce accountability. It produces the appearance of accountability.

When every decision requires a committee, every expense an approval chain, and every action a documented rationale, the compliance record looks impeccable. But compliance data is not outcome data. Knowing that the process was followed tells you nothing about whether anything worked.

The mechanism of drift is subtle but consistent. Because the governance structure rewards documentation over delivery, the people inside it gradually learn to optimise for what can be reported. Goals get restated in terms that are easier to achieve. Success metrics migrate toward inputs, budgets spent, committees convened, reports produced, and away from outputs. The original purpose does not disappear suddenly. It dissolves slowly, absorbed into a revised narrative, because the governance structure provides no feedback loop to catch the drift. By the time the gap between what was promised and what was delivered becomes undeniable, it is too late to course-correct.

This is what makes coercive governance particularly dangerous for AI programmes. AI development is inherently iterative. You learn what works by building, testing, and adjusting. A governance structure that requires a new approval cycle for every change in direction is not just slow. It actively prevents the learning that the programme depends on.

Enabling governance is more demanding, not less. It holds people accountable for outcomes: did the service get adopted? Did it work across the domain boundaries it was supposed to cross? Did users come back? These questions are harder to answer than "was the approval form signed." That is precisely what makes enabling governance a real accountability system rather than a performed one.

If you nail everything shut, you will have expenditure and documentation. You will not necessarily have results.

Why the wrong default persists

The pressure toward coercive governance is not irrational. It is a rational response to the incentive environment public organisations operate in.

Political accountability is asymmetric. A minister whose AI initiative produces a visible scandal faces parliamentary questions and reputational damage. A minister whose initiative simply delivers less than it could faces a budget conversation. The downside of the first kind of failure is steeper than the opportunity cost of the second. So governance structures are designed to prevent the first, at the cost of enabling the second. That is a reasonable calculation. The problem is that it produces programmes structurally blind to the quieter, more common failure of just not working.

Procurement doctrine compounds this. The logic of public procurement assumes you can specify what you want in advance, verify delivery against that specification, and enforce compliance when it falls short. Applied to AI development, this logic breaks down immediately. You cannot write a specification for something you are still figuring out how to build. The attempt produces either a scope too rigid to survive contact with reality, or one so vague it provides no accountability at all.

Audit culture does the rest. Public organisations prepare constantly for after-the-fact scrutiny. The result is a preference for defensible decisions over good ones. The question in the room is rarely "what is the right thing to do?" It is "what will this look like in an audit three years from now?"

Together, these pressures produce structures that look rigorous but function as handbrakes.

What the evidence shows

The pattern is visible wherever public AI and digital programmes have been designed and honestly evaluated.

The UK Government Digital Service, built from 2012 onward around the principle that "the strategy is delivery," adopted an enabling governance model from the start: small teams with genuine authority, outcome metrics rather than process compliance, and a mandate to iterate publicly. It produced GOV.UK, consolidating nearly two thousand separate government websites into a single coherent platform in under two years. The predecessor model had produced IT programmes that ran years late and cost multiples of their estimates. The National Programme for IT in the NHS spent an estimated twelve billion pounds over a decade before being quietly dismantled without delivering its core objective. The contrast is not a coincidence. It is a governance design choice made at the outset.

Estonia's X-Road infrastructure offers the longest running evidence. Rather than building a centralised control layer, X-Road was designed around distributed trust: data stays at its source, access is enabled through a common technical layer, each organisation retains full responsibility for its own data. That architecture has been running since 2001, is now deployed in more than twenty-five countries, and underpins a government where ninety-nine percent of public services are accessible digitally. Centralised control would have made the system fragile and slow to adopt. Distributed trust made it resilient and scalable. Every country that adopted X-Road made a governance choice, not just a technology choice.

The EU AI Act, which entered into force in 2024, provides an instructive counterexample. Its compliance architecture, conformity assessments, technical documentation packages, registration requirements, and notified body involvement, follows the coercive template with precision. The compliance burden falls most heavily on the public sector organisations least equipped to absorb it, while large technology companies with dedicated legal functions are better positioned to navigate it. Full compliance with the Act is compatible with deploying AI that produces poor results for citizens, as long as the documentation is correct. Whether it will produce better AI, rather than better-documented AI, will become apparent over the next decade.

What good design requires

The design choice is made at the beginning, before the first governance structure is formalised. It is also, typically, the moment when it receives the least attention.

Enabling governance is not the absence of governance. It is governance oriented around the questions that actually matter. Agreements framed around what should be achieved rather than how it should be done. A governance layer lean enough to ask the right questions rather than generate the right forms. Genuine authority distributed to the people doing the work. Tolerance for iteration, including the kind that requires acknowledging publicly that something did not go as planned.

There is also a structural dimension that internal governance design alone cannot resolve. An AI initiative confined to a single department, or requiring negotiated agreement from every other department before it can touch their data, will either stay small or quietly redefine its mission to fit its constraints. The mandate to work across policy domains is not a feature. For any AI programme meant to serve citizens across multiple public services, it is the precondition for everything else. Good internal governance combined with a cross-domain mandate is what makes scale possible. Without the mandate, you get well-run small programmes.

The pilot's checklist is the right analogy. It is a form of control. No pilot feels mistrusted by it. It exists to support judgment, not replace it.

In an enabling governance structure, the auditor's job is not to verify that procedures were followed. It is to ask the harder questions: are the outcome metrics measuring the right things, or have they drifted toward what is easy to report? Is the secure container genuinely engineered, or documented into existence? Is the distributed authority creating accountability, or creating gaps in it? An auditor who limits themselves to compliance verification in this environment is not adding value. An auditor who insists on asking whether the controls are actually controlling is indispensable.

The design choice is available at the start of every initiative. Most of the time, no one is paying attention when it gets made.

Think about it.

Sources

• Paul Adler & Bryan Borys, "Two types of bureaucracy: Enabling and coercive," Administrative Science Quarterly, 1996. Primary theoretical grounding for the enabling/coercive distinction.
• Edward Deci, Richard Koestner & Richard Ryan, "A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation," Psychological Bulletin, 1999. Background on how external monitoring affects intrinsic motivation.
• John Meyer & Brian Rowan, "Institutionalized organizations: Formal structure as myth and ceremony," American Journal of Sociology, 1977. Background on performative compliance in public organisations.
• Karin Bijlsma-Frankema & Ana Cristina Costa, "Understanding the trust-control nexus," International Sociology, 2005. On the relationship between control structures and trust.
• UK Government Digital Service, GOV.UK history and design principles, gov.uk/guidance/government-design-principles, retrieved April 2026.
• House of Commons Public Accounts Committee, "The National Programme for IT in the NHS: an update on the delivery of detailed care records systems," HC 1070, Session 2010-12, published 2011. Source for NHS NPfIT outcome figures. The £12 billion figure is the National Audit Office's projected lifetime cost of the programme, estimated June 2006.
• Republic of Estonia, X-Road documentation and international deployment record, x-road.global, retrieved April 2026.
• EU AI Act, Regulation EU 2024/1689, Official Journal of the European Union, 12 July 2024. Governance architecture for high-risk AI systems.