Most organisations now buy “AI capabilities” as a bundle: model, API, orchestration, data services, often from different vendors and sub‑processors. When a failure occurs—IP infringement, biased decisions, data leakage—the investigation usually discovers one thing: nobody had really understood the AI supply chain they’d just outsourced.

That is the core of an opaque AI vendor supply chain: inherited model, data and operational risk from suppliers you barely see, let alone govern. For risk and audit leaders, this undermines assurance, complicates regulatory accountability, and makes it very hard to evidence that “reasonable due diligence” was performed over AI components.

The primary safeguard is disciplined third‑party AI due diligence, backed by AI‑specific liability clauses in contracts. Due diligence should cover model lineage, training data sources, bias and drift monitoring, incident processes, and sub‑processor chains—not just generic security questionnaires. Contracts then need to allocate responsibility for model errors, IP infringement, data breaches and regulatory sanctions, through warranties, indemnities, audit rights and clear scopes of liability.

Technically, many of these expectations are now reflected in the platforms themselves. Azure AI Foundry and Amazon Bedrock expose model catalogues, version histories, usage logs and monitoring dashboards that can be tied to vendor commitments on transparency and incident response. Governance teams should be asking: does the contract require access to model cards, event logs, and drift alerts, and is that access configured in workspaces and role‑based policies so it’s actually auditable?

For boards and EXCOs, two questions follow: Who in your organisation “owns” third‑party AI due diligence end‑to‑end? And would gaps in your AI supply chain be discovered by your monitoring—or by a regulator, plaintiff, or journalist?