Third-party AI governance: the SS2/21 lens, applied to vendors and models.
Almost no organisation trains its own foundation model — AI risk is very often a vendor's model, not yours. 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 don't control.
Last reviewed: 2026-07-29
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.
Everything tagged with this lens.
Pulled live from the library — assembled by the third-party facet, not a hand-maintained list.
4 risks
1 glossary term
Frequently asked questions
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.