In the 1990s, some of my earliest experiences of large-scale software development and delivery involved the concept of a software factory. The ambition was to industrialise the way large teams designed, built, and maintained complex software-intensive systems by standardising key tasks and roles, to make delivery more predictable than anything previously experienced, and to do it at managed cost. This involved reusable components, standardised processes, defined roles, and measurement at every stage. The movement's intellectual backbone came from scholars such as Michael Cusumano at MIT Sloan, whose review of Japan's software factories documented in detail how Hitachi, Toshiba, NEC, and Fujitsu had applied their production management skills to writing code. For a while it looked as though software was about to grow up and behave like manufacturing.

It didn't work out that way. The factory metaphor brought some elements of discipline, and a good deal of what became modern engineering practice can be traced back to it. But the factory floor never quite materialised, because the expensive part of software was never mass producing identical goods. It was working out what to build, coordinating the people building it, and absorbing the constant change that arrived while they were building it and after it had been shipped.

The idea did not disappear. It reappeared as the global software supply chain, and I spent a good deal of the following decade studying what that looked like inside large organisations. The lesson from that generation was not that industrialisation failed outright. It was that distributing and standardising the work moved judgement around rather than removing the need for it. Every efficiency we gained created a corresponding demand for someone, somewhere, to understand what was arriving and whether it was any good.

Which is why it is striking that with AI the term “software factory” has come back. Unfortunately, it seems to be focused in the wrong place.

The Idea Already Has a Name

In January 2026, Dan Shapiro, chief executive of Glowforge, published a five-level model of AI-assisted programming borrowed from the road vehicle automation taxonomy. Level 2, where he reckons most self-described AI-native developers are stuck, is pair programming with an AI tool, with every line co-created and verified. Level 3 is the shift where most of the code is generated, and the engineer becomes a full-time reviewer of work they didn't write. Level 4 turns that engineer into something closer to a product manager who writes specifications, checks the tests and no longer reads the code at all. Level 5 is what Shapiro calls the dark software factory: nobody reviews AI-produced code, ever. The name borrows from lights-out manufacturing, where robots work in an unlit building because robots do not need to see. Simon Willison amplified the framing days later, and it has since become one of the most widely referenced maturity models in the field.

Weeks after that, the idea acquired a working example. StrongDM, an access management and security company, described a Software Factory operating under two rules: no human writes the code, and no human reviews it. Humans define intent, specify scenarios and watch the scores. Agents generate, validate against simulated environments and iterate until behaviour converges. The company's Attractor repository famously contains no code at all, only markdown specifications intended to be fed to a coding agent. Writing at Stanford's CodeX, one commentator put the uncomfortable point plainly: a firm building security infrastructure has decided that human code review is an obstacle rather than a safeguard.

The debate this has generated is almost entirely about autonomy. How much can the machine do unaided? How far up the automation ladder is your team? I think this is the wrong focus, and the two precedents the metaphor draws from both explain why.

Two precedents, Both Misread

Start with the kitchen. A dark kitchen is not primarily an automation story. There are still people cooking. What changed was the shape of the business. Stripping out the dining room decoupled the brand from the production site, which meant one kitchen could serve a dozen restaurants that existed nowhere except inside an app. It changed who employed whom, where the margin sat, which planning and hygiene regimes applied, and how much of the operation any customer or inspector could actually see. Dark warehouses did something similar to retail. The automation mattered, but the reorganisation of the value chain mattered more.

Apply that to software and the interesting questions change character. If delivery capability can be assembled as a configuration of agents rather than a human team, then the software factory decouples from the firm in exactly the way the kitchen decoupled from the restaurant. What happens to the systems integrator whose business model rests on placing bodies? What happens to the in-house platform team whose value was continuity of knowledge? A dark kitchen serves many brands from one site. An agentic delivery capability could serve many clients' backlogs from one specification pipeline, and the winner is whoever owns the pipeline rather than whoever owns the relationship. Dark kitchens also created a major inspection problem, because premises that used to be in plain view became an industrial unit behind a retail park. For anyone working in regulated sectors or the public sector, the equivalent question for software factories should raise concern.

Now the second precedent is the one I lived through. The objection to software factories was well made at the time. When Microsoft's Software Factories was published in 2004, and a copy was provided to every attendee at OOPSLA, Martin Fowler used his conference write-up to take a deliberate shot at the manufacturing metaphor, describing an instinctive negative reaction to the book's industrialisation framing. He was careful to add that there were good ideas underneath it, particularly around domain-specific languages. But in The New Methodology he set out the objection at length: the factory model rests on a Taylorist assumption that the people doing the work are not the people best placed to work out how it should be done, and the damage the engineering metaphor does is to encourage the separation of design from construction. Software, he argued, is creative professional work, and that separation is exactly the wrong approach.

Manufacturing has since made much the same point about itself. Genuinely lights-out plants remain exceptions rather than the rule decades after the idea took hold, and for most manufacturers the realistic destination is what one industry series calls the grey factory, where partial automation lets people and machines share the work and humans handle the exceptions.

So, both precedents point the same way, and neither says what the enthusiasts want it to say. What changed in dark kitchens was where the value sat, not whether people were needed. What changed in software factories was where judgement sat, not whether it was needed. Borrowing the word "dark" and reading it as "empty of humans" gets both stories backwards.

Why Agile is a Better Starting Point

If the factory is the wrong frame, agile product delivery is the right one, and it turns out to be a much more useful place from which to think about what AI is good for.

The Agile Manifesto was a rejection of that idea that a system can be specified completely before it is built. Its authors chose responding to change over following a plan, and the second principle asks teams to welcome changing requirements even late in development. Requirements are not gathered; they are discovered, and they are discovered mainly by putting something imperfect in front of somebody and watching what happens. The iteration was never a scheduling convenience. It was a position about how anyone comes to know what a system should do.

What is interesting is that Agile teams never wanted long loops. They wanted the shortest loop they could pay for, and the price was set by how long it took to build something real enough for a user to react to. That was weeks, so sprints were weeks. The economics set the rhythm, not the philosophy.

That cost has now collapsed. A team can build three working versions of a contested feature in an afternoon and put all three in front of a user, which is what the method wanted from the beginning and could never quite afford. This is the most valuable thing AI does for delivery, and it argues for more human contact with the work rather than less.

The second thing worth pointing AI at is the drudgery. Test scaffolding, fixture data, dependency upgrades, framework migrations, the long tail of maintenance, the documentation nobody wants to write, and so on. These are the parts of delivery that no amount of human judgement improves, and handing them over frees the scarcest thing on any team, which is attention. That is the honest promise of the technology, and it is a huge step forward.

What neither of those addresses is the cost of being wrong about the user needs. That has not moved. If anything, it has risen, because a pipeline that converges in hours can build a beautiful wrong solution at a scale that makes the error much harder to spot and considerably more expensive to unwind. And this is precisely where the dark factory design fails. Agile approaches put a person at the end of the loop deliberately: a customer, a user, a product owner, somebody with a stake in the outcome and the standing to say this is not what we meant. In the dark factory, the loop closes against a scenario that was itself derived from the specification, so the system validates its interpretation of the requirement against a formalisation of the same requirement. It converges. That is not in dispute. The question is what it converges on, and consistency with a specification is not the same thing as fitness for purpose.

Ethan Mollick has reached similar conclusions. In a recent essay he uses StrongDM as his example of an early dark factory, then proposes an alternative he and Lilach Mollick call the Twilight Factory: agents do most of the work, but a facilitator agent decides when to pull humans in, for approval, for expertise the model lacks, for diversity of thought, and for the parts of the job that are actually interesting. His warning is the one I would reinforce. If agents take every interesting decision and leave people the approvals, the exceptions, and the failures, we will have automated the wrong half of the job, and we will stop producing the experts whose judgement the whole arrangement depends on.

That is the choice in front of today’s digital leaders, and it is a design choice rather than a technology forecast. The dark factory is the default, not because it is right but because removing people is the easy thing to build. Deciding where the lights stay on takes deliberate effort.

So, two questions for your next delivery review. Where has the collapsing cost of building a candidate solution let you put working software in front of a real user sooner, and if the answer is nowhere, what have you bought? And if your engineers stop reading code, who in the building will be qualified to tell you that something has gone wrong? Or how to fix it?

The software factory did not fail because the ambition was foolish. It failed because we mistook the visible part of the work for the valuable part. It would be a shame to repeat that with AI.

In the early 2000s, I moved to Dallas to work in the Software Research Lab at Texas Instruments. I arrived thinking I understood all there was to know about computing. I had a degree in it, a PhD, and a decade of delivering software systems in anger. Within a few days I realised I was lost. I had walked into a different discipline that happened to share some of my vocabulary.

The people around me talked about photolithography, resist chemistry, overlay error, and the behaviour of light at wavelengths I had never had cause to think about. My mental model of a computer stopped at the instruction set. Theirs started several layers below it, in physics. Everything I had ever built sat on a set of physical constraints I had never considered and didn’t understand, negotiated by people whose names appeared in no software conference programme.

That memory returns to me every time I scroll through LinkedIn or watch the TV news and see yet another so-called "AI expert" talk confidently about how AI works, where it is going, and what matters as we consider our AI future. Because the company and the technology that matter most in the AI stack are ones that many of them, and most senior leaders, have never had to think about.

The Magic Machine

Every computer, and every AI system running on one, depends on the processor. And every processor is a pattern of transistors printed onto silicon, now numbering in the tens of billions on a single chip and separated by distances measured in nanometres. Printing those patterns is a problem of optics rather than computing, and only one company in the world has solved it.

ASML, headquartered in Veldhoven, is the only company in the world that builds extreme ultraviolet (EUV) lithography systems. Not the leading supplier. The only one. Nikon and Canon abandoned the technology more than a decade ago. Additionally, CSET's data puts ASML at 98.7% of the immersion deep ultraviolet (DUV) market too, the older tools that still do most of the work in any advanced fab.

The EUV machine prints circuit patterns onto silicon using light with a wavelength of 13.5 nanometres (compared to 193 nm for the highest-resolution of earlier DUV systems). Achieving that means firing droplets of molten tin into a vacuum chamber 50,000 times a second, striking each one twice with a high-power CO2 laser built by Trumpf in Germany, and heating the resulting plasma to around 220,000°C, roughly forty times the surface temperature of the sun. EUV light is absorbed by every known material, so lenses are useless. The light is steered instead by mirrors from Zeiss SMT in Oberkochen, polished for years apiece to a tolerance Zeiss describes this way: scale one to the size of Germany and its largest bump would be under a millimetre.

Each system contains more than 100,000 components from around 5,100 suppliers. This is less a supply chain than a thirty-year act of industrial diplomacy that happens to produce a product.

Every Frontier Model has a Physical Address

Every frontier AI accelerator in existence was printed by an ASML machine. There is no second route, and no substitute in development that will change that. When we describe compute as the binding constraint on AI progress, we are describing, several layers down, how quickly Veldhoven can build more of these machines. ASML has said it is adding around 30% more EUV capacity in 2027 and investigating a further 30% for 2028, which is a better forward indicator of AI capability growth than most model roadmaps.

This matters now because sovereign AI has become the organising ambition of technology policy almost everywhere. The Economist set out the state of play in July. Days before the G7 summit, Washington barred Anthropic from making its most advanced model available to foreigners and OpenAI followed suit, prompting President Macron to warn that nobody would buy American AI from a supplier able to turn off the switch. CNAS counts a fivefold rise in state-backed AI projects outside America and China across 2024 and 2025, with more than $70 billion committed. The Economist's verdict is that full independence is a pipe dream, though partial protection from coercion remains achievable, because almost every country will still be running on American chips, Chinese open-weight models, or both.

This has three consequences that the UK’s AI policy conversation handles badly.

The most consequential AI regulation of the past decade was not written by an AI regulator. Arguably the single decision that has shaped global AI capability most was the choice, taken in The Hague under US pressure from 2019 onwards, never to license EUV systems for export to China. No AI Act or model evaluation regime comes close to it in effect. Yet it was made by export control officials using instruments designed for dual-use goods, in departments with almost no connection to the bodies now charged with governing AI. That gap is the first thing to fix.

The layer you choose is the strategy. The Economist's analysis works down the stack, and the difficulty rises the further down it goes. Open-weight models near the top offer real control at modest cost. Compute and energy below them are punishing: Nvidia accounts for two thirds of the world's AI compute, Huawei's best answer manages roughly a fifth of the performance of Nvidia's latest, and a one-gigawatt data centre costs around $50 billion, more than two thirds of it computing equipment. Talent, which Kevin Xu argues gets the least attention of any layer, may be hardest of all, because engineers cannot be imported or downloaded.

But notice where that analysis stops. Its bottom layer is chips, and chips have a layer beneath them. ASML is that layer, and no government can buy its way into it at any price. Deciding which layers to recreate at home and which dependencies to live with is the strategic choice, and the one most national strategies never explicitly make. ASML itself illustrates how partial the results are: its €1.3 billion stake in Mistral has not stopped Mistral running largely on Nvidia hardware and American cloud. Owning the bottom of the stack did not deliver the middle.

Owning an asset is not the same as holding the decision rights over it. Europe owns the chokepoint. Europe does not straightforwardly control it. Congress is debating the MATCH Act, which would extend US authority into the servicing of machines already installed in China. The Dutch Trade Minister travelled to Washington in June to lobby against it, and The Hague has stated plainly that it intends to remain responsible for its own export control policy. Sovereignty, as Xu puts it, is better understood as control than as independence. Any conversation that stops at ownership, data residency, or location has not reached the question that matters.

I called this silent lock-in in “Making AI Work for Britain”, with departments in mind that discover a procurement decision from three years earlier has quietly removed their ability to change course. The ASML case is the same pattern at national scale. Nobody in The Hague signed anything away. Dependency accumulated through component sourcing, software provenance, and allied pressure until the decision rights had migrated without a decision ever being taken. That is why I argued for exit-by-design as a discipline rather than a clause: if you cannot describe how you would leave, you have already lost the argument about whether you are free to.

China: the reason this stays contested

Without EUV, Chinese fabs are effectively capped around the 7 nanometre node using multipatterning on older tools, so duplicating ASML is not an industrial ambition but a national project. In December 2025, Reuters reported on a state-run effort involving Huawei that had assembled an EUV prototype in Shenzhen, partly from second-hand ASML components, with former ASML staff central to the work.

But a prototype that produces EUV light is not a machine that produces chips profitably, and the distance between the two is where Canon and Nikon died. ASML shipped pre-commercial demo tools from 2006 and did not reach commercial production until 2019. The most careful public forecast I have seen, published in June by the AI Futures Project and The Substrate, works from ASML's own history and puts commercial-scale Chinese EUV towards 2040. SemiAnalysis's Dylan Patel disagrees, predicting pre-commercial Chinese EUV by 2030. The range is wide, and the signal worth tracking is whether Chinese fabs start running domestic tools on production wafers at scale.

