AI Risk Management

Third-Party AI Risk Management: Managing Vendor and Model Risk

A practical approach to assessing and managing risk from third-party AI vendors and models you don't control, including a vendor due-diligence checklist.

Jasper Claes

April 30, 2026 · 7 min read

AI Risk Management

You can't inspect a vendor's training data or model weights — but you're still on the hook for the risk their AI introduces into your product or operations. Here's a practical approach to third-party AI risk management, with a due-diligence checklist you can start using today.

TL;DR

Third-party AI risk requires an evidence-based approach since you can't directly inspect a vendor's model or training data.
Request specific artifacts from vendors: model documentation, bias testing results, security practices, and incident notification commitments.
Contractual protection (indemnification, audit rights, incident notification clauses) matters as much as technical assessment for risk you can't fully verify yourself.
Ongoing monitoring matters — a vendor's risk profile at signing can change as they update their models without necessarily telling you.
Regulatory frameworks generally don't let you transfer legal responsibility to the vendor — you often remain accountable for how you use their AI regardless of contract terms.

The Visibility Gap

You have full visibility into your own models — third-party AI is a black box you assess through evidence, not inspection.

A Vendor Due-Diligence Checklist

Model card or system documentation describing intended use and known limitations
Bias and fairness testing results relevant to your specific use case
Security and data handling practices, especially regarding your data passing through their system
Incident notification commitments — will you actually be told promptly if something goes wrong?
Update and retraining cadence — how often does the underlying model change?

Contractual Protection Matters as Much as Technical Assessment

Contract term	Why it matters
Indemnification	Transfers some financial risk if the vendor's AI causes harm
Audit rights	Lets you verify claims rather than relying purely on trust
Incident notification SLA	Defines how quickly you'll be told about a problem
Data usage restrictions	Limits how your data can be used to train or improve their models

You Usually Can't Outsource Legal Responsibility

Most AI regulation — including the EU AI Act's deployer obligations — holds the company using an AI system accountable for its use, regardless of who built it. A strong contract can shift financial risk to a vendor after the fact, but it doesn't remove your own regulatory obligations to assess and monitor the system in the first place.

Ongoing Monitoring, Not Just a One-Time Review

A vendor's risk profile at contract signing isn't fixed — they can update their model, change training data, or shift their own sub-processors without necessarily notifying you in detail. Treat vendor risk assessment the same way as internal risk assessment: something to revisit on a schedule, not a one-time gate at procurement.

A Simple Assessment Process

Request the due-diligence artifacts above before signing
Score the vendor relationship using the same likelihood/impact framework as your internal AI risk register
Negotiate contractual protections proportional to the risk level identified
Schedule a recurring review — annually at minimum, more often for high-risk use cases

Primary Sources

NIST — AI Risk Management Framework
EUR-Lex — Regulation (EU) 2024/1689

Categorizing the Type of Third-Party Risk

Vendor relationship	Primary risk
Embedded third-party model (e.g. an LLM API)	You inherit the model's behavior with limited ability to inspect or retrain it
Vendor SaaS with AI features built in	Risk is bundled with a broader software relationship, easy to overlook as 'just a feature'
Data processor using AI on your data	Risk to your own data governance obligations, not just the AI's output quality

When to Walk Away From a Vendor

Some findings should end a vendor evaluation rather than just get flagged as a risk to manage: a flat refusal to share any model documentation, no willingness to commit to incident notification in writing, or a use case where the vendor's own terms disclaim responsibility for the exact failure mode you're most exposed to. Continuing anyway usually means inheriting risk you've already identified and chosen not to address.

Where Unorma Fits

One register, internal and third-party

Unorma’s AI inventory tracks third-party and vendor AI alongside internally built systems, so vendor risk doesn’t live in a separate, forgotten spreadsheet. Read How to Build an AI Risk Register for the underlying scoring methodology to apply to vendors too.

Frequently asked questions

Can we transfer our legal AI compliance responsibility to a vendor through contract?

Not entirely — most AI regulation holds the deploying organization accountable for how a system is used, regardless of who built it. Contracts can shift financial risk, but not regulatory responsibility.

What should we request from an AI vendor before signing?

Model documentation, bias/fairness testing results, security and data handling practices, and clear incident notification commitments, at minimum.

How often should we reassess a third-party AI vendor's risk?

At least annually, and sooner for high-risk use cases — a vendor's model and risk profile can change after signing without necessarily being communicated to you.

Should third-party AI risk be tracked separately from internal AI risk?

It's generally better tracked in the same register using the same scoring framework, so you get one complete view of AI risk exposure rather than two disconnected pictures.

What third-party AI risks are easiest to overlook?

AI features bundled inside a broader vendor SaaS product — they're easy to treat as 'just a feature' rather than a distinct AI risk requiring its own due diligence.

What findings should end a vendor evaluation rather than just get flagged?

A flat refusal to share model documentation, no willingness to commit to incident notification in writing, or vendor terms that disclaim responsibility for the exact failure mode you're most exposed to.

Who inside the organization should own third-party AI risk?

Typically the same compliance or risk function that owns internal AI risk, working with procurement or legal on the contractual side — splitting ownership between security and procurement without a shared register tends to leave gaps.

Key terms in this article

About the author

Jasper Claes

Compliance Manager & AI Governance Consultant

Compliance Manager and consultant specializing in AI governance for high-scale technology companies operating in regulated markets.

View full profile

Keep reading