AI Third-Party Risk Management: The Vendor Assessment Checklist

Most organisations' AI risk comes from the AI tools they buy, not the AI they build. This is the practical vendor assessment checklist — what to ask AI vendors, what the answers mean, and what to put in contracts.

Key Takeaways

For most organisations, third-party AI is a larger governance challenge than internally developed AI — the tools bought from vendors process more data, affect more decisions, and are less transparent than AI built in-house.
The EU AI Act's deployer obligations cannot be transferred to AI vendors through contract — as the deployer, your organisation is responsible for compliance regardless of what the vendor contract says. Vendor assessment is about risk management, not liability transfer.
The three red flags that should stop an AI vendor assessment: the vendor cannot explain how their AI makes decisions at a meaningful level ('it's proprietary' is not acceptable for high-risk AI), the vendor refuses to provide data processing terms that satisfy your legal obligations, or the vendor has had enforcement actions or significant incidents without satisfactory remediation.
Contract essentials for AI vendors: data processing agreement (GDPR/Privacy Act), data training restrictions (vendor cannot train on your data without consent), model change notification (30 days for significant changes), audit rights (right to receive performance and security reports), and incident notification (24-hour notification of material incidents).
Ongoing vendor monitoring matters as much as initial assessment — AI vendors update their models, change their data practices, and alter their terms. Quarterly monitoring of material AI vendor relationships is the minimum for high-risk AI vendor relationships.

"仅供参考。本文不构成法律、监管、财务或专业建议。如需具体指导，请咨询合格专家。"

AI third-party risk checklist — the minimum viable assessment

Most AI risk now sits in third-party vendor relationships. Even organisations with strong internal AI governance often assess AI vendors using generic third-party risk processes that miss AI-specific concerns. This checklist provides the minimum viable assessment for any AI vendor relationship.

Before contracting — vendor assessment

☐ Data handling. Will the vendor use your data for model training? Where is data processed and stored? How long is data retained? Who has access? What sub-processors are used? Is there a Data Processing Agreement available?

☐ Security. Does the vendor hold SOC 2 Type II? ISO 27001? ISO/IEC 42001 (AI management system)? What adversarial testing has been conducted? What incident response procedures exist for AI-specific failures?

☐ Model documentation. Can the vendor provide model cards or technical documentation? What bias testing has been conducted? What are the known limitations? What demographic groups were represented in testing?

☐ Regulatory compliance. Has the vendor classified the system under the EU AI Act? Is the vendor CPS 230 compliant (for Australian financial services)? Does the vendor support DORA requirements (for EU financial services)?

☐ Financial stability. Is the vendor financially stable? What is the ownership structure? Are there pending ownership changes? Has the vendor disclosed any material litigation (training data IP cases)?

☐ References. Can the vendor provide references from comparable customers in your sector?

Contract provisions

☐ Contractually binding no-training commitment for your data

☐ Data Processing Agreement with specific AI provisions

☐ Sub-processor disclosure with change notification

☐ Model change notification before material updates

☐ Performance benchmarks with measurable SLAs

☐ AI-specific incident notification timelines

☐ Audit rights (SOC 2 + organisational audit for material vendors)

☐ IP indemnification covering training data litigation risk

☐ Exit provisions with data return and deletion verification

Ongoing monitoring

☐ Vendor AI performance against contractual SLAs

☐ Security attestation currency (SOC 2 reports are annual)

☐ Vendor incident reports and remediations

☐ Sub-processor changes

☐ Ownership and financial stability indicators

☐ Regulatory developments affecting the vendor

☐ Concentration risk assessment (quarterly for material vendors)

Escalation triggers

☐ Vendor reports a significant AI incident

☐ KRI thresholds breached for vendor AI performance

☐ Vendor ownership or financial stability changes

☐ New litigation involving the vendor's AI

☐ Regulatory action against the vendor

☐ Material sub-processor change