Why this Matters

Understanding ASML’s role is much more than a fascinating technology story. It has real consequences.

For digital leaders, the lesson here is to map the physical dependency underneath your AI roadmap. Most have mapped their model providers and cloud regions, but few have asked what happens to compute access, costs, and timelines under a serious lithography disruption.

For policymakers, the key is to stop treating AI sovereignty as a question of where the servers sit. It is a question of decision rights across a stack. Britain has no ASML and will not acquire one. Thirty years of supplier coordination cannot be conjured by a strategy document.

For regulators, remember that supervisors devote real effort to concentration risk in financial infrastructure, and the AI supply chain would fail those tests outright. The expertise this demands sits partly in export control, industrial policy, and supply chain economics, not solely in model evaluation and algorithmic accountability. The people who understand the binding constraints on AI capability are in different buildings from the people writing the rules.

Something shifted over the summer. In conversation after conversation, with boards, digital leaders, and public sector teams, I’ve noticed the questions getting harder and considerably more useful. Less "which AI tools and models should we be using" and more "where is the value for our AI investment coming from, and how would we know". After several years of experimentation, budgets are being examined properly for the first time, and a plain question is being asked out loud: what should we use AI for?

It’s the right question. However, many of the leaders asking it are starting from perspectives that were set for them by someone else (such as tool vendors, external commentators, and online influencers) and they are determining what counts as a good answer.

Two metaphors dominate current views of where AI’s value lies. The first is AI as a telescope, bringing the future into view: market movements, demand signals, and user scenarios previously too faint or too far to resolve, can now be more reliably observed. The second is AI as a microscope: deeper insight into today's problems to improve decision making and operational practices by revealing the fine structure of processes, analysing behaviours, and connecting siloed data.

Both are reasonable. Both are being oversold. And I have started to think the largest opportunity sits somewhere neither of them points, in a third framing that nobody is selling because it cannot be so easily packaged: AI as a mirror, showing an organisation to itself in a light it has not previously had.

The benefits of better optics

Let me be fair to the optics before taking them apart, because organisations clearly do suffer from limited reach and limited resolution, and better instruments are worth having.

The trouble is what the optical framing conceals. A telescope and a microscope both assume a competent observer who simply lacks equipment. The organisation is treated as a fixed, functioning thing that needs better optics bolted on. Buy the instrument, see more, decide better. Nothing about the organisation itself has to change.

That assumption deserves more scrutiny than it usually gets, and each instrument breaks in a way that tells you something important.

Telescopes show you old light. What reaches the lens left its source long ago, and everything forward-looking is inference stacked on top of a historical record. Models trained on the past are, quite literally, instruments for observing what has already happened at a considerable distance. That is useful. It is not prediction, whatever we’d all like to believe. Telescopes also look through atmosphere, and in this analogy the atmosphere is your own technical debt and dysfunctional data estate, distorting the signal before it ever reaches the optics.

Microscopes fail more subtly. They magnify the sample you have selected and prepared. Yet, process mining reveals what your systems logged, not what your people did. The gap between those two is where most of the interesting behaviour lives, and no amount of additional resolution will surface something that was never captured in the first place.

The instrument you never ordered

But a third framing offers a very different perspective: AI as a mirror.

The telescope and the microscope are instruments you choose to deploy. The mirror is a by-product you can’t avoid. Every serious AI deployment runs an unintended audit of how well an organisation understands itself, and the results arrive whether or not anyone commissioned them. Most organisations receiving those results read them as a historical technology effect and file them away.

Where "AI as a mirror" is considered, it often takes far too narrow a view, as an argument about societal bias or lack of diversity in data collection. Such important arguments have been made well by others, from Buolamwini and Gebru's audit of commercial facial analysis systems to Kate Crawford's Atlas of AI, and I am not repeating them here. What interests me is broader and, for anyone running an organisation, far more actionable: what AI reveals about institutional self-knowledge.

Start with specification. The inability to write a usable requirement is routinely diagnosed as a procurement skills gap. It is rarely that. It is the discovery that nobody ever had to articulate what a given process was actually for, because it was held together by tacit knowledge and long-serving staff. Ask a machine to do it, and the vagueness becomes visible immediately. The requirements document turns into an accidental self-portrait, and it is not usually a flattering one.

Then data readiness. "Our data isn't ready" gets reported upward as a technical finding. It is nothing of the sort. It is a decade of deferred ownership decisions surfacing at once, under a deadline, in front of a vendor. The data was never the problem. The absence of anyone accountable for it was.

Consider also what stalls pilots. In my experience, they stop scaling less often because the technology underperformed than because nobody can name who owns the decision to proceed. The NAO's 2024 review of AI in government put the same point in more measured language, warning of risks to value for money where government had not established which department held overall ownership and accountability for delivering AI adoption, nor set out who was responsible for contributing to it. The pilot holds a mirror up to the governance structure and the reflection comes back blank. That is a finding about the organisation, not about the model.

Which brings us back to where we started. Ask a leadership team what should be automated with AI and too often there is little response. That pause is not caution. It is the absence of any shared account of what the work is for. An organisation that cannot answer a question about what this work is for has no way of answering what is AI for, and no instrument will supply the missing answer.

Consider, for example, Klarna's much-discussed AI reversal. Having announced in February 2024 that its OpenAI-powered assistant was handling two-thirds of customer service chats and doing the equivalent work of 700 full-time agents, the company changed course by May 2025 and began recruiting human agents again. It reads differently through the AI mirror lens. Less a misjudgement about technology, more a company discovering it had never properly articulated what its service did for customers in the first place.

The face in the mirror

To be fair, not every disappointment with AI use is a process issue. Plenty of AI projects fail for straightforward technical reasons, and an AI mirror lens that explains everything risks explaining away real limitations in the tools.

However, the organisations getting the most out of AI do one thing differently at the outset. They treat early AI work as explicitly diagnostic rather than as deployment, and they say so in the business case for why they invested in it.

That sounds like semantics. It is not, because it changes what counts as success. If the stated deliverable of the first project is a map of where specification, ownership, and decision rights were missing, then an AI pilot that fails to scale has still returned its investment. At the very least, the organisation has bought a survey of its own foundations at a fraction of what a transformation programme would charge for the same information, and considerably more honestly.

The alternative is what I see most organisations are doing now: running the diagnostic accidentally, reading the result as technology failure, and commissioning yet another AI pilot to prove the first one wrong.

So, next time the board asks what AI is for, there is a better answer available: to tell us more about ourselves. Three questions will test whether your organisation is ready to give it. Could you write a requirements document for your most important process without asking anyone who currently carries it out? Can you name the person who owns the decision to scale your most advanced AI pilot? And when your last AI project failed to deliver the value you’d hoped, did anyone ask what it had just revealed, rather than only what had gone wrong?

The lens through which to view your AI adoption was always going to show you something. The only real choice is whether you want to look.

I’ve spent a lot of time over the past few weeks in discussions with senior leaders about accelerating AI adoption. The same exchange keeps happening. Someone sets out what they want generative AI for and focuses on the work they cannot do themselves. Write the code nobody in the team ever learned to write. Draft the contract clause they would otherwise pay a solicitor for. Digest the hundred-page report nobody has time to read. Each time, I find myself giving the same unwelcome reply.

That instinct is exactly backwards.

It is also the first of three paradoxes that explain a lot about what is currently going wrong in AI adoption. None of them is a technical problem. All three are management problems. And each one has a direct consequence for how you invest, how you train your people, and how you judge whether any of it is working.

Paradox One: AI helps you most with the things you already know how to do

The most rigorous evidence we have on this comes from a field experiment run by Harvard Business School researchers with Boston Consulting Group. Fabrizio Dell'Acqua and colleagues describe what they call a jagged technological frontier: AI assistance improves performance on some tasks and actively worsens it on others, even within the same workflow and at apparently similar levels of difficulty. The experiment was preregistered, ran with 758 consultants, around 7% of BCG's individual contributor population, and has since been published in one of the top academic journals, Organization Science.

The finding that matters for leaders is not the average uplift for the team. It is what happened at the edges. On tasks that fell outside the frontier, knowledge workers using AI performed worse than those working without it. The paper is blunt about why: users tended to over-rely on the tool, and combined human and machine performance fell precisely where closer supervision was needed.

That leads to an uncomfortable implication. The frontier is jagged, which means you cannot tell from the outside which tasks sit on which side of it. The only reliable way to know whether an AI-assisted answer is good is to already know enough to judge it. Expertise is not what AI replaces. Expertise is what makes AI safe to use.

This inverts the usual business case. Organisations tend to deploy AI where capability is thinnest, because that is where the pain is most obvious. That is precisely where it is most dangerous. So, for example, the team with no legal training is the team least equipped to spot a plausible-sounding clause that will not survive contact with a court.

An important counterpoint is that the frontier moves. Ethan Mollick, one of the paper's own co-authors, writes constantly about the ever-expanding range of what these systems can do, and models that failed a task last year may pass it now. That is true, and worth watching. But it does not help the manager deciding what to deploy this quarter, because the frontier's shape is not published anywhere. It has to be discovered locally, by people who know the work.

Paradox Two: the better the tool, the more skill you need to supervise it

This one is not new. It was set out in 1983 by Lisanne Bainbridge, then a psychologist in the Department of Psychology at University College London, in a five-page paper called Ironies of Automation. She was writing about industrial process control and aircraft flight decks, but the argument transfers to knowledge work almost without alteration.

Her point was this. When you automate most of a task, you leave the human responsible for the part that cannot be automated, which is usually the rare and difficult part. But because the human no longer performs the routine version day to day, the underlying skill decays. So, at the exact moment intervention is needed, the person best placed to intervene is least practised at it. Bainbridge's conclusion was that automation means operators need more training, not less.

Put paradox one and paradox two side by side and you have a slow-acting trap. AI works best in the hands of people who already know the work. Sustained use of AI erodes the knowledge that made those people effective. The organisation that treats AI as a substitute for building expertise will find, in three or four years, that it no longer has anyone able to tell whether the output is any good.

For enterprise-scale organisations and public sector leaders, this is the smart-buyer problem in a new guise. You cannot outsource your way to the capability you need in order to judge what you have outsourced.

Paradox Three: the productivity gains arrive last, not first

In July 1987, Robert Solow reviewed a book for the New York Times and produced a line that has outlived almost everything else he wrote for a general audience: you can see the computer age everywhere but in the productivity statistics.

We now have a decent explanation for why. Erik Brynjolfsson, Daniel Rock and Chad Syverson call it the productivity J-curve. General purpose technologies, they argue, require large complementary investments: redesigned business processes, new products and business models, retrained people, and much more. Those investments are intangible, poorly captured in the national accounts, and expensive. So measured productivity dips before it rises. The gains are real, but they are back-loaded, and they only materialise once the organisation has changed shape around the technology.

If that is right, then flat results after eighteen months of AI pilots are not evidence that AI does not work. They are evidence that you are at the bottom of the curve, where you should expect to be.

There is an obvious danger in that argument, and it is worth considering. The J-curve can be used to excuse any disappointing result indefinitely, and I have heard it used exactly that way. What stops it becoming an alibi is the second half of the claim: the gains follow the complementary investment and only follow it. So, the question to ask is not "where are the savings?" but "what have we actually redesigned?". If the honest answer is that people are using a chatbot alongside processes that have not changed in several years, you have not started the investment that produces the return, and the curve owes you nothing.

Why Your Evidence Probably is Not Evidence

There is a fourth finding that cuts across everything above, and it should make anyone relying on self-reported benefits uneasy.

The research organisation METR ran a randomised trial with experienced open-source developers working on their own codebases. Participants expected AI to speed them up by around 24%, and reported afterwards that it had made them roughly 20% faster. Instead, measured against the clock, they were about 19% slower.

That result needs careful handling. METR has since changed the design of its follow-up experiment and reported some evidence of speedup, but with confidence intervals wide enough that the direction is not settled: a point estimate of 18% faster among returning participants, on an interval running from 38% faster to 9% slower, and 4% faster among newly recruited developers, on an interval from 15% faster to 9% slower. Selection effects were part of the problem. Some developers were reluctant to take part if they might be told to work without AI, and some avoided submitting the tasks they most wanted help with. METR now describes the original finding as historical, and so should we.

What survives the revision is the gap between perception and measurement, and that gap is critical. Almost every AI business case I see rests on people telling you they feel more productive. That is not evidence. It is a feeling, and in this study the feeling pointed in the opposite direction to the stopwatch.

Three Questions You Must Address

Reviewing these paradoxes raises questions any leadership team must address.

• Where are we deploying AI into capability gaps rather than into capability strengths, and what would it take to reverse that?

• What are we doing deliberately to maintain the expertise we will need to supervise the AI systems we are deploying over the next five years?

• What is our evidence base for claimed productivity gains with AI, and would it survive rigorous analysis?

Taken together, the three paradoxes point the same way: AI rewards organisations that already understand their own work and punishes those hoping it will stand in for understanding it. The investment that matters is therefore not the tool, but the expertise needed to supervise it and the process redesign that lets any gain reach the numbers. The most important consequence is that difference between an organisation that is measuring its AI benefits and one that is merely feeling them will be obvious in about three years, and by then it will be too late to fix.

Since Monday I have been asked a version of the same question by clients, colleagues, and journalists: is scrapping the Department for Science, Innovation and Technology a disaster for British AI? My answer keeps disappointing people. The department was never the strategy. What matters is whether the new arrangement gives the centre of government the one thing DSIT never had, which is the power to make other departments buy and operate differently.

Let me be clear about the strength of the case against Andy Burnham's decision, because it is not a weak one. techUK and the Startup Coalition wrote to the incoming Prime Minister before the announcement, warning that dismantling DSIT was, in their words, "the wrong change at the wrong time". Matt Clifford, who advised Keir Starmer on AI opportunities, called it a mistake. Sarah Munby, the founding permanent secretary of DSIT, made the most substantive objection: the department's real value was in treating data, digital capability and AI as a single integrated problem rather than three separate ones. In the House of Lords, the crossbench peer Lionel Tarassenko put the cost in terms the sector understands, warning that a reorganisation of this kind takes a year and that "12 months is an eternity in AI".

Bryan Glick, editor-in-chief of Computer Weekly, has written the sharpest version of the critique, and I would encourage you to read it. His conclusion is that DSIT mattered because it existed, as a signal that government took technology seriously. That is a real argument, and I do not dismiss it. Investors, founders and international partners read structure as intent, and the signal sent this week was not a good one.

