Third-Party AI Risk: Why Your Vendor's AI Problem Is Your Problem

AI third-party risk is the dominant risk vector for most enterprises

Most enterprise AI capability is delivered through third parties. OpenAI, Anthropic, Google, Microsoft, AWS, and a long tail of specialist vendors deliver the foundation models, the AI features embedded in productivity software, and the AI tools used by every business function. This means the dominant source of AI risk for most enterprises is third-party AI risk — and most third-party risk management frameworks were not designed for the specific characteristics of AI vendors.

APRA's 30 April 2026 letter to Australian financial services named "supplier concentration and opacity" as one of four critical AI governance gaps in the sector. The observation applies more broadly: most enterprises have material AI dependencies on a small number of vendors whose model behaviour, training data sources, and security controls they cannot directly verify. Traditional supplier risk frameworks built for software-as-a-service contracts do not address model behaviour, training data provenance, or AI-specific incident scenarios.

The unique characteristics of AI vendor risk

AI vendor risk differs from conventional IT vendor risk in several important ways:

Opacity of model behaviour. Unlike traditional software whose behaviour is determined by its code, AI model behaviour emerges from training data and parameters. Vendors typically cannot guarantee specific behaviour, only statistical performance. This makes traditional service level agreements (SLAs) — defined uptime, defined accuracy — difficult to write meaningfully for AI systems.

Concentration risk. A small number of foundation model providers (OpenAI, Anthropic, Google) underlie a large fraction of enterprise AI capability. A single provider's outage, policy change, or security incident has cascading effects across the customer base. This is structural concentration risk that did not exist with diverse traditional software vendors.

Training data provenance. AI vendors trained their models on data they may not own outright. The New York Times v OpenAI litigation (commenced December 2023, proceedings continuing through 2026) and similar cases create downstream uncertainty for vendor customers. If a foundation model is found to have been trained on infringing data, what is the customer's exposure?

Sub-processor opacity. AI vendors typically use multiple sub-processors — cloud infrastructure, evaluation services, data labellers. The full sub-processor chain is often not disclosed at the contract level, creating fourth-party and fifth-party risk that conventional DPAs do not address.

Dynamic behaviour. Unlike traditional software with version control, foundation models are updated continuously. Behaviour observed at procurement may differ materially from behaviour in production. Change management notification provisions in conventional contracts do not contemplate this rate of change.

The regulatory expectations that drive AI third-party risk programmes

Several regulatory regimes now require AI third-party risk management. EU AI Act places obligations on providers and deployers of AI systems — where you deploy a third-party AI system, you may be the "deployer" with your own obligations regardless of the provider's compliance. APRA CPS 230 (Australia, in force 1 July 2025, amendments 1 July 2026) requires regulated entities to identify and manage material service providers, conduct due diligence, embed contractual protections, and maintain business continuity arrangements — applied to material AI vendors. EU DORA (Digital Operational Resilience Act) (in force 17 January 2025) imposes ICT third-party risk requirements on EU financial services entities — including AI vendors as ICT providers. UK FCA SS2/21 and operational resilience requirements apply equivalent expectations to UK financial services. EU NIS2 Directive (applicable 17 October 2024) imposes supply chain security requirements on essential and important entities across multiple sectors.

The contractual provisions AI vendor agreements need

Conventional master services agreements (MSAs) and data processing agreements (DPAs) do not adequately cover AI-specific risk. AI vendor contracts should include:

Training data warranties. The vendor warrants that training data was lawfully obtained, that no infringing material was knowingly used, and that the customer is not exposed to IP claims arising from model outputs. Vendors will not always agree to absolute warranties, but indemnification provisions and IP-related representations are negotiable.

Model behaviour and change notification. Defined notification before material model updates, version control where possible, and rollback rights where customer use cases would be materially affected. This is harder to negotiate with hyperscale providers, but realistic with smaller specialists.

Data use restrictions. Explicit restriction on use of customer data for training, evaluation, or improvement of the vendor's models. This is the most critical clause for enterprise customers — without it, your proprietary data may improve a model your competitors use. Enterprise-tier offerings from major providers include training opt-out by default; verify it in writing.

Sub-processor disclosure and approval. List of sub-processors current at contract signing, with notification requirements for changes. For high-risk applications, prior approval rights over material sub-processor changes.

Security controls and audit rights. Standard infosec provisions (SOC 2, ISO 27001) extended to AI-specific testing — adversarial testing, red teaming, prompt injection resistance, supply chain security. Audit rights or independent attestation reports.

Incident notification. Defined notification timelines for AI-specific incidents — model behaviour anomalies, training data issues discovered, security incidents, regulatory enquiries. Standard breach notification provisions need extension to AI failure scenarios.

Termination and transition. Exit assistance, data return and deletion, and model output transition. For material AI dependencies, defined alternative provider arrangements or in-house fallback capabilities.

Due diligence practices for material AI vendors

Before contracting with a material AI vendor: review the vendor's published AI policy, transparency report, and model documentation; obtain copies of relevant attestation reports (SOC 2 Type II, ISO 27001, ISO 42001 where available); review the vendor's training data disclosures and any related litigation; test the proposed AI system for your specific use cases with realistic adversarial inputs; review the contract DPA, sub-processor list, and incident notification provisions; obtain references from comparable enterprise customers.

During the contract lifecycle: monitor the vendor's behaviour for material changes (regulatory enforcement actions, security incidents, ownership changes, business model changes); review the vendor's transparency reports and policy updates; track regulatory developments that affect the vendor's obligations or your obligations as a deployer; conduct periodic re-assessment, particularly when the vendor releases model updates.

Practical steps for enterprise AI third-party risk management

Catalogue your AI vendors with risk classification — material vs non-material, by use case, by data sensitivity, by regulatory exposure. Update your standard vendor due diligence questionnaire with AI-specific questions covering training data, model behaviour, sub-processors, and AI security testing. Update standard contract templates with AI-specific provisions. Identify concentration risks — which vendors do you have material dependencies on, and what are your alternatives? Establish AI vendor governance authority — who in your organisation can approve material AI vendor onboarding, contract terms, and exception requests? Integrate AI vendor risk into existing third-party risk reporting to the board and risk committees.