In one paragraph
Two questions decide whether an organisation's AI third-party risk work is real. The first is what it actually depends on, which is rarely the vendor named on the invoice. Beneath most AI products sits a foundation model from somebody else, and beneath that an infrastructure provider, and the concentration that matters usually lives two layers down where nobody is looking. The second question is whether the organisation is a deployer, or has become a provider without noticing. Under EU AI Act Article 25 that transition happens through three ordinary commercial acts: putting your brand on a system, modifying it substantially, or changing what it is for. None of them feels like a regulatory event at the time. Both questions are answerable with a due diligence process, and the reason most AI vendor questionnaires answer neither is that they were adapted from information-security templates predating the value chain they are now being asked to describe.
The dependency you actually have
An AI vendor relationship is at minimum three-layered. The application vendor you contracted with. The foundation model underneath it. The infrastructure underneath that. Your contract, your due diligence and your exit plan typically address only the first.
Three consequences follow, and each has a register entry.
Provenance stops at the vendor. Third-party model and dataset provenance is the risk that you cannot say what model your system actually runs, what it was trained on, or whether that changed last month. A vendor who cannot answer for their own upstream is usually reporting a gap, and not being evasive. It is still your exposure.
Concentration is invisible at the layer you can see. Two suppliers built on the same foundation model are one dependency wearing two coats. An assessment counting vendors will report healthy diversification for a portfolio with a single point of failure. That is what vendor concentration and exit strategy gap describes, and it is materially worse in AI than in conventional software because the number of viable foundation model providers is small.
Your vendor's vendors are your exposure. Sub-outsourcing visibility is a familiar problem in regulated third-party management and an unfamiliar one in AI procurement, where the chain is often assembled faster than it is documented.
For UK regulated firms there is a further wrinkle worth stating plainly. The critical third parties regime that went live in July 2026 designated four cloud providers. It designated no AI providers, and HM Treasury declined in April to commit to changing that before the end of 2026. Designation of your cloud provider transfers nothing: regulated firms remain responsible for their own third-party arrangements. See financial services.
The transition nobody notices
EU AI Act Article 25 sets out when a distributor, importer, deployer or other third party is considered a provider of a high-risk AI system, taking on the provider's obligations in full. Three routes, and all three are things organisations do routinely.
Putting your name or trademark on a high-risk system already on the market. Subject to contractual arrangements allocating obligations otherwise, which is precisely why the contract matters more than it appears to.
Substantially modifying it, in a way that leaves it high-risk.
Modifying the intended purpose, including of a general-purpose AI system not originally classified as high-risk, such that it becomes high-risk under Article 6.
That third route deserves emphasis, because it catches organisations who believe they bought a general-purpose tool. Take a general-purpose assistant and point it at CV screening. You have not merely used it in a new way. You may have changed its intended purpose into a high-risk one, and become its provider.
Article 25(2) then makes the original provider's position explicit. They cease to be the provider of that system, and must cooperate closely with the new provider, making available the necessary information and reasonably expected technical access and assistance. That duty falls away if they clearly specified that their system is not to be changed into a high-risk one, which is a specification you should expect to find in terms of service and should check for before assuming cooperation.
Article 25(4) is the operative clause for procurement. A provider of a high-risk system and a third party supplying components must agree in writing the necessary information, capabilities, technical access and assistance needed to comply. Free and open-source tools are excluded, and the AI Office may develop voluntary model contract terms.
So determine, per system, in writing, whether you are deployer or provider. Re-determine it whenever somebody rebrands, fine-tunes, or repurposes. That determination belongs in the due diligence record and not in somebody's head.
What you are entitled to ask for
Here AI due diligence can be sharper than general third-party risk work, and here most questionnaires leave value on the table.
Since 2 August 2025, providers of general-purpose AI models have been obliged under Article 53(1)(b) to draw up and maintain documentation for downstream providers who integrate the model into their systems, meeting the requirements of Annex XII. That annex functions as a list of things you can ask for by name:
- The tasks the model is intended to perform, and the types of system it can be integrated into
- Acceptable use policies
- Release date and distribution methods
- How the model interacts with external hardware or software
- Relevant software versions
- Architecture and number of parameters
- Input and output modality and format
- Licence terms
- The technical means required for integration
- Modalities, formats and maximum sizes, including context window
- Information on training, testing and validation data, including type and provenance, and curation methodology
Separately, providers of high-risk systems owe deployers instructions for use under Article 13. That is what makes an Article 27 impact assessment completable, so it is a procurement dependency and not a documentation one.
The change this makes to a due diligence conversation is one of posture. "Please describe your approach to training data" invites a marketing paragraph. "Please provide the Annex XII information on training, testing and validation data, including provenance and curation methodology" asks for a document the provider is already required to hold. A vendor who cannot produce it has told you something specific.
Two caveats, stated so the article does not oversell. The Annex XII duty runs to downstream providers integrating the model, and not to every purchaser of every AI-enabled product. A firm buying a finished SaaS product is not automatically its recipient. And the free and open-source exemption from Article 53(1)(a) and (b) applies unless the model is classified as having systemic risk. Where the duty does not reach you directly, the list remains the right specification for what good looks like. You are asking commercially instead of citing.
Four questions a generic security questionnaire never asks
Assume the standard controls coverage: certifications, breach history, encryption, sub-processors. These four are the AI-specific additions that change decisions.
What model is underneath this, and how will we be told when it changes? Not "do you use AI" but the specific model, version, and the notice period for a change. A vendor who updates the model beneath your validated workflow without telling you has broken your change control, and most contracts are silent on it.
What happens to our data, specifically in relation to training? Whether inputs are used for training, whether retention differs between the vendor and the model provider underneath, and whether an enterprise agreement upstream actually covers you. This is frequently where the contract and the technical reality diverge.
Can you provide the Annex XII documentation, and if not, why not? The answer is informative either way.
If you disappeared in ninety days, what would we do? Portability of prompts, evaluation sets, fine-tuned artefacts and retrieval corpora, and whether an equivalent model exists to move to. Exit strategy and concentration management is the control, and the AI-specific difficulty is that "equivalent model" does a great deal of work. Behaviour is not portable across models even where the interface is.
The third-party model due diligence control is where these belong, and the AI vendor due diligence risk is what their absence describes.
Provenance as a technical control
Asking about provenance and verifying it are different activities, and the second is where the supply chain risk actually lives.
Training data provenance checks matter where you fine-tune or supply data, because at that point you have joined the supply chain instead of merely consuming it.
Model artefact signing and integrity verification matters wherever you self-host, because it proves the artefact you deployed is the one you assessed. A model pulled from a public repository, unverified, is an unreviewed dependency with network access. Think of it as the AI equivalent of an unpinned package, with a larger blast radius and less mature tooling.
Both are ordinary supply-chain hygiene applied to a new artefact type. Neither is exotic. Both are routinely absent.
What to evidence
For a governance function, five artefacts carry the weight.
- The provider or deployer determination per system, with reasoning and a date, re-examined on rebranding, fine-tuning or repurposing.
- The dependency map to the model layer, and not the vendor layer, including which vendors share an underlying model.
- The Annex XII request and its response, including non-responses.
- The data-and-training position, reconciled between contract and technical reality instead of taken from either alone.
- The exit plan, with the portability question answered concretely.
The third-party governance hub covers the wider programme this sits inside, and the third-party risk glossary entry the underlying concept.
The recurring failure here is not weak questions. Answers get collected once, at procurement, for a relationship whose most behaviour-determining component then changes without notice. Due diligence that is never repeated describes a system that no longer exists.