But notice what Glick's own piece concedes along the way. DSIT never functioned as a coherent department. It was poorly led. It gave up trying to recruit a chief digital officer and ended up folding the responsibility into the permanent secretary's job. At one point most of its senior digital leadership was in interim posts. A department whose defenders are reduced to arguing that its existence was the point has a problem that no machinery of government change was going to solve.

Where the Leverage Sits

The argument I have been making for two years, and the core of “Making AI Work for Britain”, is that the British state's AI problem is not visibility or ambition; it is buying power. Consolidate demand, diversify supply. Behave like a smart buyer rather than a grateful one. Design every contract for exit before you sign it. Become an intelligent user of AI.

None of that was ever within DSIT's remit. A mid-weight sponsor department can convene, publish, and cheer. It cannot tell the Ministry of Justice how to run a procurement, and it cannot make the Treasury attach conditions to a spending settlement. Demand consolidation is a Cabinet Office and Treasury function, or it is nothing at all.

Which is why my reaction to the detail of this week's changes is more complicated than the consensus. Responsibility for AI strategy, public sector AI adoption and the AI Security Institute is moving into the Cabinet Office, supported by a new AI taskforce and a prime ministerial adviser. Kanishka Narayan attends Cabinet as AI minister. Reported in isolation, that is the centre taking ownership of exactly the functions that need central authority. Baroness Anderson, responding for the government in the Lords, argued that science and technology should not sit in an isolated department but be embedded across Whitehall. On the narrow question of AI adoption, she is right, and the sector should be careful about arguing otherwise simply because it dislikes the messenger.

The genuinely damaging decision is a different one, and it has attracted less attention than it deserves. The Government Digital Service is going to the Department for Digital, Culture, Media and Sport, separated from the AI adoption agenda now sitting in the Cabinet Office. Raoul Ruparel of the BCG Centre for Growth called this strange, and that is generous. GDS is the closest thing Britain has to a working model of consolidated demand: common platforms, shared standards, a spend control that made departments justify duplication. Detaching that machinery from the AI programme, and parking it in a department with no historic grip on Whitehall spending, removes the delivery arm from the strategy at the precise moment the strategy claims to be about delivery.

Three Tests We Must Apply

So rather than argue about the org chart, I would judge this government against three questions over the next six months.

First, does the centre control the money? An AI taskforce with no authority over spend controls or Crown Commercial Service frameworks is a convening body with a new letterhead. If the Cabinet Office is serious, we will see AI conditions attached to departmental spending settlements.

Second, who now owns supply diversification? With sector sponsorship in the business department and buying power in the Cabinet Office, market shaping has no obvious home. The £500m Sovereign AI Fund already has governance split across two departments. Left unowned, the default outcome is a narrower supplier base dominated by three American hyperscalers, and nobody will have decided it.

Third, what gets signed while the furniture is being moved? This is the point I would most want a minister to answer. Reorganisations do not pause procurement. Contracts signed during an 18-month transition, when nobody is quite sure who approves what, will still be running in 2032. Silent lock-in does not wait for a machinery of government exercise to conclude, and exit-by-design is not a clause you can add retrospectively.

Where to Watch

The tech sector's response this week has been about status, job roles, and responsibilities. That is understandable and largely justified, but it is also the argument least likely to change anything, and it hands the government an easy reply about not seeing technology as an isolated issue.

The first Burnham Budget is expected between mid-October and late November. That, rather than the departmental map, is where we will find out whether AI has been elevated or quietly pushed into the long grass. If the Budget contains conditions on how departments buy AI, a named accountable owner for public sector adoption, and money attached to a published delivery record, then the centralisation was real. If it contains a restated ambition and another growth zone, we will know that AI got a chair at the Cabinet table and very little else.

A minister without a department needs a published mandate, a named senior official accountable for delivery, and a public record against which progress can be judged. Those are reasonable things to ask for, and asking for them is more useful than mourning a department that was not working. Britain has now restructured its AI machinery twice in three years without once rethinking what the strategy is actually for. The boxes have moved. The buying has not.

So, the broader question that arises is a practical one. If you sell to government, or buy on its behalf, or advise anyone who does: who is signing your next AI contract, and do they know yet who they report to? If the answer is unclear, that is not a Whitehall problem. It is your commercial risk, and it starts now.

Three signals arrived within the last few days that together they tell a specific story about AI's economic impact. On Monday, more than 200 leading economists, including 16 Nobel laureates, released a public statement at wemustactnow.ai urging action on AI's economic transformation. On Tuesday, IBM lost roughly a quarter of its market value in a single session, its worst day on record since at least 1968, on evidence that AI is already reshaping enterprise IT in ways nobody had forecast. And in the background, The Economist's June piece "Meet the world's top AI-pilled economists" carries a chart showing that the leading economists in this field cannot agree on how transformative AI actually will be.

Taken together, these three signals tell a story. It is not the one the loudest of them thinks it is telling.

The Letter That Plays it Safe

The statement, organised by Erik Brynjolfsson (Stanford), Ajay Agrawal (Rotman, University of Toronto), Anton Korinek (University of Virginia and Anthropic) and Tom Cunningham (METR) through the Stanford Digital Economy Lab, contains just three propositions. First, that AI may become radically more powerful over the next ten years. Second that this could drive a transformation larger than the Industrial Revolution over a much shorter time frame. And third, that economists, policymakers and technology leaders must act now to understand transformative AI and to build the incentives, guardrails and institutions to steer it. That is the whole content of the statement.

Read the signatory list carefully and the reason for the hedging becomes obvious. The letter is signed by economists who, in the wider literature, disagree bitterly about how transformative AI will actually be. A statement that both ends of that intellectual spectrum can sign is, by construction, a statement saying very little. The letter was a chance to move the debate forward. It settled for asking that the debate continue.

The Disagreement is the Finding

The Economist's "Rogues' Gallery" chart, published as part of its June article on where AI economics is being done, is more informative than the letter that has followed it. The chart shows leading economists spread across the full range from "least transformative" to "most", with signatories to this week's statement sitting at both extremes: Erik Brynjolfsson (Stanford) among the most bullish, Daron Acemoglu (MIT) at the least bullish end of the scale, and Simon Johnson (MIT) close to him. That spread is not a failure of the profession. It is the actual result of the past three years of serious empirical work: the economics of AI is quite openly unresolved.

The uncomfortable conclusion is that waiting for economists to reach consensus before acting on AI policy is a serious error. The consensus is not coming. Anyone in a position to make decisions today, in a government department, a regulator, or a boardroom, needs a strategy that is robust to the disagreement rather than one that depends on the disagreement being settled first.

Meanwhile, Back on Earth

While the theorists argue, the transformation is already visible in the numbers. Arvind Krishna, IBM's chief executive, attributed the company's Q2 shortfall to clients redirecting their capital spending in the final weeks of June away from IBM's software and mainframe business and towards AI-related infrastructure: servers, storage and memory. Peers including ServiceNow, Salesforce and Accenture fell in sympathy. Full results are due on 22^nd July, but the pattern is already clear enough for the market to have re-priced.

This is not the "AI will replace jobs" narrative the letter points at. It is a different narrative, and arguably a more immediate one: AI is restructuring how enterprises allocate capital, where value accrues within the technology supply chain, and which providers get squeezed. It is happening now, in observable ways, and it does not require anyone to settle the “transformativeness” question before it accelerates further.

What "Acting Now" Should Mean

If the letter is right that this moment demands action but wrong about what to say, the useful question is what a substantive response looks like. My argument in Making AI Work for Britain is that the UK does not need to resolve the macro debate to act well. Four moves hold regardless of whether AI's eventual impact turns out to be modest or transformative.

Consolidate demand. The Government Digital Service model showed how public-sector buying can be coordinated so that departments are not each picked off individually by vendors. That discipline matters more, not less, when supply is genuinely constrained. The IBM story is evidence that AI-related infrastructure is now such a constraint, and coordinated buying is how a mid-sized economy retains any leverage over the resulting market.

Diversify supply and design for exit. If enterprises are already reshuffling providers under AI pressure, silent lock-in becomes an active risk, not a theoretical one. Exit-by-design should be treated as a procurement discipline, embedded in contracts and architectures from the start, rather than as an aspiration invoked when things go wrong.

Build the smart-buyer capability. Open uncertainty about outcomes is precisely the reason to invest in institutional capacity to procure, evaluate and govern AI. The buyers who cannot do this will be the ones for whom the economists' disagreement ends up being most expensive.

Escape pilot purgatory. While the debate goes on, real projects stall at proof-of-concept because no organisation has built the delivery pipeline that would move them into production. Every month of delay compounds, both in unrealised benefit and in accumulated technical debt.

Where the Letter Leaves Ss

The signatories are right that this is a moment for action. Such an open letter can be useful to galvanise action. Where they fall short is in supplying the content. UK AI Watch, the RAG-rated tracker I established alongside the book, records the current UK baseline against the 25 recommendations: 0 green, 12 amber, 13 red. That is one attempt to say what "acting now" actually means in specifics rather than in sentiment. Others are welcome to disagree with the recommendations. What is not helpful is a statement that lets everyone feel virtuous while committing to nothing.

Ask most senior leaders what they mean when they talk about artificial intelligence, and you will most often get an answer about capability. Larger models. Better reasoning. More automation. Faster answers. The conversation almost always fixes on what the technology can do.

That framing is not wrong. But it misses a more important question: where does the intelligence sit once a technology like this is loose in an organisation? The answer to that question has changed profoundly in recent years, and most enterprise AI strategies have not yet caught up.

From products, to services, to outcomes

For most of the last century, businesses thought of themselves as producers of things. Value was manufactured, packaged, and shipped. The customer's role was to buy, use, and eventually replace. The intelligence, such as it was, sat inside the product itself: in its design, its features, its engineering.

The shift to services complicated this picture. Value was no longer just in the artefact but in the ongoing relationship. Cars became transport contracts. Software became subscriptions. Elevators became lifecycle service agreements with predictive maintenance built in. The intelligence shifted into the service delivery model: the workflows, the SLAs, the support functions that made the relationship work.

Then came platforms and access-based models. Instead of owning a service, customers gained the ability to draw on capability when they needed it. The intelligence appeared to move again, this time into the infrastructure that allowed access at scale.

More recently, the frame has shifted once more, this time toward outcomes. Increasingly, buyers do not want a product, a service, or even access. They want the result: the diagnosis, the decision, the completed task. That shift changes almost everything about where the intelligence needs to sit as we seek to deliver greater value from AI.

What Vargo and Lusch saw twenty years ago

The intellectual scaffolding for this shift is older than most enterprise AI conversations. In 2004, Stephen Vargo and Robert Lusch published a paper in the Journal of Marketing titled "Evolving to a New Dominant Logic for Marketing"" that reframed how we should think about value creation. They called their framework service-dominant logic, or S-D logic, and its central claim was quietly radical.

Value, they argued, is not embedded in things. It is co-created between provider and user within the specific context in which a product or service is put to use. A car sitting in a showroom has no value. The same car in the hands of a driver, on a road, going somewhere that matters, is where value comes into existence. The provider offers a value proposition. The user, applying their own knowledge, context, and needs, completes the act of value creation.

This idea has been developed by a wide community of scholars over the past two decades and echoed in adjacent work. Prahalad and Ramaswamy's paper "Co-creation Experiences: The next practice in value creation" argued that the interaction between firm and consumer is becoming the centre of value creation. Earlier still, Normann and Ramírez had made the case in "From Value Chain to Value Constellation" that successful companies do not simply add value but reconfigure the relationships among suppliers, partners, and customers so that value can be produced together. The common thread across all three is consistent. Value is not delivered. It is produced together, in use.

Why this matters for AI

If value is co-created, then intelligence cannot sit purely in the product or be wrapped around a service. A large language model, however capable, is inert until it is used in a specific context by a specific person trying to do a specific job. It cannot know, by itself, what a good answer looks like for this user, in this moment, for this purpose.

Intelligence also cannot sit purely in the service delivery mechanism. Wrapping a model in a chatbot interface, or plumbing it into a workflow, does not by itself produce a useful outcome. The chatbot that answers everything competently and nothing well is now a familiar feature of enterprise pilots.

Nor does it sit purely in the AI infrastructure. Compute, data pipelines, and model registries are necessary but not sufficient. Plenty of well-provisioned organisations have deployed impressive stacks and produced disappointing results.

Even the accumulated experience of the organisation providing the service is not quite the right answer. Organisational knowledge matters, but it is a resource brought to the interaction, not the interaction itself.

The intelligence, in any serious sense, lives in the interaction. Most people, when they hear that, translate it as “workflow”. That is understandable. Workflow is the familiar language of enterprise IT: define the steps, plug in the tool, measure the throughput, iterate on the process. It is also the operating assumption of most enterprise AI programmes, which treat the workflow as the unit to be redesigned around a model, a copilot, or an agent.

But workflow and interaction are not the same thing, and the difference matters. A workflow is the designed sequence of steps that describes how a process is meant to run. An interaction is what actually happens when a user, an organisation, and an AI system meet in a specific moment to produce a specific outcome. Two organisations can run an identical workflow and get very different results, because the interactions inside it play out differently, on different data, with different users, under different pressures. The workflow is the script. The interaction is the performance.

Design at the level of the workflow, and you optimise the sequence while hoping the interactions inside it are good enough. Design at the level of the interaction, and the workflow becomes a consequence of what you learn from thousands of specific exchanges. It is the interaction that brings together a user's context and intent, an organisation's capability and knowledge, and an AI system's models and data to produce something useful. That choreography is where the value is created. It is also where the intelligence has to be designed, governed, and improved.

From doing AI to being AI

This is why so many enterprise AI programmes stall in what I have called pilot purgatory. Organisations approach adoption as if they are installing a product or standing up a service. They procure the technology, define the workflow, train the users, and wait for the value to arrive. It rarely does, because the model of value they are working from is the wrong one.

The organisations that are making genuine progress are doing something different. They treat intelligence as an interactional property. They invest heavily in the mechanisms that capture what happens when users engage with AI, govern how that engagement takes place, support the user in getting the most from the system, and enhance the system based on what is learned. They build feedback loops as first-class infrastructure. They treat the interaction, rather than the model, as the product.

That is the shift from doing AI to being AI. Doing AI is a project, an initiative, a line on a transformation roadmap. Being AI is a change in how the organisation understands where its value comes from, and what it takes to sustain that value in an era of co-created outcomes.

There is a reasonable objection here. Not every AI application needs to be understood this way. A spam filter, a fraud-detection model, or a defect classifier can reasonably be thought of as a product feature that either works or does not. Fair enough. But the frontier of enterprise AI adoption today is precisely in the domains where the objection breaks down: knowledge work, judgement, customer relationships, decisions with context. Those are the domains where co-created intelligence is not a metaphor. It is the operating model.

