Plan on the assumption that any AI model you depend on could be changed, delayed, restricted or withdrawn by its provider or by a government. Boards should know which processes rely on which model, require notice and exit terms in contracts, and keep a tested fallback for anything critical. Model access is now a supplier continuity risk.
Governments are now involved in who can use frontier AI models, and when. This article sets out what that means for a business that builds on those models. It is governance guidance, not legal advice.
Why is model access now a board-level risk?
Because the model is increasingly a single point of failure. Many organisations now run customer service, document review, coding or analysis on one provider’s model, often reached through a vendor’s product rather than a direct contract. If that model changes behaviour, is withdrawn, is priced differently or becomes unavailable in a jurisdiction, the process that depends on it changes too.
Governments have also taken a direct interest in the most capable models. In the United States, Executive Order 14409, “Promoting Advanced Artificial Intelligence Innovation and Security”, signed on 2 June 2026, set up a voluntary framework under which developers of “covered frontier models” can give federal agencies access for up to 30 days before release to other trusted partners (The White House, 2 June 2026; Federal Register, 5 June 2026). The order states that it does not authorise any mandatory licensing, preclearance or permitting requirement. The point for boards is not the detail of one order. It is that release timing and access to the most capable models can now be shaped by national security processes, as well as by the provider’s commercial choices.
What can actually change, and how would you notice?
Five things, and in most organisations nobody is watching all of them:
- Availability. A model version is retired, delayed or not offered in a market you serve.
- Behaviour. An update changes outputs, refusals or accuracy, and a process that worked last month quietly degrades.
- Terms. Pricing, usage limits, data handling or acceptable use policies change on notice you may not have negotiated.
- Access conditions. Advanced capabilities are released first, or only, to vetted partners.
- Supply chain. Your vendor switches the model underneath its product without telling you.
The last is the one boards most often miss. Your contract may be with a software company, but your exposure is to the model provider behind it, and sometimes to several.
How should the board classify its exposure?
Map each AI-dependent process against two questions: how critical is it, and how easily could it switch to another model? That gives a simple view of where to act first.
| Exposure | What it looks like | Board expectation |
|---|---|---|
| Critical and locked in | Core operation built on one model, with no tested alternative | Fallback designed and tested; exit terms in contract; reported to the board |
| Critical but portable | Core operation, alternative model tested and approved | Regular switch test; change notice required from vendor |
| Non-critical and locked in | Productivity use tied to one provider | Accept the risk knowingly; review at renewal |
| Non-critical and portable | Assistive tools with several options | Normal supplier management |
What should contracts and architecture require?
Contracts should require the vendor to name the model providers it relies on, give advance notice of material model changes with the right to test first, and support export of your data, prompts and configuration at exit. These terms are far easier to win before signature than after an incident.
Architecture matters as much as paper. Where a process is critical, ask whether it could run on a second model with acceptable performance, and whether anyone has tried. A fallback that has never been tested is a hope, not a plan. Keep evaluation sets, the examples you use to check that a model still performs, so a change can be detected and a replacement can be judged quickly. Open-weight models are one route to that independence; our guide to open-weight and closed models sets out the trade-offs.
Finally, assign ownership. Someone should be responsible for tracking model and policy changes that affect the business, in the same way a treasury team watches currency risk. Without an owner, changes are found only when a process fails.
What should the board ask management?
- Which of our critical processes depend on a single AI model, directly or through a vendor?
- Do our contracts name the model providers behind each AI product, and require notice of changes?
- If our main model became unavailable tomorrow, what would stop, and for how long?
- Have we tested a switch to an alternative for anything critical?
- Who monitors model changes, policy changes and access restrictions that affect us?
Model concentration sits alongside data and security risk; our article on why data governance belongs to the board covers the related exposure in the data you send to these providers.
Where to start
Start with a map of which processes depend on which models, including those hidden inside vendor products. Our briefing on AI vendor due diligence and the questions vendors hope you won’t ask sets out the 24 questions, the red flags and six contract clauses, including model change notice and exit. The step on the AIPEX roadmap for most boards here is Step 2, Assess: the AI Readiness Assessment (£999 + VAT) shows where your risk sits when you buy AI from vendors, with a prioritised plan and a 60-minute debrief.
Frequently asked questions
Why is AI model access a continuity risk?
Many processes now depend on one provider's model, often reached through a vendor. If that model changes behaviour, is withdrawn, is repriced or becomes unavailable in a market, the dependent process changes too. Governments also now take an interest in release timing for the most capable models.
What should AI contracts say about model changes?
They should require the vendor to name the model providers it relies on, give advance notice of material model changes with the right to test first, and support export of your data, prompts and configuration at exit. These terms are easier to win before signature.
How do you reduce dependence on a single AI model?
Map which processes depend on which models, including those inside vendor products. For critical processes, test a second model, keep evaluation sets to detect changes, and document a fallback. A fallback that has never been tested should not be relied on.
Correct as of 28 September 2026. This content reflects the law, official guidance and deadlines as published on that date. The EU AI Act and its guidance, standards and deadlines are still being amended and clarified. If you are reading this after 28 September 2026, check for later amendments, European Commission guidance and harmonised standards before relying on it. It is general information, not legal advice, and AIPEX accepts no liability for decisions taken on it without specific professional advice.