AI third-party risk: the vendor you contracted with is rarely the dependency you have.
Almost no organisation trains its own foundation model, so AI risk is very often a vendor's model rather than yours. Underneath the application vendor sits a foundation model from somebody else, and underneath that an infrastructure provider, and the concentration that matters usually lives two layers down. This hub assembles everything on the site tagged with the third-party lens: the risks, controls and terminology that apply whenever governance, compliance, security or engineering responsibility depends on a party you do not control. For the mechanics of a due diligence process, including what the EU AI Act already obliges a provider to give you, see model provenance and vendor due diligence.
Last reviewed: 2026-10-07
Looking for AI used in third-party risk management? This page is about the third-party risk of AI. For what AI tools can and cannot do for the TPRM function itself, see AI in Third-Party Risk Management.
Four pillars, one dependency.
Third-party AI risk isn't a fifth concern alongside the pillars — it's each of the four, applied to a system you don't fully control.
Governance
Who owns the vendor relationship, who signs off on onboarding a new AI model or platform, and whether that accountability survives the vendor changing its own terms.
Compliance
Obligations that flow through to you regardless of who runs the model — data protection, the EU AI Act, and sector rules don't stop at the API boundary.
Security
A third-party model or platform's attack surface becomes yours the moment you integrate it — provenance and supply-chain assurance, not just uptime SLAs.
Engineering
Whether the AI you depend on is mapped into your important-business-service inventory, with a tested impact tolerance for when the vendor fails.
What AI-specific due diligence checks.
Extending the SS2/21 discipline most firms already run for material outsourcing, not replacing it.
- Model and dataset provenance: where the training data came from, and whether the vendor can actually answer that question.
- Sub-outsourcing visibility: what the vendor itself outsources, and whether you have visibility into that chain, not just the vendor you signed a contract with.
- Concentration and exit: what happens if this vendor becomes unavailable, and whether an exit plan exists before you need one.
- Contractual assurance: audit rights, incident-notification obligations, and data-handling terms specific to AI, not a generic outsourcing template.
Long-form analysis on this
Articles that work through the practice rather than catalogue it.
AI in Third-Party Risk Management: What It Automates, and What It Cannot
Most of what AI does in third-party risk management is labour: reading evidence, pre-filling questionnaires, watching for change. That is worth having. What it cannot do is accept a risk, and the model inside your TPRM tool is itself a third party.
Third-Party AI Risk: Model Provenance and Vendor Due Diligence
Most AI vendor questionnaires are security questionnaires with "AI" added to the headings. The useful version asks for the specific documentation the EU AI Act already obliges the provider to hold, and establishes in writing whether your own configuration has quietly made you the provider.
Everything tagged with this lens.
Pulled live from the library — assembled by the third-party facet, not a hand-maintained list.
4 risks
Frequently asked questions
What is AI TPRM?
AI third-party risk management is the discipline of assessing and monitoring the AI vendors, models and infrastructure an organisation depends on but does not control. It differs from general third-party risk management in what it has to establish: which model actually sits underneath the product, what happens when the vendor changes it, whether two suppliers share one foundation model, and whether your own configuration has quietly made you the provider rather than the deployer.
Why does third-party AI governance need its own hub instead of being one topic under Governance?
Because it genuinely cuts across all four pillars — governance of the vendor relationship, compliance obligations that flow through the vendor, security of a third-party model or platform, and the operational-resilience discipline of knowing what happens if the vendor fails. A single-pillar page would force an artificial split.
What is SS2/21 and why does it matter for AI vendors?
The Bank of England PRA's supervisory statement on outsourcing and third-party risk management. It already tells firms what due diligence looks like for material outsourcing, including cloud and new technology — AI vendor risk is that same discipline applied to AI specifically, not a new framework.
What should AI vendor due diligence check that generic vendor due diligence might miss?
Model and dataset provenance, sub-outsourcing visibility (what the vendor itself outsources), concentration risk and exit planning, and contractual terms — audit rights and incident notification — written for an AI system specifically, not adapted from a generic outsourcing template.
This is one of the areas Andrew advises on.
Third-Party & Operational Resilience Risk is one of five areas of expertise on the services page, grounded in exactly this SS2/21 discipline.