Questions worth asking

If any of this resonates, three questions are worth discussing with your senior team.

First, when you look at your current AI initiatives, where does your organisation assume the intelligence sits? In the model? In the process? In the platform? What follows from that assumption, and is it still the right one?

Second, what mechanisms do you have in place to capture, govern, and learn from the actual interactions between your users, your systems, and your customers? Are these first-class investments, or afterthoughts wired in once the pilot has already launched?

Third, if value is genuinely co-created in the moment of use, what does that mean for how you measure success, and for how you distribute the returns between provider, user, and the wider system in which both operate?

The organisations that answer these questions well are the ones that will move beyond the pilot phase. The rest will keep buying technology and wondering why the results keep disappointing.

After a long wait, the Defence Investment Plan finally arrived this week. Was it worth the wait?

That question has two answers. The obvious one is a defence answer, and most of the coverage so far has focused there. The more interesting one, that I want to address, is what the DIP tells us about the state of AI development and adoption in the UK. Not the marketing version. The commitments-on-paper-with-money-behind-them version.

Read that way, the plan offers a mixed picture.

Most of the coverage is treating the DIP as a platforms story. Frigates. Jets. Nuclear powered submarines. Tanks. More than 80 pages of them. The International Institute for Strategic Studies (IISS), a major defence think tank, walks through the plan service by service, weighing which programmes have survived intact and which platforms have been sacrificed.

Yet, for me, the more important story is the digital layer underneath. And that layer is where the plan discusses how important it is that the UK has a "sovereign" approach, but never actually lets you know what it means. That should be a cause for concern.

First the Good News

The institutional design in this plan is comprehensive and clear.

The National Armaments Director Group has been led by Rupert Pearce since October 2025. It is the closest thing UK defence has produced to a GDS-like redesign of the defence operating model for the digital age. It merges seventeen organisations into four. It gives UK Defence Innovation a ring-fenced £400 million a year. It has six Commercial Pathways and a Segmented Acquisition Model. It claims it will generate £10 billion of savings over the decade, all to be reinvested into defence. It commits MOD to a first delivery report to Parliament by July 2027.

Seen from my “Making AI Work for Britain” viewpoint, this is a real attempt to move to a more agile delivery model underpinned by a “consolidate demand and diversify supply” philosophy. It has the shape of something that could work. The first real test is the major review in July 2027. I’ll certainly be watching that date.

But institutional design is only half the story. Underneath it sits an architecture question the plan must answer to deliver on the promises. It is focused on a “sovereign” approach for the UK. Yet, what that means is far from clear.

Three Ways the DIP Uses 'Sovereign'

So, what does the DIP mean when it talks about a sovereign approach to defence? At least three different things.

First, with respect to the nuclear enterprise, including warheads, submarines, reactor cores, fuels, and so on. The DIP identifies £63.6 billion in spending aimed at developing UK-based capabilities as required.

Second, in the industrial language with a mantra to "Buy British by default." It mentions a forthcoming definition of a British company and “Five Defence Growth Deals” across Plymouth, South Yorkshire, Scotland, Wales and Northern Ireland. These are real intentions with important outcomes for the UK, especially regarding jobs, skills, and the defence industry’s role in the broader UK economy.

Third, in the digital and AI layer. This is where things become much more hazy. It looks as if "sovereign" is being used as a slogan draped over decisions that have not been made.

The Decisions No One is Naming

Three components sit at the centre of the UK's future defence infrastructure. The Digital Backbone is the connectivity and data infrastructure that everything else runs on. The Digital Targeting Web is the kill chain: the system that links sensors, decision-makers and weapons so a target can be identified and struck faster than the adversary can respond. Underneath both sits a Defence-wide Secret Cloud, promised as a minimum viable product “later in 2026”.

Together these deliver the essential plumbing that turns individual platforms into a networked fighting force. The DIP announces that the Digital Backbone gets £5.5 billion over four years. The Digital Targeting Web gets £1.8 billion. Both are described in the DIP as underpinned by "world leading AI and software".

However, the DIP does not name the provider. It does not set the architecture principles. It does not describe the exit terms. It does not commit to sovereign compute floors. It defers the Defence Strategic Approach to AI, and the frameworks for Dependable AI and Responsible Use of AI, to future publication.

That's a critical £7.3 billion decision. It underpins almost every AI-branded programme in the plan. It will be finalised later this year. The terms are undefined at publication.

Now compare the AI-branded programmes. Taskforce RAID: £100 million over four years. Project FRONTIER: £100 million. Land AI C2: £80 million. AI for underwater dominance: £20 million. Total named AI investment: about £300 million.

The architecture layer is more than twenty times the size of the AI-branded layer. And it is where every meaningful sovereignty question lives.

 Why This Matters

Understanding the details of these decisions will determine the sovereign nature of the UK’s defence infrastructure. If the Secret Cloud is a hyperscaler tenancy, that may be defensible on grounds of speed. But it is not sovereign. And it needs an exit strategy from day one.

If Project FRONTIER's compute sits in commercial data centres on someone else's chips, that may be defensible on grounds of capability. But the £400 million sovereign chip procurement announced in June needs to connect to it explicitly.

If the model layer for the Digital Targeting Web is a fine-tuned foundation model from a US provider, that may be defensible on grounds of performance. But the evaluation, red-teaming, dependency mapping and switching costs need to be visible to Parliament before the contract. Not after.

None of these choices is wrong. All of them can deliver capability faster than building sovereign alternatives. The point is not that MOD should build everything itself.

The point is that "sovereign" in the DIP's digital chapters is doing work that "smart-buyer" ought to be doing. The two are not the same. Consolidating demand, diversifying supply, and buying with exit-by-design terms. That is what makes a customer sovereign in a market it does not own. It should be explicit and clear in the DIP. It is not.

Key Questions to Address

Seen through this lens, five important questions must be answered in the spirit of the smart-buyer model.

1. Who provides the Defence-wide Secret Cloud? Under what terms? What are the exit conditions?

2. What is Project FRONTIER's compute strategy? How does it connect to the £400 million sovereign chip procurement announced in June?

3. Where does the model layer for the Digital Targeting Web come from? How is it evaluated? What happens when the supplier changes its pricing, its terms or its model?

4. What are the acquisition standards for Dependable AI and Responsible Use of AI? When are the frameworks published?

5. How do the Defence Growth Deals connect to the compute geography, so that "Place" as a growth-lens criterion is more than a paragraph?

These are answerable questions. They are also the ones most likely to go unasked. Political attention will go to platforms. Technical attention will go to programmes. The architecture layer sits between the two. And it is where the sovereignty of the whole plan is either quietly established or quietly given away.

When AI regulation comes up in a room full of digital leaders, it tends to get discussed like the weather. Something that happens to you. You forecast it, you grumble about it, but there’s little you can do besides carry an umbrella or a sun hat. The unspoken model is that regulation is a brake, your job is to make progress despite it, and the best you can hope for is that the brake is applied gently.

I want to argue that this thinking is dangerously upside down. The competence of the people governing AI is one of the largest single influences on whether your own AI adoption moves quickly, and on whether you can deliver meaningful value to your customers.

I do not come to this as a neutral observer. Over the years, I have worked in a number of countries advising a variety of regulatory bodies, and I have played a role in interpreting and applying those regulations with several large organizations in the public and private sectors. So, I carry the scars. The good ones were never the obstacle. They made the work possible by creating shared frameworks to understand technology risks and rewards, and by setting expectations we could plan around, and by holding public confidence that no single organisation can build on its own. But that wasn’t always the case, and much of my time has been spent figuring out the difference.

Weak regulators, not strong rules, are the real brake

Let’s start with the obvious. Regulators can slow adoption. But the mechanism is the opposite of the one most people assume. It is a weak understanding, far more than strict rules, that does the damage.

An under-equipped regulator tends to fail in one of two directions. The first is that it freezes. Unsure what good looks like, it hedges its bets and over emphasises protecting against every possible risk, and that hedging reaches the market as uncertainty. Uncertainty is precisely the thing that keeps promising projects stuck in pilot purgatory and gives finance directors a reason to defer the spend for another year. Facing backlash from stakeholders for “stalling innovation, the second is that it waves things through without governing the risk, until something goes wrong in public. Then comes a second backlash, and with it a clampdown heavier and clumsier than careful rules would ever have produced. Either way, thin understanding makes adoption both slower and worse.

What I’ve seen in practice is that a capable regulator does the reverse. Because it can tell a real risk from a hypothetical one, it identifies meaningful priorities and offers clear rules that businesses are able to plan around to allow investment to flow. Just as important, it protects the one ingredient no product plan can manufacture on its own: public trust.

Here the evidence is blunt. In the 2025 Ada Lovelace Institute and Alan Turing Institute survey, a nationally representative study of more than three thousand people, 72% of the UK public said laws and regulations would make them more comfortable with AI, up from 62% two years earlier.

Read that again, because it cuts against the instinct that the public simply wants AI held back. People are not asking to be shielded from the technology so much as asking for help to establish guardrails for the conditions under which they would accept it. The same survey found that only 18% knew AI was already being used to assess welfare benefits, even though most had heard of driverless cars. This means that the AI use cases that touch people most directly are the least understood, which is exactly the ground in which a backlash takes root.

Trust, then, is not a courtesy added at the end of a project. It is infrastructure, in the way that roads are. The much-discussed AI trust deficit turns out, on inspection, to be as much an adoption problem as an ethics issue.

What policy makers need to know

So, the question “what do policymakers and regulators actually need to understand about AI” is far from academic. It is a direct input to an organization’s delivery timelines. And the answer is more reachable than the common myths suggest. It is not the mathematics. It is enough to ask the right questions, weigh the answers, and recognise when something does not add up.

In the work I have been carrying out with policymakers, I have found it useful to come back to three plain questions about any AI system. Is it responsible: governed, accountable, and fair? Is it robust: secure, reliable, and able to fail safely? Is it responsive: able to adapt as the world keeps moving? A regulator who can hold those three in mind can have a useful conversation with a vendor. One who cannot will either rubber-stamp or freeze, and we have just seen where both of those can lead.

The lesson behind this is hard-won and not new. What I have seen work best in the UK public sector is when that capability lives inside the state rather than being rented by the day from consultancies. The same principle applies now. A smart buyer can specify what it wants, judge what it is offered, and walk away from a bad deal. A body that has outsourced its understanding can do none of those things and ends up governing AI through press release and reaction. Capability is not a nice-to-have extra alongside the regulation or statute. It is the thing that makes it work at all.

The honest objection is that building this capability is slow and expensive, and that the technology will outrun any team you assemble. There is truth in that. But the alternative, governing by reaction, is slower and more expensive still. It simply arrives on a delay, often with a scandal attached.

Why this is your problem, not just theirs

In this regard, the UK is in an interesting position. Rather than write detailed AI law, as the EU has, or leave the question largely to the market, as the United States tends to, the UK government asks existing regulators to apply shared principles in their own areas. That is a defensible approach. But it only pays off if those regulators are genuinely equipped, and there are signs the gap is real. The long-promised AI legislation has yet to arrive, even as public demand for it climbs. The danger here is not over-regulation. It is a vacuum, filled eventually by a reactive clampdown that serves no one.

Where does this leave us? If you lead digital change in a company, a hospital, or a council, you have a stake in the state being good at this, not merely a grievance about it being in your way. A capable regulator is often the difference between your next AI project scaling and your next AI project becoming a cautionary tale. That is worth more than forecasting the weather and complaining about it. It is worth engaging with by responding to consultations, sharing what you are learning, lending good people to the institutions that need them, and being straight in public about both the value and the risks.

The real question, in other words, is not "how should we regulate AI". It is "how AI-capable is the state doing the regulating, governance, and auditing”, and that is a question about investment in people and institutions as much as about law. Consider the implications of this. In your own sector, is the body that oversees you equipped to tell a good AI system from a dangerous one? And if it is not, what would it take to change that, and what part might you play in closing the gap?

In a recent conversation with a group of senior business leaders, one of them asked me whether the UK needs its own AI bill. When I told them that was the wrong question, my answer caused a stir. Let me explain.

The instinct behind the question is a fair one. AI is moving fast, the headlines swing between miracle and menace, and it feels as though someone in authority ought to be writing the rules. So people are often surprised to learn that Britain has no AI law at all, and that the government has spent two years promising one without delivering it.

Back in 2024, ministers pledged to bring in binding regulations on the handful of companies building the most powerful AI models. That law has not appeared. What did appear, in this year's King's Speech, was a Regulating for Growth Bill, and despite the AI billing, it points the other way. Its purpose is to reduce the burden of regulation, not to add to it. The government is so conscious of how that reads that the official briefing notes stop to insist the bill "is not about deregulation." When a government tells you what its law is not, it is worth asking what it is.

In plain terms, the bill tells regulators to put growth first and gives them powers to suspend their own rules for a while so that businesses can test new ideas under controlled conditions, a so-called sandbox. AI is mentioned, but as one example among several that also includes new medicines, self-driving ships, and defence equipment. The tougher promises from 2024, regulating the most powerful models and banning sexually explicit deepfakes, are nowhere in it. Where AI harms are being tackled, it tends to happen quietly, through small changes to laws we already have, rather than through anything you could point to and call Britain's AI Act.

This is the gap that has reopened an old argument: a government that promised to regulate AI has instead produced a bill designed to deregulate. Each side has a serious case, as I acknowledged to the leaders who put the question to me. But the argument between them rests on a shared assumption that I think is mistaken.

Two Camps, One Nation

One camp wants a bill and is willing to accept some delay to get it. Its case is about protection: guarding people from real harms, building public trust, and ensuring that access to AI is fair rather than concentrated in the hands of a few firms and a few regions. From this view, the steady drift of substantive rules into the margins of other legislation is no substitute for a coherent framework, and the Centre for Long-Term Resilience was right to call the continued absence of frontier-AI legislation a missed opportunity for a country that once hosted the world's first AI Safety Summit.

The other camp wants speed and sees delay as the danger rather than the safeguard. The government's own figures give this case its sharpest edge: nearly a third of UK AI start-up leaders are considering relocating overseas because of regulatory complexity and capital constraints, and AI contributed an estimated £11.8 billion to GDP last year. From this view, every month spent drafting a comprehensive rulebook is a month ceding ground to the United States, China, Singapore, and others. All of which are moving faster than we are. Better a light touch and a sandbox than a European-style Act that arrives late and increases the administrative burden.

Both camps are arguing in good faith. But both, I believe, are arguing about the wrong thing.

The Proxy Problem

The presence or absence of a statute has become a proxy. For one side it stands for whether AI is being handled responsibly. For the other it stands for whether Britain is open for business. Each is optimising the visible signal rather than the thing the signal is meant to represent, which is AI that is safe to use and actually gets used, on terms Britain controls.

