Here is a question I think every board using AI should ask: what would happen to our business if we could no longer use our main AI provider?
Not because the model was having a bad afternoon. Because somebody, somewhere, had decided that the provider could no longer serve us.
The US sanctions on the International Criminal Court prompted this thought. If American AI has become part of how we write code, serve customers, analyse information and get work done, access is now a business dependency. It deserves the same attention as any other important supplier.
I am not predicting that the US will switch off Britain's AI. I am asking whether we have built businesses that could cope with a loss of access. Those are different questions.
Research checked on 12 October 2026. This is a governance thought experiment, not a prediction, legal opinion or investment recommendation.
What actually happened?
On 9 October 2026, the US Treasury added the ICC itself to its sanctions list. That is a real institutional designation, not merely a rumour about individual officials. But the same announcement included licences. We need to read those too. OFAC announcement.
General Licence 13 permits specified maintenance and wind-down transactions until 7 April 2027. General Licence 14 authorises certain telecommunications, internet-communications and enterprise-software transactions involving the ICC, subject to its conditions and other applicable laws. That is not the same as every American software service immediately going dark. Nor does it settle whether a particular AI service qualifies: that needs product-specific legal assessment. Licence 13; Licence 14.
The underlying emergency-powers law, IEEPA, requires a declared national emergency concerning an unusual and extraordinary threat with a substantial foreign source. It is not an unrestricted permission to ban anything on a whim. The authority, wording, exceptions and legal challenges to any order matter. IEEPA statutory text.
Then there is Anthropic. In March, the company described a US government dispute involving federal use of its technology and a military supply-chain-risk designation. A district court issued a preliminary injunction on 26 March against the challenged measures. It did not require the military to use Claude. This is a dated, contested legal episode, not a settled finding about the government's powers today, and not evidence that Britain was cut off from Claude. Anthropic's account; court order.
My conclusion is narrower, but still important: political decisions can reach into technology relationships. Commercial usefulness does not make a supplier relationship immune.
Which switch-off are we testing?
“All AI traffic to the UK” sounds like one switch. It is not. A restriction on US-provided services would not automatically stop a lawfully held model already running on independent British hardware.
For a board exercise, I would separate three scenarios:
- Our organisation loses access. A designation, contract suspension or compliance decision affects us, even if everyone around us can continue working.
- A particular provider or service becomes unavailable. Our model endpoint, account or cloud integration stops working. Other services may remain available.
- A broad UK restriction affects several US services together. This is the deliberately severe geopolitical stress case, not an announced policy or a probability estimate.
A UK-and-EU restriction would be a separate, larger scenario. Do not quietly use the combined market to calculate a UK-only loss.
The narrower scenarios are already enough to justify doing the work. We do not need to believe in the most dramatic version before asking who would answer customers, finish the release or process the backlog if the AI stopped.
The quarter-of-revenue question
The report behind this article suggested the UK and EU together might represent around a quarter of some providers' revenue. That is an estimate, not an audited disclosure. It is not a claim that the UK alone supplies a quarter.
Its regional estimates use proxies such as website visits and counts of companies using a product. Those are interesting clues, but visitors are not paying customers, company counts are not spending, and an API contract is not a visit to a chatbot website. The EEA is also not identical to the EU.
I could not verify a reliable current UK-versus-EU revenue breakdown for OpenAI, Anthropic or xAI from the sources reviewed. So I am not going to dress an assumption up as a financial fact.
| Provider | What we can use | What remains unknown here |
|---|---|---|
| OpenAI | Axios: $50bn annualised, 8 October 2026. | Verified current UK and EU revenue shares. |
| Anthropic | The company said its run rate exceeded $47bn in May. A dated company disclosure, not an October estimate. Series H announcement. | A verified current regional split. Do not apply an older geographical mix automatically to today's business. |
| xAI / Grok | No sufficiently reliable comparable revenue base verified in this review. | Both the relevant revenue base and its UK/EU allocation. |
Annualised revenue extrapolates a period's sales rate. It is not cash already earned over a full year, and it is certainly not profit. The examples above come from different dates and are not a like-for-like ranking.
We can still test the economics without pretending we know the missing shares.
| Assumed share lost | Annual exposure | One-month exposure |
|---|---|---|
| 5% | $50m | About $4.2m |
| 10% | $100m | About $8.3m |
| 25% | $250m | About $20.8m |
The calculation is revenue multiplied by the assumed affected share; the monthly column divides that by twelve. It assumes steady sales, complete loss of those sales and no recovery, substitution or offsetting demand. A short interruption, a partial restriction and a permanent market exit would produce different results.
The point is not that 25% is correct. It is that losing a material market would be expensive, even before we considered what other customers might do next.
What would it do to the providers?
I would expect providers to have a strong commercial incentive to preserve access, seek lawful licences where available and maintain customer confidence. But an incentive is not a guarantee. A business cannot simply ignore an applicable legal restriction because the customer is valuable.
The financial impact also depends on the costs they can stop. Less inference can mean less variable computing expenditure. Spare capacity might find another buyer. Those are possible offsets, not evidence that the loss would be painless.
Other commitments do not necessarily disappear. For example, Akamai announced an $11.6bn contractual commitment from Anthropic over seven years in September. That is one infrastructure relationship, not a complete cost base or proof that every obligation is non-cancellable. It does show why revenue, capacity and long-term commitments need to be considered together. SEC-filed announcement.
Here is a deliberately fictional example. A provider earns $100m, spends $40m in variable costs and $50m in fixed costs: it has $10m left. Lose 25% of sales, let variable costs fall proportionately to $30m, and keep fixed costs at $50m: it now loses $5m. That is an explanation of operating leverage, not anybody's actual accounts.
What about money invested from other countries? OpenAI's February investment announcement included $30bn from SoftBank within a larger round. International capital is part of the picture. It does not itself give British customers a right to continued service or exempt the provider from US law. OpenAI's announcement.
Investors might revise expected growth, future funding terms or the value they put on the company. Equity investment is not an ordinary customer refund: a sales decline does not automatically require the provider to repay it. Any financing consequences would depend on the actual agreements. I have not inspected those private agreements.
The longer-term commercial risk could be confidence. If a multinational decided that a service could not be relied on in one of its markets, it might move more of its global work elsewhere. Other countries might accelerate their alternatives. That is my scenario analysis, not a measured loss or a forecast that every customer would leave.
So yes, a restriction could hurt the American suppliers too. But “they would lose money” is not a business-continuity plan for us.
What stops in a British business?
The answer depends on what we have allowed AI to become.
If it helps someone draft a presentation, we have a productivity problem. If an agent triages customer requests, changes code, reads documents or prepares operational decisions, we may have a service problem. If nobody can perform or review the work without it, we have a much bigger dependency.
I would map the business outcome, not just the chatbot subscription:
- People: who can take over, and how much work can they realistically handle?
- Information: can we retrieve our documents, decisions and audit history without the original account?
- Tools: which workflows depend on the model, the agent harness, cloud search, identity, payments or a remote licence check?
- Customers: what service can we still deliver, and what do we need to tell them?
Loss of access is not automatically deletion of data. But information that exists somewhere we cannot access is not much use during an incident. Keep lawful, secure, tested exports of the material needed to continue.
The replacement may also be slower or less capable. That is acceptable if we deliberately reduce the workload. It is not acceptable if we silently put a weaker model in charge of the same high-consequence decisions and hope nobody notices.
What the regulators actually say
There is a tempting shortcut here: “The FCA and PRA already say everything critical must be British or European.” The guidance reviewed does not say that.
The PRA's SS2/21 explicitly rejects interpreting its expectations as a demand for restrictive data localisation. It instead considers jurisdiction and location risk, and expects documented, appropriately tested stressed-exit arrangements for material outsourcing. This is guidance for firms within its scope, not a nationality rule for every business. See paragraphs 7.7–7.8 and chapter 10. Current SS2/21.
There is a date trap too. On this article's research date, the November 2024 version is current. The March 2026 revision takes effect on 18 March 2027. A newer publication date does not necessarily mean a rule is already in force. PRA version history.
For firms in scope, FCA SYSC 15A covers important business services, impact tolerances, dependency mapping and testing severe but plausible disruptions. The scenarios include unavailable critical third-party services. FCA cloud guidance also addresses jurisdiction, political stability and effective regulatory access. Neither is a blanket ban on US AI. SYSC 15A; FG16/5.
I would borrow that discipline even in a company outside financial regulation. That is my recommendation, not a claim that these financial-sector requirements legally apply to everybody.
Are Mistral, Cosine and the alternatives ready?
Ready for what? A useful drafting assistant, a coding agent and a production-critical service are not the same requirement. None of the products below has been certified by this article as a drop-in replacement for your business.
| Option | Available route | Important boundary |
|---|---|---|
| Mistral: existing open weights | Mistral Large 3 and the smaller Ministral 3 family were released under Apache 2.0. A candidate for controlled self-hosting. Release. | Match model size to hardware, capacity and task. Large 3 is not a laptop-sized fallback. You still need an operated, secure service. |
| Mistral Large 4 | Public API preview announced on 6 October. Mistral says the preview is served on its own European infrastructure. Announcement. | Weights are promised for the end of October, not already available at this research date. Do not make a future download your current exit plan. |
| Cosine / Lumen Sovereign | Cosine offers controlled engineering evaluation and deployment support. Its sovereign FAQ describes air-gapped deployment paths. Vendor detail. | Lumen Sovereign is still “coming soon”. This is a coding-focused candidate to evaluate, not a proven general-purpose replacement today. |
| Cohere: private | Documented private-cloud and on-premises options, including air-gapped environments. Deployment documentation. | Contract, licence, updates and hardware need checking. A deployment on a US-controlled cloud still requires that cloud's risk assessment. |
| Scaleway Generative APIs | A managed inference route. Its FAQ says serverless models currently run in Paris; its policy says it hosts the models without third-party inference services. FAQ; Policy. | European hosting is evidence about this service, not immunity from every disruption. Check the selected model's licence, contract, throughput and dependencies. |
My answer on Mistral is yes: it is a serious option to test now. My answer on Cosine is that it deserves attention, particularly for controlled software engineering, but I would not write “our fallback is Lumen Sovereign” while its own page says it is coming soon.
For many businesses, the sensible first step is not replacing everything. Pick one important but bounded workflow and prove that it can operate elsewhere. Document what the alternative cannot do as carefully as what it can.
Two suppliers can still be one dependency
Switching model brands can reduce a single-company failure risk. It does not necessarily remove a shared jurisdictional exposure.
Likewise, a different reseller does not necessarily mean a different underlying model or operator. “We have two contracts” is not the end of the investigation.
I would ask four separate questions: where does the processing happen, who controls the service, what permits us to run the model, and what other systems must remain available?
A British data centre running an externally controlled API is different from a British deployment holding licensed model files and able to continue without that API. Conversely, downloaded weights are not magic sovereignty. Remote authentication, cloud keys, updates, support and other dependencies may still matter.
For self-hosting, verify the exact licence and version, retain the required artefacts securely, and test operation without essential external calls. Do not assume that an open-weight label grants every commercial right or guarantees an independent runtime.
This is about lawful continuity. It is not a suggestion to route around sanctions, disguise a customer or bypass a provider's restrictions.
A board plan you can actually test
Here is the work I would put in front of the board. The timetable is my suggested starting exercise, not a regulatory deadline.
- First week: find the important services. Name their owners, the AI dependencies, the legal entities involved and the amount of disruption the business can tolerate. Distinguish essential operations from helpful experiments.
- Second week: prove portability. Retrieve the necessary data, policies, prompts, tool definitions and records. Check confidentiality, intellectual-property rights and retention rules before transferring anything. Test that another team can actually use the export.
- Third week: qualify a fallback. Run representative cases, difficult edge cases and permission checks. Measure accuracy, latency, throughput, cost and recovery time. Agree what must pause or return to human review if capability drops.
- Fourth week: rehearse loss of access. In a controlled test, make the primary service unavailable. Include dependent identity and cloud services where the scenario calls for it. Test the alternative with the same approved workload and record the evidence.
- Then maintain it. Give someone ownership of the fallback, capacity and contracts. Retest after material changes. Record who may declare an incident, approve the switch and restore normal operation.
Have legal counsel assess the actual restriction and available licences. Have security assess the proposed deployment. Keep permissions and human approvals in place during failover. An emergency is not permission to let an agent send payments, expose data or change production without authority.
I would also price the plan honestly: migration work, duplicated capacity, licences, testing, support, people and reduced productivity. Self-hosting moves responsibility onto us. It does not make computing free.
If the answer is that our team could continue manually for two days, show me the capacity calculation. If the answer is that we can change models in an hour, show me the last exercise. Plans become useful when we can inspect what actually happened.
Use the tools. Keep the option to leave.
I am not saying stop using American AI. Some of these tools are extraordinarily useful. I use them, and I want businesses to benefit from them.
I am saying that the more useful they become, the less sensible it is to rely on access we have never planned to lose.
A major restriction could damage the providers' revenue, their investment story and their relationships with international customers. That gives them reasons to resist disruption. It does not protect our business on the morning access stops.
Use the best tools for the work. Keep control of the information you need. Qualify another route. And test it.
That is not being anti-American or anti-AI. It is what good governance looks like when intelligence becomes part of the infrastructure.
Sources and limits
The links above lead to official sanctions documents, statutory text, a court order, regulator publications and vendor documentation. Product and funding announcements are claims by their issuers, not independent performance audits. The OpenAI revenue entry is attributed secondary reporting.
The supplied report was used to frame the questions, not as proof of its regional revenue estimates. No precise UK/EU split, probability of a broad cutoff, provider insolvency forecast or legal-compliance certification is claimed. The financial examples and four-week board exercise are explicitly illustrative.
Availability and law can change. Recheck the actual order, applicable guidance version, selected service and contract before making an operational or investment decision.