Supply-chain sovereignty: knowing and controlling what your AI depends on

What does supply-chain sovereignty cover?

It is one of the seven kinds of sovereignty on the Sovereign Intelligence map, alongside data, infrastructure, model, intelligence, operational and governance sovereignty. Its scope is four things: vendors, models, infrastructure and critical dependencies.

The other six kinds describe what you control inside your own estate. This one describes what you depend on outside it. An organisation can run its own agents on its own hardware and still be fragile if one model provider, one inference library or one managed vector database sits underneath everything and can change terms, price or availability on its own schedule.

The brief for the platform is plain: you can see which suppliers and components your AI depends on, and change them without rebuilding. Both halves matter. Visibility without the ability to change is a report. The ability to change without visibility is luck.

• Vendors: model providers, cloud and GPU providers, SaaS tools the agents call, integration and data vendors, and the sub-processors behind each of them.
• Models: the specific model families and versions in use, where each is hosted, under what licence or contract, and with what known data provenance.
• Infrastructure: accelerators, regions, networking, orchestration layers and the inference engines that serve models.
• Critical dependencies: anything whose failure or withdrawal stops a business process. This includes open-source libraries, container registries and identity providers as well as commercial suppliers.

What is an AI bill of materials, and why build one first?

A bill of materials lists every component a product is built from. Software teams already keep them for code. An AI bill of materials (AI-BOM) extends the idea to the parts that make an AI system behave the way it does: the models, the data and context that feed them, the libraries that serve them and the providers that host them.

You cannot reason about supply-chain risk without one. Most organisations discover, when they first try to write it, that nobody holds the whole list. Teams adopted tools one at a time, and the list lives in many heads. The shadow AI analysis describes how that happens, and the AI estate inventory post shows how to start.

Keep it machine-readable and keep it owned. A spreadsheet that one person updates quarterly will be wrong within a month. The better pattern is for the platform that runs your agents to emit the inventory as a by-product of operating them. That is the idea behind the Trust Profile: each AI system records its approved models, permitted systems and policy set, so the bill of materials is a query, not a project.

How do you measure concentration risk?

Concentration risk is the share of your AI activity that would stop, or degrade badly, if one supplier disappeared. It is easy to underestimate because AI stacks are layered. Three agents might each use a different front-end tool and still all call one model provider, which all runs on one cloud region.

Work down the layers and count, at each one, how many production workflows share the same supplier. You are looking for single points of failure, not for a particular number. If one answer is "everything", that layer is where a substitution test belongs first.

1. List your production workflows and agents from the AI-BOM.
2. For each one, record its model provider, hosting provider, region, inference engine and critical tools.
3. Group by supplier at each layer and mark every layer where a single supplier carries most of the workload.
4. For each marked layer, write down what happens on the day that supplier changes price, changes terms, degrades or is withdrawn.
5. Rank by business impact and by how long a substitution would take today.

Vendor change events are not hypothetical. A recent write-up on a frontier model that was available for only six days is a useful case study in how quickly a model dependency can move, and in why behaviour monitoring matters when the model underneath you is not yours. The cost side is covered in the model exit-cost audit framework.

What should you know about the provenance of a model?

Provenance means knowing where a component came from and under what terms you may use it. For a model, ask who trained it, under what licence you may deploy and modify it, what is documented about its training data, and where the weights or the endpoint actually run. For hosted models, also ask which sub-processors touch your prompts and outputs.

• Licence terms: open-weight does not mean unrestricted. Read the use restrictions, the redistribution terms and any size or sector limits before you build on a model.
• Documentation: model cards and technical reports are the minimum. If a supplier will not describe what a model is and how it was evaluated, treat that as a finding. Swfte publishes model cards by intelligence level as one example of what to ask for.
• Hosting location and operator: the same model can be served from very different jurisdictions, with different legal exposure.
• Update policy: does the supplier change the model behind a fixed name? If so, you need your own evaluation set to notice.
• Sub-processors: every hosted dependency has its own suppliers. Swfte lists its own on the sub-processors page, which is currently marked as a draft.

Provenance is also where model sovereignty and supply-chain sovereignty meet. Model sovereignty is about your ability to select, deploy, tailor and retire models. Supply-chain sovereignty is about knowing what each of those choices drags in behind it.