I wrote recently about tokenmaxxing, the habit of treating AI token consumption as a measure of productivity, and how it runs straight into Goodhart's Law: once a measure becomes a target, it stops measuring anything. The AI Bill debate has the same problem. We have started keeping score on the legislation itself, as though passing or blocking it were the outcome, when it is at best a channel and at worst a distraction.

Look at what is actually happening, and the proxy gives way. The protection camp's genuine wins are arriving anyway, through amendments to laws we already have, which rather undermines the claim that only a single grand Act can keep people safe. And the growth camp's own diagnosis undercuts the case for a deregulatory sprint. The binding constraint on AI adoption that businesses keep naming is not red tape. It is the cost of energy, the shortage of skills, and the difficulty of moving a promising pilot into dependable operation. A comprehensive AI Act would have over served a safety question that is already being handled in pieces, while under serving an adoption problem that was never really about rules.

The Question That Matters

So, the question worth asking is not whether Britain legislates, but what any legislation would have to do to make AI work here. In my book, Making AI Work for Britain, I argue that the levers that decide the outcome are four: consolidate fragmented public demand so the state buys as one informed customer rather than a thousand uncoordinated ones; diversify supply so we are not captive to a handful of providers; design every deployment so we can exit it; and treat sovereignty as a default rather than an afterthought.

Judged against that test, the Regulating for Growth Bill is close to silent. It loosens supply-side friction and touches none of the structural questions. Worse, a sandbox that lowers the barrier to adopting whatever is cheapest and most readily available could deepen the silent lock-in I warn about, because nothing in it diversifies who Britain buys from or preserves the freedom to switch later. Speed without an exit is not agility. It is a faster route into dependence.

There is a sharper way to put this. The strongest protection against AI harm and the strongest engine of AI growth turn out to be the same thing: domestic capability and the freedom to walk away from a supplier. A country that can build, buy, and switch on its own terms does not have to choose between being safe and being fast, because it is not negotiating from weakness in either direction. A bill that delivered that capability would satisfy both camps at once. A bill that merely relaxes rules in a sandbox satisfies neither for long.

For those of us advising boards and public bodies, the implication is uncomfortable but clarifying. Do not organise your AI strategy around the fate of a bill that, whichever way it goes, will not change your exposure by much. Build the smart-buyer capability now. Know what you are deploying, on whose infrastructure it runs, what it would cost to leave, and whether you could. That work is entirely within your gift, and it is the work that a future Act, if it is any good, will eventually try to make you do.

Which brings me to the question I would put to anyone still keeping score on the AI Bill. Before either camp celebrates its passage or mourns its absence, ask this: what would a bill actually have to contain before it changed your organisation's exposure to AI by a single degree? If you cannot answer that, then the bill was never the thing that mattered, and the work that does matter is already waiting for you.

When I started as a software developer more than thirty years ago, the numbers that were supposed to matter were lines of code, test coverage, defect density, and code churn. Each was meant to capture something real about the quality of the work and the productivity of the person producing it. What’s more, they had the great merit of being easily countable.

What became clear before long, though, was that they correlated poorly with the only question that truly mattered: Was any of this improving the experience of the people who actually had to use the software I was building? I have found myself thinking about those early measures a great deal lately, because we appear to be in danger of making the same measurement mistakes with AI.

Over the past few months, the surest status symbol in Silicon Valley was not your title or your stock grant. It was how many AI tokens you burned last month. Engineers compared their monthly token counts the way a previous generation compared lines of code or defects fixed. Some firms built internal leaderboards to crown the heaviest users, and a few began treating "token budgets" as a form of compensation. The practice acquired a name, borrowed from the internet: tokenmaxxing. The premise was simple. The more AI you consume, the more productive you must be.

Rather than just dismissing this, I want to take this seriously, because the joke and the warning are the same thing. Tokenmaxxing looks like a curiosity from the engineering fringe. It is in fact, a near perfect illustration of the question hanging over every boardroom this year: Are we actually getting a return on what we spend on AI, or have we simply found a more sophisticated way to mistake activity for value?

When the meter becomes the scoreboard

A token is the basic unit an AI model reads and writes, and every provider meters it because metering is how they bill their users. That makes tokens one of the few things in an AI workflow that can be counted precisely. And there lies the trap.

Goodhart's Law, named for the economist Charles Goodhart, holds that when a measure becomes a target, it stops being a good measure. Token consumption is an input. It tells you how hard the machine worked, not whether the work was any good, whether it survived review, or whether a customer was better served at the end of it. The moment that input becomes a scoreboard, people optimise the scoreboard. They run agents in parallel, pad their prompts, and automate consumption for its own sake. The number goes up. Whether anything of value was produced is a separate question that the metric was never designed to answer.

This is precisely the trap those early code metrics fell into. Lines of code and churn were easy to tally and reassuring to report, yet a developer could push every one of them in the right (or wrong) direction while shipping software that was slower, more brittle, and harder for anyone to use. Tokenmaxxing is that same confusion reborn in a faster and far more expensive form. The meter is more precise than ever, which only strengthens the temptation to mistake it for value.

What the meter is hiding

This matters now because patience with AI is beginning to run out. After several years of experimentation, boards and investors have shifted from asking what AI might do to demanding details of what it has actually returned. The pressure is real, and it is documented: in one large survey, around three in five senior leaders said they felt more pressure to prove a return on AI than they had a year earlier. Research from MIT's NANDA initiative, in its study of AI in business, found that roughly 95% of enterprise GenAI pilots had produced no measurable P&L impact. Similarly, Forrester's analysts have noted that only a small minority of decision-makers can point to a real earnings lift, and fewer than a third can tie AI spending to a change in the bottom line.

The phrase doing the rounds is "AI sticker shock": The ballooning bill arrives long before the proven benefit. The correction is already underway. By late spring, Microsoft had cancelled internal AI coding subscriptions in several divisions over cost, Meta had quietly removed its tokenmaxxing leaderboard, and Uber had admitted to burning through its entire annual token budget in the first four months of the year. The unease is not confined to finance directors, eithe. A Nature Machine Intelligence editorial recently urged firms to stop tokenmaxxing and deploy AI sensibly instead.

Set the two trends side by side and the absurdity becomes clear. At the precise moment finance directors are demanding to see returns, the culture has produced a metric that rewards inflating the cost. ROI is a fraction. Value over spend. Tokenmaxxing optimises the denominator in the wrong direction and calls the result success. It is the ROI crisis in miniature, lived out one leaderboard at a time.

In fairness, there is a serious counter-argument to be considered. Nvidia's Jensen Huang has reportedly said he expects a top engineer to get through around $250,000 of tokens a month, and the optimistic reading is that the returns on this investment are a timing problem rather than an absence. From this perspective, the genuinely valuable agentic workflows are still being built, the heavy consumption today is the necessary investment, and the P&L impact will follow once those systems mature. That may prove partly true. But it is an argument for patient, governed investment with a clear value hypothesis attached. It is not an argument for a leaderboard. The honest version measures what the spending has changed. The vanity version simply measures the spending.

Why Britain should be watching

For a UK audience there is a further dimension. When token consumption becomes the badge of being serious about AI, that consumption flows overwhelmingly to a small number of providers, almost all of them American.

The dependence is not hypothetical: the US "Big Three" of AWS, Microsoft Azure and Google Cloud already supply cloud services to more than 90% of UK public sector organisations, and the AI layer is being built on top of exactly that base. Every token burned for show, rather than for value, is a small transfer of money and capability offshore. The ROI question is usually framed as a corporate one, a matter for a single company's accounts. At national scale it is also a question of sovereignty and of the balance of payments. Uncontrolled, status-driven demand is the opposite of what I have argued we need, which is to consolidate demand so that we understand and shape it, and to diversify supply so that we are never captive to a single meter.

Sovereignty by default does not mean spending less on AI. It means refusing to let spend become a proxy for progress, and insisting that demand is governed, routed intelligently, and spread across meaningful alternatives. A smart buyer asks a different question from the tokenmaxxer. Not "how much did we use", but "what changed, and what did it cost per outcome we actually accepted". That single shift, from input to outcome, is the whole of the argument.

What matters now

So, before the next dashboard lands on your desk, three questions worth asking of your own organisation.

First, where are you already counting activity and quietly hoping it stands in for value? Second, if you replaced "tokens consumed" or "tools adopted" with "cost per accepted outcome", which of your AI initiatives would still look like a success? And third, for those of us thinking about the country and not only the company: if AI spend is becoming a measure of ambition, who exactly is on the receiving end of it, and what are we building here at home in return?

The meter will keep running either way. The only choice is whether we let it tell us a flattering story or insist that it earns its keep.

A government select committee report is not the kind of document most people read for pleasure. It is the kind you read because something in it matters. So, I’ll admit to a particular satisfaction in finding my own argument quoted back at me from the House of Commons, in the Science, Innovation and Technology Committee's first report of this session, Rewiring the state: Delivering digital government, published on 3rd June.

For readers outside the UK, a Commons select committee is a cross-party group of MPs that scrutinises a government department and takes evidence from witnesses before publishing its findings. Its recommendations carry real political weight but no legal force, and the government is obliged to respond, usually within sixty days.

In the chapter on sovereignty, the committee records that "Professor Alan Brown of the University of Exeter has argued that, when it comes to technology procurement, the UK should treat open source and open-weight models as first-class options, with evaluation criteria that credit them for the strategic flexibility they preserve." The footnote points to my Computer Weekly piece, the one whose subtitle is the core message of Making AI Work for Britain: consolidate demand, diversify supply.

The citation is gratifying. But it is not the interesting part. The interesting part is that a cross-party committee, working from its own evidence sessions and its own witnesses, has arrived at almost exactly the diagnosis the book sets out. When the analysis you have been making from the outside starts appearing in the language of parliamentary scrutiny, something has shifted in the centre of gravity of the debate.

What the Committee Actually Said

The report is built on a simple structure: four building blocks that successful digital government requires, and four barriers that currently stand in the way.

The building blocks are money, people, information, data security, and delivery. On each, the verdict is roughly the same. The government has a vision and the beginnings of the right machinery, but it cannot tell you what it spends, cannot get enough skilled people into the roles that matter, has not held itself to the data security standards public trust requires, and has produced a roadmap with no overarching metrics by which delivery can be judged. The committee is blunt about the last of these: publishing the roadmap as an ordinary web page rather than as a formal document laid before Parliament, it notes, conveniently allows the government to revise its commitments quietly, without the alerts that would let anyone hold it to account.

The four barriers are where the report sharpens into an argument. The first is hype. The committee takes the government's own headline claim, drawn from its January 2025 State of digital government review, that digitisation could save £45 billion a year, and calls it "worryingly optimistic", pointing out that the figure rests on an assumption that all routine tasks and a tenth of non-routine ones can be automated. The second is legacy systems, where the central scandal is not cost but ignorance: the government still does not know the full scale of what it is running. The third is vendor lock-in, much discussed in recent years but with little to show for it. The fourth is sovereignty. These last two are where my work sits, and where the committee's conclusions are most striking.

On lock-in, the report names names. Palantir concerns the committee most, and it recommends that the government commit to exercising the February 2027 break clause in the NHS Federated Data Platform contract, the £330 million system that holds and connects patient data, and publish a fully costed exit plan by the end of this year. It wants reasons for the £240 million Ministry of Defence contract awarded to Palantir in December without a competitive tender. It points to Amazon Web Services as the sole bidder for a ten-year, £472 million HMRC contract, and to the Competition and Markets Authority's estimate that Microsoft and AWS together hold between 60 and 80 per cent of the UK cloud infrastructure market.

Its remedy is structural rather than rhetorical: a strategy from the Government Digital Service, the unit at the centre of government charged with digital reform, to end lock-in, with supplier diversification targets reported quarterly; a cloud consumption dashboard that publishes contract values, break clauses and licensing terms; a requirement that public bodies prioritise open-source tools through the planned update to the Procurement Act; and a minimum share of procurement budgets directed to UK start-ups and small and medium-sized firms.

On sovereignty, the committee is equally direct. Reliance on a handful of US providers is, in its words, a strategic and economic vulnerability, one that could see the government's ambitions derailed by a decision taken outside our shores. It wants a working definition of technology sovereignty, reviewed annually, and a strategy with stretching targets for sovereign and open-source alternatives.

The Committee Reached the Same Conclusions as My Book

Strip away the parliamentary tone, and the recommendations are the framework I have been arguing for, almost line by line.

Consolidate demand, diversify supply is precisely what a cloud dashboard plus an all-of-government contract plus supplier diversification targets amounts to: aggregate the buying power, then deliberately spread the risk. The costed exit plan for the FDP is exit-by-design made concrete, the recognition that the time to plan your departure from a supplier is before you are dependent on them, not after. The committee's concerns that the government is "worryingly comfortable" with its dependencies is silent lock-in described from the inside. And treating open source as a first-class procurement option, the specific point for which I am cited, is the smart-buyer model applied to the one decision that determines everything downstream.

This is not a coincidence so much as convergence. The argument I’ve been making has moved from contested to mainstream, and a committee with no particular reason to flatter me has put it on the record.

The Blind Spot in the Report

But there is a critical complication. For all its diagnostic sharpness, the report has the very weakness it identifies in government. It is strong on what and conspicuously lighter on how.

A select committee shines a light. It does not deliver. Its recommendations carry no legal force, and the government's track record on adopting committee recommendations is, to put it gently, mixed. There is a deeper irony, too. The committee rightly criticises the government for a £45 billion figure unsupported by a credible delivery path. Yet a report calling for an exit plan, a sovereignty strategy, a workforce strategy, a legacy taskforce and a re-engineered cloud market, all at once, risks the same charge it levels at others: an ambitious destination with no costed route. The committee even warns, quoting its own witnesses, against the temptation to "boil the ocean". The recommendations, taken together, come close to asking the government to do exactly that.

So, the right response is neither triumph nor cynicism. The diagnosis is now a consensus, which is real progress and was not true even two years ago. The open question is the one my book keeps returning to, and the one I summarised after reviewing the government's record against my own 25 recommendations: vigorous activity, but no completion.

The work that matters now is not making the case. That case is increasingly won. It is building the delivery discipline, the metrics, and the follow-through that turn a sound diagnosis into a working state. That is harder, less glamorous, and far easier to abandon when the next priority arrives.

For digital leaders, this raises an important question: When the government responds to this report, as it must and conventionally does within about sixty days, what would count as evidence that it has accepted the diagnosis rather than merely acknowledged it?

My own answer is simple: a costed FDP exit plan by December, and a sovereignty definition you can actually hold a department to. I will be watching for both and tracking them on UK AI Watch. I hope you’ll be watching too.

