The chain is longer than the contract
An AI vendor relationship is at minimum three-layered: the application vendor you contracted with, the foundation model underneath, and the infrastructure underneath that. Due diligence, contracts and exit plans typically address only the first.
That gap produces a specific failure that conventional third-party management does not: an assessment can be thorough, current and complete, and still be an assessment of the wrong entity.
Concentration hides a layer down
Two suppliers built on the same foundation model are one dependency wearing two coats. An assessment that counts vendors will report healthy diversification for a portfolio with a single point of failure, and the number of viable foundation model providers is small enough that this is common rather than exotic.
For UK regulated firms there is a further wrinkle: the critical third parties regime, whose rules have applied since January 2025, made its first designations in July 2026: four cloud providers, not AI providers, and designation transfers no responsibility: firms remain accountable for their own third-party arrangements. See financial services.
The exposure categories
Four, and they are not interchangeable:
- Security: a vendor breach becomes your incident, and the AI-specific surface includes the retrieval index and the model artefact as well as the usual estate.
- Compliance: a partner who cannot produce documentation you are obliged to hold blocks your compliance, not theirs. The clearest case is a provider's Article 13 information package, without which an Article 27 impact assessment cannot be completed.
- Performance: undisclosed model quality, and quality that changes without notice when the provider updates.
- Operational: dependence, discontinuation, and the fact that behaviour does not port across models even where interfaces do.
When using a system makes you its provider
Distinctive to AI, and easy to miss. Under EU AI Act Article 25, putting your name or trademark on a high-risk system, substantially modifying it, or changing its intended purpose can make you its provider, taking on the provider's obligations in full. Point a general-purpose assistant at CV screening and you may have done the third of those.
The instruction is to determine, per system, in writing, whether you are deployer or provider, and to re-determine it whenever someone rebrands, fine-tunes or repurposes. Third-party AI risk in full covers the mechanics.
Knowing what the system is made of
Due diligence on an AI supplier increasingly asks for a machine-readable inventory of what the system contains: models, datasets, adapters, libraries and where each came from. CycloneDX and SPDX both define formats for it, and in May 2026 CISA and its G7 partners, including the UK, published voluntary minimum elements for a software bill of materials for AI. Asking a supplier for one is now a reasonable contract term.
For general-purpose models, the EU AI Act's provider documentation duties give the same request a legal footing; see general-purpose AI model and provider and deployer. Downloaded models need the same scrutiny as downloaded code, because some model file formats can run code when they are loaded. Model artefact signing and integrity verification is the control.
Mitigating it
Vendor assessment that reaches the model layer; contractual requirements including notice of model change; ongoing monitoring rather than a procurement-time snapshot; and a tested route to an alternative. The controls are third-party model due diligence and vendor exit strategy and concentration management; the register entries are provenance, inadequate due diligence and sub-outsourcing visibility.
The recurring failure is not weak questions. It is that answers collected once at procurement describe a system whose most behaviour-determining component changes without notice.