Which European rules already ask about AI dependencies?

Several European instruments push organisations toward exactly this discipline. None of them is an AI supply-chain law, and each applies only to the entities and services it covers, so read the text for your own situation.

• DORA: Regulation (EU) 2022/2554 applies to financial entities from 17 January 2025. It requires a register of information on contractual arrangements with ICT third-party service providers, distinguishing those that support critical or important functions (EUR-Lex text (opens in a new tab)). If an AI provider supports such a function, it belongs in that register.
• Data Act: Regulation (EU) 2023/2854 has applied since 12 September 2025. Its Chapter VI covers switching between data-processing services, including cloud services, and prohibits switching charges, egress for switching included, from 12 January 2027, with reduced cost-based charges until then (overview (opens in a new tab), analysis of the 2027 date (opens in a new tab)). Committed-spend contracts and architectural lock-in are outside the ban, so contract terms still need reading.
• EU Cloud Sovereignty Framework: the European Commission scores cloud services against eight sovereignty objectives, including SOV-5 Supply Chain and SOV-6 Technology, which covers openness, interoperability and mitigation of vendor lock-in (Commission document (opens in a new tab)). It is a useful checklist even if you are not buying under it.

How do you build an exit plan that works?

An exit plan that has never been run is a hypothesis. The goal is not to leave your suppliers. It is to make leaving credible, which is what gives you negotiating room and resilience when something changes.

Design for substitution

• Put a gateway or routing layer between applications and model providers, so a model is a configuration value rather than a code dependency. The model routing guide covers the mechanics.
• Keep prompts, evaluation sets, tool definitions and policies in your own repositories, in portable formats, not inside a supplier console.
• Store embeddings alongside the source documents and the embedding model identifier, so an index can be rebuilt if the embedding provider changes.
• Prefer open protocols at tool boundaries. The Model Context Protocol, for example, now sits under neutral stewardship at the Linux Foundation (announcement (opens in a new tab)).

Test substitution on a schedule

Pick one workflow per quarter. Swap its model for the approved alternative in a staging environment, rerun your evaluation set and record what moved: quality, latency, cost, refusal behaviour, tool-calling accuracy. The point is to learn the real switching cost while nothing is on fire. Teams that do this find that prompts tuned for one model carry hidden assumptions, and that finding them early is cheap.

Write the trigger conditions down

Decide in advance what counts as a reason to switch: a price change beyond a threshold you set, a supplier jurisdiction change, a degraded evaluation score, a security incident, withdrawal of a model version. Triggers agreed in calm conditions prevent arguments in a crisis.

What should a procurement checklist for AI suppliers include?

Use the same questions for every AI supplier, whether it is a model API, a GPU provider or an agent tool. Ask them in writing and keep the answers with the contract. Where a supplier cannot answer, record that too. The buyer-specific lists on the CIO page and the legal and compliance page go further.

1. Which legal entity provides the service, and under which jurisdiction does it operate?
2. Which sub-processors handle our prompts, outputs and logs, and how will we be told when that list changes?
3. Can the service run in a region and on infrastructure we choose, and is that stated in the contract?
4. Will the model version we test be the version we run, and how much notice do we get before a change or withdrawal?
5. In what format can we export our data, configuration, prompts and logs, and what does it cost to leave?
6. What happens to our data and derived artefacts on termination, and how is deletion evidenced?
7. Does the supplier rely on a single upstream model or infrastructure provider that would affect us?
8. Can we obtain audit records and policy decisions in a form we retain and control?

The pattern across all eight is the same: ask what the supplier controls that you cannot see, and what you could do about it. That is supply-chain sovereignty applied to a purchase order. For the deployment decisions that sit behind it, see infrastructure sovereignty and step 2 of the build guide.

How does the Sovereign Intelligence Platform approach this?

The platform is designed so that models, hosting and tools are choices you make and can change. Connect is one API for 50+ model providers with routing, failover and cost tracking, which makes a model a swappable dependency. The Models layer and the Infrastructure layer describe the choices behind that, and dedicated cloud covers isolated deployment options scoped with you.

On the supplier side, Swfte publishes what it can today on the trust centre, including what is still in progress and what it does not claim. Treat that as the standard to ask of any vendor, including us.