How many AI and algorithmic systems are in use across the UK's central government? According to the government's own mandated transparency register, the answer is 131. That’s not an estimate, not a survey response, but the official record of every algorithmic tool that central departments have declared. The UK government has reported that it met its commitment to publish them all by the end of 2025.

Can that be true? It cannot, and the distance between that number and the reality needs to be explored.

When I worked on the National Audit Office's 2024 study of AI in UK government, our survey of 87 government bodies identified 74 AI use cases already deployed across departments and arm's-length bodies. That was autumn 2023, before the AI Opportunities Action Plan and before the current surge in adoption. If 87 bodies were already running 74 tools more than two years ago, a register today listing 131 across the whole of central government is not a measure of how much AI government uses. It is a measure of how much AI government departments are willing to write down. That 2023 count was itself conservative: the NAO survey deliberately excluded AI embedded by default in existing software and the ad-hoc use of public tools by individual civil servants, the very categories that have grown fastest since.

What the Register Shows

If you read through the register, the typical record is a calculator. Pension calculator. Budget planner. Mortgage repayment calculator. Interest calculator. Or perhaps a chatbot: Ask HMRC online, DVLA Contact Centre chatbot, GOV.UK Chat. Then an identity verification tool. Then a variety of dashboards such as a similar-schools clustering tool used for attendance reporting.

These are useful tools and worth publishing. They are also, almost without exception, the safest things to publish. A calculator that estimates your mortgage repayments is deterministic, low-risk and politically uncontroversial. A chatbot that surfaces existing guidance pages is really helpful and easy to defend. Publishing a transparency record is easy and quick.

What you will struggle to find in the register is the harder category. Tools that triage benefit claims for fraud signals. Tools that score immigration applications. Tools that prioritise tax investigations. Tools that assist police forces in risk assessment. These exist, and receive a great deal of comment. Other trackers, such as the Public Law Project's independent Tracking Automated Government register, identify a number of them. Most are not on the ATRS, either because they are explicitly exempt under the December 2024 scope and exemptions policy, because they sit just outside the in-scope organisations, or because no one has yet been compelled to declare them.

Unfortunately, a transparency register that operates only where the stakes are low is not offering a very meaningful picture of AI use in the UK public sector.

The AI Accountability Puzzle

The trajectory tells its own story. The ATRS became mandatory for central departments in February 2024. Through most of that year the register barely moved. By summer 2024 it held 9 records, and 23 by the end of the year. The compliance survey published alongside the NAO report found that 38 per cent of responding bodies reported never complying with the standard.

Then in January 2025 the Public Accounts Committee called in the Permanent Secretary at DSIT to give evidence and asked her directly why only 33 records had been published. Within twelve weeks the count had nearly doubled. By year end, against a public commitment to publish every in-scope tool by the end of 2025, it had reached approximately 125. The lesson is uncomfortably familiar. The mandate, as a piece of policy, did very little. What moved the needle was the prospect of being named in a select committee report.

This is not a particularly unusual finding. Soft policy mechanisms rarely change institutional behaviour without a clear tracking approach supported by a meaningful enforcement function. But it does suggest something specific about the architecture of AI accountability in the UK. If transparency relies on individual select committees noticing a problem in time to ask about it, the system has no general purpose mechanism for keeping pace with deployment. AI is being adopted faster than parliamentary scrutiny can be organised around it.

The Denominator is Unknown by Design

As a result, we don’t currently know how many algorithmic tools the UK public sector uses today. The UK government can declare the register complete only because it decides what counts as in scope. The current scope policy excludes a great deal: national security applications, broad analytical work, tools that affect "groups" rather than identifiable individuals, and more.

It also has no answer for the AI that is now arriving inside every commodity productivity tool the civil service procures. When a department buys Microsoft 365 with Copilot built in, no transparency record gets filed, even though every drafted email, summarised meeting and triaged inbox is shaped by an algorithmic system. Nor does it capture the shadow estate: the consumer tools civil servants reach for without sanction. A Microsoft survey of more than 2,000 UK workers found that 71 per cent had used unapproved AI at work, and there is no reason to assume Whitehall is the exception. The difference is that no one is counting how often it happens inside government, or what citizen data goes with it.

An effective public sector AI transparency regime would begin somewhere different. It would start with an independent inventory of deployed tools, conducted to a consistent definition, and use the register to make sense of that inventory rather than to constitute it. This is what we can see in other places. Amsterdam and Helsinki pioneered registers built from the systems their own administrations actually ran, and a shared transparency standard followed from that practice rather than preceding it. The Netherlands extended the same approach to national level, where the data protection authority is only now pressing for registration to become a legal requirement. The UK has gone the other way around, declaring the standard first and then hoping departments would follow.

Seeing is Believing

Want to see more on the UK government’s AI register? To offer greater insight and make this more concrete, I have published an interactive tracker that pulls every ATRS record live from GOV.UK, categorises them by tool type, and lets anyone browse, filter, and search the register. You can find it at futureofai.uk/atrs-tracker.html. It is not a replacement for the official register. It is meant as a critical companion to it. Take a look and let me know what you think.

If you work in or with the public sector, two questions are worth taking back to your own organisation. First, how many algorithmic tools is your organisation using, including the ones bundled inside the commercial software you have already paid for? Second, who in your organisation would notice if the answer to that question started to climb sharply?

A transparency standard that cannot answer those two questions is not yet doing the job it was built for.

Last week I wrote about Katrina Manson's Project Maven, the inside story of how a small team in a windowless Pentagon room set out in 2017 to put AI at the heart of how America fights its wars. It is a serious piece of reporting, drawn from more than two hundred interviews, and reviewers from The Economist to the New York Times have rightly placed it among the most important recent books on AI and conflict. But the more I consider it, the more I am struck by how the experiences described reveal important success factors for every leader as they seek to deliver AI-driven transformation.

Strip out the descriptions of targeting algorithms, drone footage, and rooms full of intelligence analysts, and what remains is a case study every digital leader will recognise. A small team trying to drag a vast organisation into a different way of working. A technology that promised more than it could initially deliver. Bureaucracy that fought back. Talent that came and went. A long argument about ethics that no one wanted to have but everyone had to. The names and the stakes differ from anything most of us work on, but the patterns will feel familiar to anyone who has tried to push a serious AI programme through a complex organisation.

There are seven lessons I think are worth pulling out.

1. Leadership sometimes means defying the system you serve

Manson's protagonist, Marine Corps Colonel Drew Cukor, was given a mandate by Deputy Defense Secretary Bob Work in the April 2017 memo establishing the Algorithmic Warfare Cross-Functional Team, but very little authority to deliver it. What Cukor and his small team had instead was focus, energy, and a refusal to accept that the Pentagon's procurement cycle, security culture, and turf wars were immovable. At several points their actions bordered on insubordination. The book makes clear this was not heroism for its own sake. It was the only way to get the work done in the timescales that mattered.

The lesson for digital leaders is not "break the rules". It is that real AI delivery requires people willing to apply judgement against the grain of the organisation, and must include senior-level cover for such actions when they do. Most large enterprises and public bodies have no shortage of governance. What they lack is the small number of leaders prepared to push, with purpose, against settled assumptions.

2. The data problem is rarely the data problem you expect

The single biggest constraint on Project Maven was not algorithms. It was data: too little of it, badly labelled, locked up by classification rules, and contested between agencies. Manson told NPR that the early Project Maven models had been trained on images of wedding cakes, bridal veils, and grooms' suits before being repurposed for the battlefield, where they confused trees for people and a cloud for a school bus. Cukor himself said his AI was, in those early days, "just a bag of potato chips" to operators.

Anyone who has run an enterprise AI programme will recognise this. The hard work is not picking a model. It is finding data that is current, representative, and legally usable, then labelling it properly, then negotiating who is allowed to share what with whom. Privacy, ownership, and rights are not back-office issues that the lawyers will sort out later. They are first-order design constraints. Treating them as such early saves months of rework, and a great deal of avoidable embarrassment, later.

3. Experiment at the scale the problem requires

One detail in the book has stayed with me. The Project Maven team would, at peak, test more than 1,500 algorithms in order to deploy fewer than a dozen of them. That ratio is worth considering. It is not the typical organisational picture of AI: pick a model, prove a pilot, scale it up. It is closer to drug discovery. Most things you try will not work. Some will work, but not well enough. A small number will earn their place in production.

Most organisations are nowhere near set up for this. They run a handful of carefully curated pilots, almost all of which are declared successful, and then wonder why so little reaches the front line. The infrastructure question for the next phase of enterprise AI is not "do we have a platform". It is whether the organisation can afford, financially and culturally, to throw away ninety-nine per cent of what it builds. Without that capacity, pilot purgatory is more or less guaranteed.

4. The model is not the system

Perhaps the most important sentence in Manson's account of why Project Maven eventually started to work is the one that names three things, not one: the quality of the underlying data, the system in which the algorithm sat, and the smoothness of the workflow the operators could build around it. None of those was sufficient on its own. All three had to come together.

This matters because too many AI conversations in business and government still reduce to a debate about models. Which foundation model? Which vendor? Which open-source variant? Those choices matter, but they matter least. What changes outcomes is whether the model is embedded in a system that fits the workflow of the people using it, fed by data they can trust, in a form they can act on. AI value is a property of systems, not algorithms.

5. The vendor relationship is itself a strategic risk

A second-order story runs through Manson's book alongside the Pentagon's internal one: how a handful of private companies, most prominently Palantir and Amazon Web Services, alongside Microsoft, Anduril and others, became indispensable to a national security capability. Project Maven did not just buy algorithms from these firms. It built workflows around them, trained its people on their interfaces, and made operational decisions inside their environments. Palantir's growth in particular was supercharged by the engagement, and the company's commercial posture was anything but passive.

That dependency carries three risks every digital leader will recognise. The first is alignment: how tightly do you want your strategy and your data coupled to a single supplier? The second is commercial: aggressive vendors will press their advantage at renewal. The third, easily missed, is bias, not only in the algorithms but in the framing each vendor brings to what AI is for and how it should be used. Buying from a vendor is also buying into their worldview.

This is where "consolidate demand, diversify supply" earns its place. Concentrating buying power gives an organisation leverage. Concentrating supply takes it away. The lesson from Project Maven is not to avoid commercial partners, which is neither possible nor desirable. It is to design the relationship deliberately, with exit-by-design, multiple credible sources, and a clear-eyed view of who is the buyer and who is the seller.

6. Persistence is a core competency

Project Maven survived a presidential transition, a public revolt by Google employees that ended the company's involvement in 2018, multiple changes of leadership, sustained turf wars between agencies, and several rounds of internal political opposition. It also survived a great deal of personal animosity inside its own team. None of that is unusual. What is unusual is that the project kept going long enough to deliver anything.

Persistence is unfashionable as a leadership virtue. It is harder to put on a CV than "transformation", and harder to talk about on stage than "vision". But Manson's account is, more than anything else, the story of a programme that refused to die. The implication for digital leaders is uncomfortable. Many of the most important AI initiatives in your organisation will not succeed in their first form, their first business case, or under their first sponsor. The question is whether they have the kind of patient backing that lets them get to the second, third, and beyond.

7. "Human in the loop" can quietly become "human on the loop"

The most uncomfortable thread in Manson's book is the one that runs through its final chapters. Project Maven has always insisted that it does not pull the trigger. Its job is to identify possible targets in surveillance footage, sort them, rank them, and pass them to a human operator who decides what happens next. That distinction, between an AI that recommends and a human who decides, has been the public ethical bedrock of the programme since its founding.

But Manson's reporting makes that line look much less stable than it sounds. When the system delivers a prioritised list of targets with precise coordinates, ready to be fed into a weapons system, and when the operator works under time pressure to act on what the system surfaces, what kind of decision is the human actually making? At what point does "human in the loop", actively choosing, become "human on the loop", rubber-stamping what the machine has already framed?

This is not a question confined to military AI. Every digital leader running a system that ranks candidates for hiring, flags transactions for review, or prioritises cases for casework will recognise the same tension. The system does not decide. The system suggests. But if the human accepts the suggestion in case after case, who is really in charge? Project Maven forces the question into the open in the most uncomfortable possible setting. The work for the rest of us is to ask it of our own systems before someone else does.

Where this leaves us

Project Maven continues to evolve, now housed at the National Geospatial-Intelligence Agency. And the ethical questions Manson's book raises about lethal autonomy are real and unresolved. But for digital leaders trying to make AI work in their own organisations, the more useful reading is as a case study in delivery: how a small team, with weak formal authority, built something the wider system did not know how to build for itself, and kept building it long after the initial enthusiasm had faded.

This is not the book I thought I would be reading. Not by a long way. When I picked up Katrina Manson's Project Maven, I was expecting a rather dry, technological review of AI applied to military applications and an analysis of the lessons learned about technology adoption. Instead, what I found was over 300 pages of something that reads more like an episode of “Yes, Minister” than an edition of “Tomorrow's World”. It lays out in compelling detail why AI adoption is yet another example of that well-known adage: 1% inspiration, 99% perspiration. In this case, the effort involved convincing the US military establishment that it had to wake from its institutional slumber and revolutionise. Fast.

The Team in the Basement

Katrina Manson’s book tells the story of how, in 2017, Colonel Drew Cukor gathered a small team inside a windowless Pentagon room with a mandate most of his colleagues considered either impossible or undesirable: put artificial intelligence at the heart of how America fights wars. Cukor was not a Silicon Valley evangelist. He was a Marine Corps officer who had experienced the deaths of several colleagues and was convinced that an AI-equipped China was closing the gap with American capability faster than anyone in the military wanted to admit. His response was to behave like a startup founder inside one of the most bureaucratic institutions on earth.

What followed, as Manson documents through more than 200 interviews with insiders and opponents, was not a smooth technology deployment. It was a decade-long battle of wills, budgets, procurement rules, ethical objections, and competing interests. The Maven team fought with Pentagon bureaucrats and each other. They enlisted a reluctant Silicon Valley and triggered a revolt among thousands of Google employees who refused to have their work used in targeting algorithms. They brought in Palantir, Amazon, Microsoft, and others to field AI systems in live combat zones. They learned, often painfully, where AI fails.

A Story about Institutions, Not Algorithms

Manson is a Bloomberg reporter and former Financial Times correspondent who covered US foreign policy and defence. She writes with the confidence of someone who has spent years watching powerful institutions resist the very changes they publicly claim to want. The result is a book that is, at its core, not really about AI at all. It is about institutional change: how organisations convince themselves that transformation is urgent while doing everything possible to prevent it.

