The Cabinet Office has commissioned the business and science department to work out what it would cost the UK economy if British users were shut out of the newest models from Anthropic, OpenAI and their peers, with an answer expected in weeks. That is a reasonable thing to commission, and it answers a question nobody was really asking. The harder one came from Dame Chi Onwurah, who chairs the Commons science, technology and innovation committee: welcoming the assessment, she said the country also needs “a plan to address unacceptable levels of dependency, and indeed how an acceptable level of dependency is defined”. Nobody in Whitehall has published that definition. Until someone does, every UK business that has built on a frontier model is setting its own threshold by default, usually without noticing.
Strategic Insight: An economic impact number tells you what a cut-off would cost. It does not tell you how much exposure is acceptable, which supplier concentration is tolerable, or what a workable fallback looks like. Those are procurement and architecture decisions, and they are already being made inside your organisation by whoever picked the API.
What the money actually bought
Officials pointed to two commitments when asked what Britain is doing about this: a £1.1bn plan for AI hardware and a £500m sovereign AI fund. Both are real, and both are aimed at problems adjacent to the one that surfaced in June.
The hardware money buys compute. The sovereign fund buys equity positions in British companies, and it has been doing so at pace. Its chair, James Wise, reported this month that the fund now sits behind twelve domestic companies, five announced and seven closing, which between them have raised £4bn. The portfolio leans towards compute architecture, materials, life sciences and security, which is a defensible read of where a mid-sized country can hold ground.
Neither line of spending produces a frontier model that a UK company can use next Tuesday when an American one becomes unavailable. That is not a criticism of either programme. It is a description of what they are for.
The gap between the answer and the question
Britain’s response to a dependency problem has been an investment response. Investment addresses capability gaps: it works when the constraint is that you lack something and could build it with money and time. The June episode was not a capability gap.
What happened was that on 12 June the US Commerce Department ordered Anthropic to bar foreign nationals from Fable 5 and Mythos 5, citing a disputed jailbreak that the company argued was narrow and widely shared across rival systems. Anthropic could not verify nationality in real time, so it disabled both models for everyone, Americans included. The controls were lifted at the end of the month and Fable 5 returned globally on 1 July. Nineteen days, start to finish, with the Commerce Secretary explicitly reserving the right to reimpose licensing if circumstances changed.
Nothing about that sequence would have gone differently if Britain had owned more GPUs or a larger stake in twelve start-ups. The failure mode was a switch controlled by someone else, thrown for reasons that had nothing to do with the UK and could not be appealed by anyone in it.
| What Britain has | Scale | What it does about a cut-off |
|---|---|---|
| AI hardware plan | £1.1bn | Provides compute capacity; does not provide a model to run on it that matches the frontier |
| Sovereign AI fund | £500m across 12 companies | Builds domestic suppliers over years; no substitute available during a suspension |
| Public sector AI contracts since 2018 | £5bn across 2,129 awards | Measures how far the state has already committed to external suppliers |
| June 2026 Fable 5 suspension | 19 days | The only real-world test of what a cut-off costs, and it hit US users too |
Strategic Reality: The £5bn of public sector AI contracts recorded by Tussell since 2018 is not a separate story from this one. If you sell into government, or into a supply chain that does, the state’s dependency profile is inside your risk register whether or not you put it there.
What the June episode actually proved
The most useful disagreement in the reporting is between two statements from the same person. Ciaran Martin, the National Cyber Security Centre’s founding chief executive and now an Oxford professor, told the FT he found the Fable 5 experience reassuring in part. His reasoning was mechanical rather than optimistic: the order could not be implemented as written, so Anthropic pulled the product entirely instead of sorting users by passport. On that basis he called it “slightly implausible that an American AI model would be restricted from foreigners”.
He also warned that “The US’s ability to manipulate and leverage the whole AI stack - to try and force countries to bend to its will - could be significant”.
Both can be true, and I do not think the tension resolves. The first observation is about one enforcement attempt against one consumer product. The second is about the structural position of a country that controls chips, cloud, models and the tooling above them. Treating the first as a general reassurance requires assuming that every future control will be as clumsy as this one.
There is a detail in the June sequence that cuts against that assumption. Before the general lift, Washington permitted a limited release of Mythos 5, the vulnerability-detection model, to a small set of trusted US organisations. Nationality screening at consumer scale defeated the order. An allowlist of named institutions did not. Segmentation was infeasible in one form and straightforward in another, in the same episode, within the same three weeks.
Critical Context: The protection UK users enjoyed in June came from a technical limitation, not a policy commitment. It held because the model in question served hundreds of millions of people and could not be filtered cleanly. It would not have held for an enterprise product with named accounts and contracted entities, which is what most serious business deployments actually are.
What buyers keep getting wrong about this risk
- Treating it as an outage risk. Availability language covers the wrong failure. An outage is a supplier failing to deliver what it agreed and owing you a remedy. This is a supplier delivering exactly what it agreed until a third-party government instructs otherwise, with no contractual path to compensation.
- Assuming the contract governs. Your master services agreement binds your vendor. It does not bind the US Commerce Department, and no amount of negotiation on service credits changes that.
- Reading “multi-model” as diversified. Two American frontier labs are two suppliers and one jurisdiction. A directive aimed at model exports is more likely to catch both than to catch one.
- Assuming the cheaper hedge is available. Any UK organisation that quietly standardised on a Chinese open-weight model because it was good enough now holds a policy exposure of a different shape, given the draft US letter telling allies to choose between AI blocs.
Why the impact assessment will understate it
The economic figure the Cabinet Office receives will almost certainly be built from lost productivity during a delay: what firms forgo by waiting weeks for capabilities their competitors already hold. One government figure framed it that way, arguing that businesses move on a new model immediately and a couple of weeks behind is a real economic cost.
That framing measures the wrong thing for most companies. A fortnight of slower coding assistance is an irritation. A product whose core function calls a model that is no longer available is a different matter, and so is a regulated process that has been validated against one specific system. The cost is not proportional to the length of the outage. It is proportional to how deeply the capability is wired into things you have promised other people.
⚠️ Warning: If your service level commitments to customers assume a capability you cannot provide from any second source, you have written a promise your suppliers have not made to you. That gap is not visible in an availability metric and will not appear in any impact assessment produced in Whitehall.
Who carries this, and where it lands
The awkward feature of jurisdictional supplier risk is that no single function owns it. Engineering picked the model on capability. Procurement negotiated the contract on price and terms. Risk assessed the vendor on security posture and data handling. All three did their jobs, and none of them was asked whether the supplier’s home government might withdraw the product.
That is how a dependency becomes structural without anyone approving it. The decision that mattered was made early, by a team choosing an API for a prototype, and everything since has been built on top.
| Function | What changes | What it needs | How to tell it is working |
|---|---|---|---|
| Engineering and product | Model choice becomes a reversible decision, not a foundation | Time to build and test an abstraction layer; a named second model per capability | A documented switch, exercised at least once, with measured quality difference |
| Procurement and legal | Vendor questions extend to jurisdiction and sub-processing | Standard clauses on notice periods, export-control notification, model deprecation | Contracts that say what happens when a government, not the vendor, causes the failure |
| Risk and security | Concentration risk gains a jurisdictional axis | A dependency register listing supplier, jurisdiction, substitutability and business criticality | Board-visible exposure by jurisdiction, refreshed quarterly |
| Executive and board | Dependency becomes a stated appetite rather than an accident | A written threshold: how much revenue may depend on one jurisdiction | A number the board has agreed and can defend to a regulator or customer |
What separates the prepared from the exposed
The organisations that will handle the next suspension well are not the ones with the cleverest architecture. They are the ones that have written down an answer to Onwurah’s question at their own scale: what proportion of our revenue, our customer commitments and our regulated processes may depend on capability from a single jurisdiction, and what do we do at the point where that proportion is exceeded?
Most firms have this discipline already for other things. Banks hold it for counterparty exposure. Manufacturers hold it for single-source components. The reason it has not been applied to frontier models is that the dependency arrived through a developer signing up for an API key rather than through a procurement process anyone reviewed.
🎯 Success Factor: A tested fallback beats a documented one by a wide margin. An untested second model is a plan, and plans that have never been run tend to fail on details nobody anticipated: prompt behaviour, output format, latency, cost, and the evaluation work needed to prove the substitute is fit for a regulated purpose.
What to do before the next directive
💡 Implementation Framework: Dependency thresholds
Phase 1: Map (2 to 4 weeks)
- List every product feature, internal process and customer commitment that calls a frontier model
- Record supplier, jurisdiction, and whether a second source exists today
- Classify each by what breaks if access stops tomorrow: degraded, delayed, or unavailable
Phase 2: Decide (4 to 6 weeks)
- Set a board-agreed ceiling on revenue and regulated processes exposed to one jurisdiction
- Identify which “unavailable” items must move below that ceiling and by when
- Price the substitution work honestly, including re-evaluation, not just the integration
Phase 3: Test (ongoing, quarterly)
- Run a live switch to the second model on one critical path
- Measure quality, cost and latency differences and record them
- Update customer commitments to match what you can actually deliver from a second source
For teams at different stages
If frontier models are still in pilots
- Put the abstraction in now. Routing model calls through a thin internal interface costs almost nothing before launch and becomes expensive once several products depend on provider-specific behaviour.
- Choose a second model at the same time as the first. Not to run it, but to know what it is and roughly how the outputs differ.
- Write the jurisdiction into the vendor assessment. One line in the template, added now, prevents a category of surprise later.
If models are in production
- Build the dependency register before anything else. You cannot set a threshold without knowing your current position, and in most organisations that position is worse than the executive team assumes.
- Run one real switch. Pick the highest-criticality path, move it to a second model in a controlled window, and record what broke.
- Reconcile your customer promises. Where a service commitment depends on capability you cannot second-source, either change the commitment or fund the substitute.
If you sell into government or regulated sectors
- Expect the question in your next tender. With £5bn of public sector AI contracts placed since 2018 and sovereignty now an explicit aim, supplier jurisdiction is moving from a curiosity to a scored criterion.
- Document substitutability rather than claiming independence. Buyers can verify a tested fallback. They cannot verify a claim of resilience, and will discount it.
- Track the procurement challenges from the sovereign fund. A programme that both invests in and buys from British suppliers changes the competitive position of anyone bidding against them.
Resource Reality: A dependency register for a mid-sized organisation is roughly two to three weeks of one person’s time, plus a workshop with engineering and procurement. The expensive part is not the mapping. It is the substitution work the map reveals, which is why the register keeps getting deferred.
The parts that catch people out
The abstraction layer that does not abstract
Routing calls through a common interface makes swapping providers easy at the code level and tells you nothing about whether the outputs are equivalent. Prompts tuned against one model degrade on another in ways that unit tests do not catch, and a regulated process validated against a specific system may need revalidating entirely.
Mitigation: Treat the abstraction as plumbing, not insurance. The real portability work is the evaluation suite that proves a second model produces acceptable output on your actual tasks, and that suite has to exist before you need it.
The hedge that becomes the exposure
Diversifying away from US models points naturally at Chinese open-weight alternatives, which have closed much of the capability gap and cost considerably less. That trade is now live policy risk rather than a technical choice, given a draft US letter warning that partners cannot hold membership of both Washington’s framework and Beijing’s.
Mitigation: Judge open-weight options on where the weights can run rather than where they came from. A model you host yourself under your own control is a genuinely different risk profile from one you call as a service, and that distinction matters more than the country of origin.
The fallback nobody has run
A second provider configured but never used is not a fallback. It is a configuration. Rate limits differ, quotas need pre-arranging, and the first time you push production traffic at an account that has only ever served test calls is the wrong moment to discover the limits.
Mitigation: Run the switch on a schedule, quarterly, on a real path with real load. Record the quality delta and the cost delta. If neither has been measured, the plan is untested.
Dependency inherited through the supply chain
Your own model choices may be well governed whilst a critical SaaS vendor in your stack has quietly built its core feature on a single frontier provider. Their suspension is your outage, and your customers will not care where in the chain it originated.
Mitigation: Add the question to vendor reviews and renewals. Ask which models a supplier’s product depends on and what their substitution position is. A vendor who cannot answer has not thought about it, which is itself the answer.
Reality Check: None of this eliminates the exposure. Frontier capability is concentrated in a small number of US companies operating under one government’s export authority, and no purchasing decision available to a UK business changes that. The realistic goal is to know the size of your exposure, keep it inside a threshold you have chosen deliberately, and be able to degrade rather than stop.
Setting your own threshold
The value in the Cabinet Office assessment is not the number it produces. It is that commissioning it concedes the premise: access to frontier capability is a policy variable held by another state, not a commercial certainty secured by contract. Once that is conceded at national level, the same logic runs down to every organisation that has made a promise to a customer on the strength of a model it does not control.
Three things separate an organisation that has decided its threshold from one that has merely inherited one.
- A register that exists. Written down, listing supplier and jurisdiction against business criticality, and reviewed at board level rather than kept in an engineering wiki.
- A number that has been agreed. How much exposure to one jurisdiction is acceptable, stated as a proportion of revenue or regulated activity, with a named owner.
- A switch that has been thrown. At least once, on a real path, with the quality and cost differences measured rather than estimated.
Measuring the right thing
The metric most teams reach for is availability, and it will look excellent right up to the moment it becomes irrelevant. Availability measures whether your supplier is delivering. The exposure here is that a government instructs your supplier to stop, which produces perfect availability statistics for eleven months and a hard stop in the twelfth.
The measure that matters is substitution time: how long, from a standing start, until a critical capability runs acceptably on a second source. If nobody in your organisation can state that figure for your most important AI-dependent feature, the honest answer is that you do not know, and the previous demonstration ran for nineteen days.
Take Action: Onwurah’s question has a business version that arrives sooner than the policy one. Ministers may take years to define an acceptable national dependency. You can define yours this quarter, and unlike them, you can act on it without waiting for anyone else.
Your next steps
This week:
- List every customer-facing feature and regulated process that calls a frontier model
- Record which supplier and which jurisdiction each depends on
- Identify the one that would hurt most if access stopped tomorrow
This quarter:
- Agree a board-level ceiling on single-jurisdiction exposure
- Run one live switch to a second model on a critical path and measure the difference
- Add supplier jurisdiction and substitutability to vendor assessment and renewal templates
This year:
- Bring your highest-criticality dependencies below the agreed ceiling
- Reconcile customer service commitments with what a second source can actually deliver
- Reassess as the sovereign fund portfolio matures and domestic options become credible
Source: UK examines economic hit from loss of access to frontier AI models (Financial Times, 2026), reported from London by Lucy Fisher with further reporting by Tim Bradshaw. Resultsense covered the assessment as it was announced in UK counts the cost of losing access to frontier AI models, and analysed the June suspension in Trump’s Anthropic ban exposes Britain’s AI dependence.
This strategic analysis was written by Resultsense, a UK-focused AI news and analysis publication. We will be watching whether the assessment, when it reports, contains a definition of acceptable dependency or only a number. Read more analysis at Insights, or get in touch.