5.2 Vendor & third-party risk review
Key Takeaways
- Because most organizations deploy rather than build AI, third-party foundation models and services import risks, from training data to security and bias, that the deployer often cannot directly inspect.
- AI vendor due diligence extends standard third-party risk management to cover model provenance, fairness and robustness evidence, data-training practices, and version and deprecation policy.
- Key AI contract clauses allocate risk: data-use and training rights, IP ownership of outputs, liability and IP-infringement indemnity, audit rights, and notice of behavior-changing model updates.
- The EU AI Act assigns duties by role, with providers carrying Article 16 obligations and deployers the lighter Article 26 obligations, while Article 25 converts a deployer into a provider on substantial modification or purpose change.
- Supply-chain transparency runs on documentation such as Article 13 instructions for use and GPAI technical docs, so missing model documentation is a red flag at the deployment gate.
Why third-party AI concentrates risk
Most organizations deploy AI more than they build it: they license SaaS products with embedded models, call foundation-model APIs, or fine-tune a provider's base model. Each arrangement imports capabilities the organization did not create and often cannot fully inspect, because the training data, evaluation results, security posture, and downstream dependencies live inside the vendor. Third-party AI therefore concentrates risk: a flaw, bias, outage, or licensing defect in one popular model propagates to every deployer built on top of it. AIGP treats vendor and third-party review as a core deployment control, and it maps onto disciplines the organization likely already runs, namely third-party risk management (TPRM), procurement, and vendor security review, now extended for AI-specific concerns. Treating an AI vendor as just another software supplier is the classic mistake; the model is probabilistic, its behavior can change with an update, and its training data may carry legal and ethical baggage the buyer inherits.
Due diligence on AI providers
Effective due diligence goes beyond a standard security questionnaire. Key areas to probe include:
- Model provenance and training data — sources, licensing, whether personal or copyrighted data was used, and data-quality controls.
- Performance and fairness evidence — benchmark results, bias and robustness testing, and known limitations, ideally via a model card or system card.
- Security and privacy — certifications such as SOC 2, ISO/IEC 27001, and ISO/IEC 42001, plus data residency, encryption, and sub-processors.
- Data handling — whether your inputs and outputs are used to train the vendor's models, and retention and deletion practices.
- Operational resilience — model versioning, deprecation and change-notice policy, uptime, and incident history.
- Legal and financial standing — IP indemnification, regulatory compliance posture, and the ongoing viability of the vendor.
The output of diligence is a documented risk rating that feeds the deployment gate rather than a checkbox filed and forgotten.
Contractual terms that allocate AI risk
Contracts are where AI risk is formally allocated between the parties. Terms the exam expects you to recognize include:
| Clause | What it protects |
|---|---|
| Data use / training rights | Bars the vendor from training on your data; sets retention and deletion. |
| IP ownership of outputs | Clarifies who owns generated content and grants the usage rights you need. |
| Liability & indemnification | Allocates responsibility, notably IP-infringement indemnity for model outputs. |
| Audit rights | Lets you or a third party assess the vendor's controls and documentation. |
| Security & breach notification | Sets safeguards and timely notice of incidents. |
| Change / model-update notice | Requires warning before behavior-changing model updates. |
| Compliance & cooperation | Vendor supplies information and support for your regulatory duties. |
Weak or missing clauses in any of these areas should raise the vendor's risk rating and may block the gate.
Ongoing vendor oversight
Vendor risk does not end at signing. Foundation models are updated frequently, and a silent version change can alter behavior, accuracy, or safety without warning, so deployers should track a vendor's model-update and deprecation notices, re-test after material changes, and keep a fallback plan for the day a model is retired or a price or policy shift makes it unusable. Contractual audit rights and periodic re-assessment, for example refreshed SOC 2 reports and updated model cards, keep the risk rating current rather than frozen at onboarding. Concentration risk also matters: relying on a single provider for a critical capability creates a single point of failure, which some organizations mitigate with multi-vendor or abstraction-layer strategies. In short, third-party AI must be governed continuously, mirroring the post-market monitoring the organization applies to systems it builds itself.
The provider-versus-deployer split under the EU AI Act
The EU AI Act allocates duties by role, so vendor review must establish which role each party plays. A provider develops or has developed an AI system and places it on the market under its own name; providers of high-risk systems carry the heavy obligations of Article 16: risk management, data governance, technical documentation, logging, a quality management system, conformity assessment, CE marking, and post-market monitoring. A deployer uses an AI system under its own authority; deployer obligations under Article 26 are lighter but real, requiring use of the system per the instructions, relevant and representative input data, competent human oversight, monitoring of operation, log retention, and notification of the provider and authorities about risks or serious incidents. Crucially, Article 25 provides that a deployer who puts its own name on a high-risk system, makes a substantial modification, or changes the intended purpose becomes a provider and inherits provider obligations. General-purpose AI (GPAI) model providers have their own transparency and documentation duties under Article 53 and must pass information down the chain.
Supply-chain transparency
Because deployers depend on information they cannot generate themselves, the value chain runs on documentation. Providers must supply instructions for use (Article 13) detailing capabilities, limitations, and required oversight measures; GPAI providers must give downstream integrators technical documentation (Annex XII). Article 25(4) expects the high-risk provider and its component suppliers to agree in writing on the information and technical access needed for compliance, and the AI Office is developing voluntary model contractual terms to standardize this. In practice, deployers should demand model cards, evaluation results, and data-sheet-style disclosures, and treat missing documentation as a red flag at the gate, much as a software bill of materials underpins software supply-chain security. Transparency down the chain is what makes each party's obligations auditable.
A company licenses a foundation-model API, uses it under its own authority per the vendor's instructions, and neither modifies it nor changes its purpose. Under the EU AI Act, what role does the company play?
Which contractual clause most directly protects a deployer from having its confidential prompts and data used to train the vendor's models?
Why is supply-chain documentation such as model cards, instructions for use, and GPAI technical docs treated as essential in AI vendor review?