The pattern will be familiar to anyone who has watched the UK's public and private sectors grapple with AI adoption over the past decade. The technology is rarely the limiting factor. The limits are structural: procurement systems built for a different era, risk cultures that reward caution over capability, leadership teams with the authority to commission pilots but not the appetite to scale them. Project Maven had impact not because the AI was perfect, it frequently was not, but because Cukor and his team refused to treat the organisation's resistance as a reason to stop. They treated it as the problem to be solved. And were relentless about it.

Find. Fix. Finish.

The phrase comes from military targeting doctrine, and it organises much of what Project Maven was trying to do. Find the target. Fix its position. Finish the job. As a framework for thinking about AI adoption more broadly, it is uncomfortably precise.

Find

Britain has never had a problem with this step. We have more pilots, proofs-of-concept, and AI research projects than most comparable economies. The NHS, HMRC, local government: each has its collection of AI experiments, many of them technically impressive. Project Maven started here too. The initial brief was to use computer vision to analyse video footage from military drones, processing at a speed and scale no human team could match. The technology worked. That, in the end, was found to be the easy part.

Fix

The harder step was fixing the institutional conditions that would allow the technology to move from experiment to operation. For Project Maven, that meant creating a demand signal strong enough to bring Silicon Valley off the fence, building procurement routes that could actually accommodate AI vendors, and persuading a chain of command that deploying systems whose decisions they could not always explain was a risk worth accepting. Cukor spent years on this step. The Pentagon's bureaucracy pushed back at every turn. Most organisations never seriously attempt it; they mistake running another pilot for making progress.

Finish

Project Maven did eventually finish. Today, its AI-enabled systems operate in every branch of the US military. But Manson is careful not to make this feel like a triumph. Finishing, in the Project Maven sense, meant accepting that the AI was imperfect, that it would make mistakes, and that the organisation had to build the internal capacity to understand, oversee, and challenge what it had deployed. That is the smart-buyer model in its most demanding form: not passive consumption of capability, but active stewardship of it.

The one recurring obstacle in Manson's account, appearing at almost every stage of the story, was data. Not the absence of it. The US military generates more data than almost any organisation on earth. The problem was making it usable. Finding relevant datasets scattered across siloed systems. Securing permission to use footage and intelligence records carrying their own legal and classification constraints. Labelling thousands of images so that algorithms could learn to distinguish a vehicle from rubble, a person from a shadow. Applying those labelled datasets to real-world conditions that never quite matched the training environment.

Each of these was a solvable problem. None of them was a technology problem. They were organisational, legal, and human problems dressed in technical clothing. Anyone who has tried to build an AI system inside a large UK public body or private company will recognise every line of that.

What cut through, ultimately, was a refusal to wait for conditions to become comfortable. The Project Maven team went where the problems were hardest and stayed until something worked. They embedded with operational units, deployed imperfect systems, and iterated in the field rather than holding out for certainty that the lab would never deliver. They bent rules. They circumvented procurement timelines. On occasion, they acted first and sought permission afterwards. This was not recklessness. It was a deliberate choice to treat inaction as the greater risk.

The organising principle throughout was value creation, and the speed at which it could be demonstrated to sceptics who needed to see a system working in conditions they recognised before they would commit. That principle, at least, requires no adaptation before it travels. But it is not the only universal lesson we should be taking away.

Project Mason’s Lessons for the UK

The Project Maven story is an American one, shaped by American institutions, American procurement culture, and the particular urgency that comes from facing a near-peer military adversary in China. It would be easy to conclude that its lessons do not travel. I don’t think that’s right.

The structural challenge Cukor faced, convincing an established institution that it needed to change faster than its own processes allowed, is not uniquely military, nor uniquely American. It is the challenge facing every public body and large private organisation in the UK that is trying to move AI from the edges of the organisation to its operating core. The UK is exceptionally good at Find. It has a patchy record on Fix. It rarely gets to Finish. The result is what I have elsewhere called pilot purgatory: technically interesting, strategically irrelevant.

In Making AI Work for Britain, I make a simple argument that the answer lies in consolidating demand and diversifying supply: creating the institutional structures that send a clear, sustained signal to the market while simultaneously opening the supply side to genuine competition.

The US Department of Defense did not approach AI vendors with a list of discrete departmental requirements. It created a focal point, a programme, a mandate, around which commercial capability could coalesce. That is how you get from Find to Finish. Project Maven, for all its controversy and its contexts that many will rightly find troubling, is one of the most instructive case studies available in what that actually looks like. It is also a reminder that AI success at scale requires so much more than the algorithms.

There is something disconcerting about picking up a book you wrote twelve years ago. Thumbing through the pages and remembering what you were thinking, feeling and experiencing over a decade ago. Not because much of what you’re reading is wrong, but because a lot of it still rings so true!

In 2014, Mark Thompson, Jerry Fishenden, and I published Digitizing Government with an argument centred on what we called "government-as-platform". The thesis was that government should stop building bespoke systems for every function and start creating shared digital infrastructure — common components, open standards, reusable services — on which departments and citizens could build. The language was technological, but the underlying logic was structural: the problem was not that government lacked good technology, but that it kept buying the same capabilities repeatedly, in isolation, at great expense, with no shared foundation beneath any of it.

Looking back now, that argument is recognisably the same one I make in Making AI Work for Britain under a different name. "Consolidate demand, diversify supply" is what government-as-platform was really saying, expressed in terms of market structure rather than architecture. We did not quite see it in those terms at the time. The platform framing felt primarily like a technical proposition about APIs, shared components, and interoperability. The buyer-side logic, the idea that organised demand fundamentally changes what markets deliver, was present in the argument but not yet a primary focus. A decade of watching the same structural failures repeat themselves, now in AI, has made that underlying point considerably harder to miss.

Next Tuesday, Mark and I will revisit that argument at a University of Exeter online event. We’ll be looking back at what Digitizing Government got right, what the decade since has taught us, and what it means now that AI has entered the picture. You can sign up here.

What GDS got right

The Government Digital Service, established in 2011 and gathering real momentum by the time our book appeared, represented something important and different. Not just better technology or more modern design, though it delivered both. Its real innovation was structural: it consolidated demand across government before it opened the door to competing suppliers. Common platforms, shared standards, spend controls, and a clear mandate meant that, for a period, government bought differently. The market had to respond to organised demand rather than exploit fragmented procurement.

The results were visible. GOV.UK replaced hundreds of departmental websites with a single coherent user experience. The Digital Marketplace changed how smaller suppliers could compete. The Government Design Principles gave hundreds of teams a shared framework for what good looked like. None of this happened because government discovered better technology. It happened because it briefly acted as a coordinated buyer.

The difficult decade that followed

What went wrong is harder to summarise, because it happened gradually. But in retrospect, the cumulative effect is clear. The spending controls relaxed. The mandate weakened. Departments reasserted their independence. The market, which had adapted to GDS-era discipline, adapted back again. By the early 2020s, the fragmentation that Digitizing Government had diagnosed was largely back in place. The GOV.UK infrastructure endured, and pockets of strong practice remained. But the structural discipline that had made GDS work did not become self-sustaining. It had depended on institutional will, and institutional will is always provisional. (Particularly when it is continually at odds with the “administrative won’t”).

However, this is not a matter for despair. The GDS era demonstrated what is possible and produced a generation of digital leaders who understand what good government technology looks like. The question is whether the conditions for their impact can be created again.

Déjà vu all over again

When AI arrived in Whitehall and in boardrooms across Britain, I was really hoping to see many of those lessons applied. Instead, I watched the same structural errors repeat themselves. Organisations launched dozens of disconnected pilots before anyone had agreed on priorities. Procurement reverted to established relationships rather than open markets. Accountability for outcomes was diffuse. Suppliers shaped the agenda more than buyers did.

The terminology may have changed. "Digital transformation" has become "AI adoption." The pattern of failure did not.

The reason is not ignorance or bad faith. It is that the underlying incentive structures were never reformed. Digital technology adoption was detached from policy evolution. Each department, each directorate, each agency still has its own budget, its own relationships and its own definition of success. Consolidating demand requires someone with the authority and the will to act across those boundaries. In the absence of that, the default is fragmentation.

Consolidate demand, diversify supply

This is why I felt compelled to write Making AI Work for Britain. It is the argument at the heart of the book, and it owes a direct debt to the GDS experience. The lesson of the digital decade is not that government cannot innovate. Quite the contrary. It is that innovation without structural discipline produces pilots without programmes and activity without progress. Too many ideas and too much investment were wasted. And we’re in danger of seeing the same thing happen in the UK with AI.

"Consolidate demand, diversify supply" is not a slogan. It is a description of the conditions under which markets behave in the public interest. When buyers act together, suppliers compete on merit. When buyers act in isolation, suppliers exploit the asymmetry. The GDS model worked when it had the force of political will and structural alignment applied to that principle. Delivering on the UK’s AI strategy will only work when it does the same.

That means common frameworks for AI procurement, shared evaluation standards, and coordinated investment decisions across departments rather than parallel and competing ones. It means acting as a smart buyer rather than a collection of individual customers. None of this is technically overwhelming. Making it happen institutionally is a different matter entirely.

A conversation worth having

When Mark and I discuss Digitizing Government on Tuesday, we will not be indulging in nostalgia. We will be asking a practical question: what did the experiences of a decade of digital transformation teach us about how institutions change, and what does it mean for the choices facing the UK’s AI adoption in government and business right now?

And I will leave you with the question I am sitting with as I prepare for Tuesday:

A new study, supported by AWS, exploring the state of AI adoption in the UK was published last week. The temptation, when reading the AWS adoption numbers, is to feel reasonably good. Britain is ahead of others in Europe. Adoption is rising. The productivity gains are real. These advances should be celebrated. But the report's most important finding is not in its headline figures. It is in the gap they conceal, and how we address that gap is critical to the UK’s future.

A Baseline for Understanding AI in the UK

The AWS report’s headline finding is that AI adoption in the UK has reached 64% of organisations, up from 52% a year ago. Britain is now ten percentage points ahead of the European average. The productivity benefits, for those who have committed, are real: 68% report gains, 72% expect AI to drive growth in the coming year, 79% say their innovation timelines have accelerated. These are not trivial numbers, and the report is right to lead with them.

But the most arresting figure in the document is a date: 2102. That is the year by which every UK adopter will reach the most advanced stage of AI use if progress continues at its current pace. That’s right. So, while AI adoption has surged, advanced use that rewires how organisations operate has barely moved from 23% to 24% in twelve months. The problem is that the £35 billion productivity opportunity AWS identifies sits behind that 24% number, not the 64% one.

Viewed in this way, the AWS diagnosis tracks closely with the book’s argument. Britain’s danger is mistaking the appearance of transformation for its substance. Upgrading to Microsoft Copilot or buying ChatGPT licences across the workforce is all very well. But it is an adoption metric. It is not an AI strategy. The gap between adoption and advanced use is not a pacing problem to be solved by installing more licenses. It is a structural problem about how organisations procure, deploy, and integrate AI to improve today’s way of working.

Two findings in the report reinforce the book’s central argument, especially directly. The first is that 78% of organisations say they are more likely to adopt AI if the public sector integrates it into its own services. The second is the public sector itself: 31% of public adopters now sit at the most advanced stage of use, against 24% across UK businesses overall. Where the government has gone, it has gone deeper. This is the empirical case for what the book describes as consolidating demand. Government adoption is not just about better services. It shapes the market for everyone else. The 35% of UK startups citing public sector demand as a top scaling factor closes the loop from the supply side.

What the Report Does Not Say

Where the AWS report and the book part company is on the supply side. AWS’s three recommendations are entirely demand-side: move from adoption to transformation, scale AI across public services, and close the skills gap. All sensible. None of them asks who supplies the AI that Britain is being encouraged to adopt more deeply.

This is not a failing of the research. It is a function of who commissioned it. An AWS report is not the place to interrogate hyperscaler concentration. But the report’s own data raises the question. 98% of UK AI startups now build on the cloud, and the report presents this as a clear strength. The book asks a harder question. An AI economy built almost entirely on three or four foreign cloud stacks is a different proposition from one with a diverse supply. The £35 billion is meaningful for British GDP whether it accrues to British firms or to American platforms running British workloads. For headline output, those are the same thing. For strategic capability and fiscal sovereignty, they are not.

This is the silent lock-in the book takes seriously. It is not announced. It is built up incrementally, through routine technical decisions, until the cost of unwinding it exceeds the political capital available to do so. The AWS report frames cloud as table stakes. The book argues that the architectural decisions made at the bottom of the stack determine the strategic options available at the top, and that getting them right is something Britain has done before, in a different domain, within living memory. Anyone who lived through the GDS years will recognise the pattern.

The AI Skills Need

The third place where the book pushes further is on skills. The AWS report’s analysis is detailed: 49% of organisations cite skills shortages, hiring timelines have stretched from 5.5 to 8 months in a single year, and organisations are paying an average 41% salary premium for strong AI capability. All of this is correct, and all of it is workforce-framed. The skills problem is presented as workers needing to learn AI tools.

The harder skills gap sits upstream. The most consequential AI capability gap in Britain is not down at the desk level. It is up in senior leadership and procurement: the people deciding what to buy, from whom, on what terms, and with what exit options. A workforce trained on a particular vendor’s stack but unable to evaluate the strategic implications of building on that stack has not solved the problem. It has shifted it upstream and made it harder to see. The smart-buyer skills, the ones the state and large organisations need most, are not in the AWS skills count.

Delivering on the UK’s AI Future

Read together, the AWS report and Making AI Work for Britain are stronger than either alone. The report makes the empirical case that Britain has a problem worth solving. The book makes the structural case for how to solve it. Where the report says scale faster, the book asks scale toward what.

The question I would put to any senior leader reading the AWS numbers this week is the one the report itself does not quite ask. It is not whether to adopt more AI. It is whether your adoption is taking you somewhere you actually want to go, on terms you would accept if you were buying a building or signing a twenty-year lease.

Adoption is the easy part. The architectural choices underneath it are what will matter in five years.

For long stretches of 2025, I thought I’d made a mistake. I wasn't certain the book I was writing had a compelling argument.

The material was there. Drafts, notes, case studies, whitepapers, commissioned pieces for the Digital Policy Alliance and Digital Leaders Network, and a running conversation with senior leaders across government, finance, and industry about what AI was actually doing in their organisations rather than what it was supposed to be doing. All of it pointed somewhere. None of it pointed cleanly to a single book.

That changed over the course of early 2026. Not because I found the missing chapter or cracked the structural problem in a moment of inspiration. The change came from outside the manuscript. Four forces converged in the first months of this year, and between them they pulled what had been a collection of observations into a single, recognisable shape.

The technology got serious, fast

The first force was technical. Through late 2025 and into 2026, the frontier moved at a pace that made the earlier discussion of "AI readiness" feel like a hypothetical. Recursive self-improvement left the lab. Agentic systems stopped being a research curiosity and became a procurement question. By the time Anthropic publicly held back a model it judged too capable for public release, the conversation in boardrooms had shifted from whether to adopt AI to how fast AI tools could be acquired, and how to do it safely. A book written in the language of experimentation and pilots was suddenly speaking to a world where the technology was no longer the issue.

The geopolitics hardened

The second force was geopolitical. The launch of the Sovereign AI Fund, the £31 billion US–UK Tech Prosperity Deal, and the quiet scramble across European capitals to define national positions on compute, chips, and model sovereignty. What had been an abstract discussion about "British AI" a year earlier became a concrete conversation about supply chains, foreign dependencies, and the kinds of technological choices that countries cannot unmake. The argument I had been trying to make about institutional capability now had a harder frame around it. Sovereignty was no longer a rhetorical flourish. It was a policy agenda with budget lines.

The jobs conversation became real

The third force was economic. For most of the previous two years, discussion of AI and work had been dominated by speculative numbers: percentages of tasks automatable, sectors exposed, and futures imagined. By spring 2026 the conversation had narrowed. Specific roles were being reshaped or removed, specific firms were restructuring, and the financial impact on individual organisations had become measurable. By mid-April, roughly half of UK executives believed AI would reduce overall employment in Britain over the coming decade. That shift mattered for the book because it meant the argument I had been making about AI as an institutional question, not a technical one, stopped requiring defence. The evidence was arriving weekly.

The strategy-to-delivery gap started to bite

The fourth force was political and institutional. Through 2025, the UK had settled into a pattern of ambitious AI strategy announcements that were not matched by delivery capability. By early 2026, that gap had become the dominant story, whether in the Chancellor's "fastest AI adoption in the G7" pledge, the one-year review of the AI Opportunities Action Plan, or the various sectoral initiatives that promised transformation and delivered studies. This was the terrain I had been writing about all along. The difference was that by 2026 it was no longer a minority view. It was the question the sector was asking itself.

Why 2026 is special

When these four forces arrived together, the book's argument stopped being something I was trying to construct and became something I was trying to keep up with. The five reforms at the heart of Making AI Work for Britain (a smart-buyer function for the state, board-level accountability in organisations, a consolidated demand side coupled with a diversified supply side, clearer institutional ownership of AI outcomes, and a delivery-first rather than strategy-first operating model) did not come from a single moment of clarity. They came from watching what the technology, the geopolitics, the economics, and the politics were each, independently, pushing towards.

What did I get wrong along the way? More than one thing, but the honest answer is that I underestimated how quickly the conversation would shift from whether AI would matter institutionally to how it would. The book I completed is less about persuading readers that the institutional question is the central one, and more about giving them a working vocabulary for acting on it. That is a better book than the one I set out to write, and the reason it is a better book is that the conversation is finally ready to have it.

While there were times I had my doubts, I am now convinced that the convergence of these four forces is, in the end, good news for Britain. An institutional problem is a solvable problem. The UK has built institutional capability of exactly this kind before, most visibly with the Government Digital Service fifteen years ago, and the lessons from that work are not lost. The technology has raised the stakes. The geopolitics has sharpened the choices. The labour market has made the costs of delay concrete. The delivery gap is now an accepted fact rather than a contested claim.

Britain does not have to invent its way out of this. It has to organise its way out.

That is a far better starting position than the one the country had a year ago.

Making AI Work for Britain is published by London Publishing Partnership on Tuesday. Whatever its strengths and its flaws, it is a product of the moment it was written in, and I am grateful to the readers of these Dispatches for thinking it through alongside me.

The path to make AI work for Britain is in focus. The answer is within reach. Britain has the talent, the institutions, and now the clarity to make AI deliver for the country. It is time to get on with it.

Find more details of the book at FutureOfAI.uk. And let me know what you think.

Writing a book is a strange experience. You spend months making an argument by assembling evidence, testing the logic, and sharpening the language, only to find that somewhere in the middle of it all, a quiet doubt settles in. Not about whether the argument is right, but about whether it will matter. Whether the moment will catch up with the manuscript. Whether anyone cares. Whether the urgency and passion you feel as you write it will be evident to someone reading it six months later.

I have spent the better part of the past year making the case that the UK's AI challenge is not primarily a technology problem. It is an institutional one. The gap between what AI can do and what Britain is organised to do with it is widening at a pace that our current governance structures are not equipped to match. And I will admit that, as the final proofs went back to my publisher, I wondered whether events might prove me either too pessimistic or too late.

In the past few weeks, I’ve stopped wondering. The story of Anthropic's Mythos model has brought the argument into sharper focus than anything I could have written.

A Model Too Powerful to Release?

One evening in February, an Anthropic researcher sitting at a laptop in Bali set out to test the company's most powerful AI model. What he found stopped him in his tracks. The model, now known as Mythos, had autonomously identified and exploited a 17-year-old vulnerability in a widely used operating system. No human was involved after the initial instruction. The model found the flaw, built the exploit, and demonstrated how an attacker could take complete control of any server running the software from anywhere on the internet.

Anthropic has since confirmed that Mythos identified thousands of previously unknown vulnerabilities across every major operating system and web browser. It has not released the model publicly and doesn’t plan to. Instead, it has made a limited preview available to a small group of technology and security partners, including Amazon, Apple, Cisco, Microsoft, and Palo Alto Networks, under a new initiative called Project Glasswing, with the explicit goal of helping defenders secure critical systems before models with similar capabilities become more widely available.

Today’s Deeper AI Dilemma

It would be easy to read the Mythos story as a cautionary tale about a single unusually powerful model that a responsible company chose not to release. That framing is too narrow. What Mythos illustrates is that we have entered a phase in AI development where the gap between what is technically possible and what society is institutionally prepared to handle is widening at pace.

Anthropic's own frontier red team report describes Mythos as having "improved to the extent that it mostly saturates" existing cybersecurity benchmarks. That is a remarkable statement. It means the standard tools we have developed to measure and govern AI capability in this domain are already insufficient. The model has moved beyond the frame we built to contain it.

Anthropic's decision to restrict Mythos and invest in defensive deployment is a serious and responsible response. Project Glasswing commits up to $100 million in usage credits to help defenders get ahead of the threat. The fact that a frontier AI company identified the risk, disclosed it, and coordinated a response is, on balance, a positive signal about how the industry can behave.

But there is a much harder question. Project Glasswing is a private sector consortium, coordinated by a US company, working primarily with US technology partners. The UK government is not a named participant. UK critical infrastructure operators are not listed among the forty organisations with access to the Mythos preview. At the precise moment when AI capability has crossed a threshold that, in Anthropic's own words, "fundamentally changes the urgency required to protect critical infrastructure", Britain is largely on the outside looking in.

The UK Sovereignty Question in Focus

The week that Mythos became public knowledge, the government announced its response to exactly this kind of challenge. On 16th April, Technology Secretary Liz Kendall launched the £500 million Sovereign AI Unit at Wayve's King's Cross headquarters, describing it as "one of the single most important things this government will do for the future of this country". The fund will invest in British AI startups, provide access to supercomputing infrastructure, fast-track visas for global talent, and help portfolio companies win government contracts.

It is a serious initiative, and it deserves a serious welcome. But notice what it does and does not address. It backs the supply side: building British AI companies, securing compute capacity, and attracting talent. What it does not do is build the demand-side coordination architecture that would allow the UK to respond institutionally when a capability threshold is crossed. There was no mention of a standing mechanism for assessing threats to critical infrastructure. No procurement framework to give UK operators rapid access to defensive AI tools. No answer to the question of who coordinates the national response next time a Mythos-class model emerges. And we all know there will be a next time.

The irony is startling. The Sovereign AI Unit was launched on the same day that OpenAI quietly paused its Stargate UK data centre project, citing energy costs and the regulatory environment. Britain is announcing a fund to build sovereign AI capability at the precise moment the world's most prominent AI company has signalled that the conditions for large-scale AI infrastructure investment are not yet in place. The ambition and the mechanism are still not aligned.

What an adequate institutional response to Mythos would additionally require is worth spelling out. It would need a body with the authority and technical capability to assess implications for UK critical infrastructure at pace. It would need procurement frameworks that give UK operators a route to defensive AI tools without depending entirely on bilateral relationships with US technology companies. It would need a clear line of responsibility for who coordinates the national response when a new capability threshold is crossed. And it would need all of this to be in place before the moment of need, not assembled in response to it.

None of that infrastructure currently exists in a form that is fit for purpose. The AI Opportunities Action Plan has delivered 38 of its 50 commitments. The AI Security Institute does important work. But neither was designed for the kind of rapid, operationally serious response that a Mythos-class development demands. We are, as a country, still primarily in strategy mode. And strategy mode is not adequate for where we now are.

From AI Strategy to AI Delivery

Project Glasswing, for all its limitations from a UK sovereignty perspective, offers an interesting model. It is not a regulatory framework. It is a coordinated, time-limited, operationally focused initiative that brings together the organisations with both the capability and the responsibility to act. The UK equivalent would be a standing mechanism with real authority that can convene government, industry, and critical infrastructure operators quickly when a capability threshold is crossed. Not a consultation. Not a call for evidence. A response.

The vulnerabilities Mythos identified had survived, in some cases, decades of human review and millions of automated security tests. The systems they affect are not peripheral. They are the operating systems running NHS clinical infrastructure, the browsers processing financial transactions, the networking software underpinning government services. Britain's ability to protect itself from that kind of threat is not just a matter of having good technology. It is a matter of having the governance, the procurement, the skills, and the institutional coordination to deploy that technology effectively and in time.

That is the gap this country needs to close. It is the argument I have spent the past year developing in Making AI Work for Britain, published in a few days on 28th April by London Publishing Partnership. I wondered, in those final weeks of writing, whether the urgency I felt would translate. I need not have worried. Mythos has made the case more powerfully than I ever could have done myself.

I have been watching the UK government's AI ambition grow considerably in recent months. And I find myself in an unusual position: broadly supportive of the direction of travel and yet increasingly concerned about the route being taken to get there.

Last month, Chancellor Rachel Reeves set out what she called the defining economic choice of our era. AI, she argued, is the technology that will determine whether Britain grows or stagnates, and the government's ambition is unambiguous: the fastest AI adoption in the G7. It is a serious commitment, made in a serious setting. The OECD's estimate that AI could add 1.3 percentage points annually to UK productivity, worth around £140 billion per year, is not unrealistic if the conditions are right.

And yet. According to the UK government’s own research published in January 2026, only 16% of UK businesses currently use AI in any meaningful sense. More striking still, 80% of businesses neither use AI nor have any plans to. That is not a foundation for G7 leadership. It is a baseline that the most optimistic reading of current policy trajectories would struggle to transform in the timeframes the government has in mind.

The Wrong Diagnosis

The government's framework for closing this gap has four strands: build compute capacity, invest in homegrown AI development, unlock public and private sector data assets, and create regulatory sandboxes through the new AI Growth Lab. Each of these is a reasonable thing to do. However, none of them, individually or combined, will shift the adoption rate in the way the ambition requires.

The reason is straightforward. Infrastructure does not adopt itself. Better models, faster compute, and more permissive regulation create the conditions for adoption. They do not generate it. Adoption requires organisations to change how they work: how they commission technology, how they build capability, how they measure outcomes, and how they integrate AI into processes that were not designed with it in mind. That is a coordination problem, not an infrastructure problem. And the policy levers it requires are quite different from the ones currently being pulled.

There is a signal in the data that the government should be taking more seriously. Recent Lloyds research found that more UK businesses are planning to invest in AI training than in AI technology itself. On the surface, that looks like caution. I think it may be wisdom. Organisations investing in capability before tools are, implicitly, recognising where the real bottleneck sits. It is not access to AI that is holding them back. It is the organisational readiness to use it well.

A Lesson We’ve Already Learned

Britain has solved a problem very like this one before. When the Government Digital Service was established in 2011, the challenge was not that good digital tools did not exist. They did. The problem was that every department was procuring, evaluating, and deploying them independently, producing fragmentation, duplication, and a market signal too diffuse for suppliers to build confidently against.

GDS worked not because it built better tools, but because it consolidated demand. The Digital Service Standard meant that what good looks like became a shared answer rather than a departmental guess. Procurement frameworks gave suppliers a stable, legible market. Shared outcome metrics meant that progress could be measured in something other than activity. Within five years, the UK was first in the UN e-government rankings and had saved over £4 billion through structural reform.

The adoption rate moved because the coordination problem was solved, not because the tools improved. That distinction is the key to understanding what AI adoption policy is currently missing.

The AI Growth Lab is, in spirit, the right instinct. Cross-economy sandboxes and sector-level testing are serious mechanisms. But sandboxes are by definition bounded and temporary. They generate evidence. What translates that evidence into scale is a demand-side architecture that organisations of all sizes can navigate without the bespoke evaluation and legal resources they simply do not have.

What Would Help

Three things would make a material difference to the AI adoption trajectory, and none of them require new legislation or large capital commitments.

First, a shared outcomes framework that defines what successful AI deployment looks like, not in terms of deployment counts or investment volumes, but in terms of measurable productivity and service improvement. The AI Opportunities Action Plan progress report tells us that 38 of 50 commitments have been delivered in year one. That is encouraging. But delivery of commitments is an input metric. What are the output metrics? If we cannot answer that question with precision, we are measuring the wrong thing.

Second, procurement consortia that allow mid-sized organisations, particularly across the public sector, to access AI solutions without the transaction costs that currently make independent evaluation prohibitive. This is how the Digital Marketplace worked. It is how a coordinated AI procurement architecture could work too.

Third, sustained investment in demand-side capability: the commissioning skills, the product management disciplines, and the governance literacy that organisations need to be good buyers of AI, not simply recipients of it. The British Chambers of Commerce has already warned that two thirds of UK firms report skills shortages. The Lloyds data tells us where firms think the gap sits. Policy needs to follow that logic.

The Ambition is Right. The Mechanism is Missing.

None of this should discourage us. Britain has real structural advantages: depth of research talent, a common law tradition that enables flexible contracting, and a public sector large enough to anchor demand at scale if it chooses to. The £140 billion productivity prize is achievable, in principle.

But the path from 16% AI adoption to G7 leadership runs through coordination, not acceleration. The last time Britain faced an adoption problem of this kind at scale, it built the Government Digital Service. The question now is whether we have the institutional imagination to do something equivalent for AI: not another initiative, but a real architecture for demand. That is the work. The ambition we have. The mechanism we are still looking for.

This question is at the heart of my new book, Making AI Work for Britain, to be published on 28th April by London Publishing Partnership. The argument is there in full alongside what a real demand-side architecture for AI might look like.