Third-Party AI Vendor Risk Assessment Checklist

Most procurement teams already have a vendor questionnaire. It asks about financial stability, insurance, security certifications, and business continuity. Then someone buys a tool with a language model inside it, or a scoring engine that screens job applicants, and the questionnaire has nothing to say about training data, model drift, or what happens to your prompts after you hit enter.

I have come to think the gap is not that procurement teams are careless. The gap is that AI risk shows up in places the old questionnaire never looked. This article gives you a working checklist you can drop into your sourcing process, along with the reasoning behind each section so you can adapt it to your own risk appetite.

Why does AI vendor risk need its own assessment?

A traditional software vendor sells you code that behaves the same way tomorrow as it does today. An AI vendor sells you something that can change without a release note: the model gets retrained, the provider swaps the underlying foundation model, or the data it learned from turns out to include material it should not have. You are buying behavior, and behavior can shift.

There is also the question of who is accountable when something goes wrong. Under the EU Artificial Intelligence Act (Regulation (EU) 2024/1689), deployers of high-risk AI systems carry their own obligations under Article 26, separate from the provider's obligations. Buying from a vendor does not move your accountability to the vendor. In my view, that is the single most important idea for a procurement lead to absorb before touching a checklist.

The same logic runs through ISO/IEC 42001:2023. Clause 8.1 requires an organization to make sure externally provided processes, products, or services relevant to the AI management system are controlled. Annex A control objective A.10, "Third-party and customer relationships," contains control A.10.2 (allocating responsibilities), A.10.3 (suppliers), and A.10.4 (customers). If you plan to certify to the standard, or simply want to behave as though you will, your vendor process needs to produce evidence for those controls.

Which frameworks should the checklist map to?

You do not need to invent criteria from scratch. Several published frameworks already say what a reasonable buyer should ask. The table below shows where each one speaks to third-party AI.

Article 25 of the EU AI Act is worth a close read if you resell or embed someone else's model. It describes when a distributor, importer, or deployer becomes the provider of a high-risk system, for example by putting their name on it or making a substantial modification. It also requires written agreements between a high-risk system provider and third parties supplying tools, services, components, or processes used in it.

The checklist

I organize the assessment into ten domains. Not every domain needs the same depth for every vendor, and I cover tiering after the checklist. Treat each bullet as a question you can send to the vendor and a piece of evidence you can ask for.

1. What exactly is the AI, and where does it live?

Start by pinning down what you are actually buying. Vendors often describe "AI-powered features" without saying what sits underneath.

• Does the vendor build its own models, fine-tune someone else's, or call a third-party API? Get the names of the upstream model providers.
• Which features use AI and which are conventional software? Ask for a feature-level list, not a marketing summary.
• Is the AI system classified under the EU AI Act, and if so, in what risk category? Ask the vendor to state its own classification and the reasoning.
• Does the product include a general-purpose AI model? If so, ask whether the model provider meets the obligations in Article 53 of the Act.
• Where is the model hosted, and in which jurisdictions does processing occur?

The upstream question matters more than people expect. Your vendor's risk posture is only as good as the weakest provider in its chain, and you will not see that chain unless you ask.

2. How is data collected, used, and protected?

• What data does the vendor collect from you, and for what stated purposes?
• Will your inputs, outputs, or metadata be used to train or improve models, for you or for other customers? Require a plain yes or no, and get it in the contract.
• Can training use be switched off, and is the default on or off?
• What are the retention periods for prompts, outputs, and logs, and can you require deletion?
• Who are the sub-processors, and how are you notified of changes? GDPR Article 28(2) and 28(4) govern engagement of other processors, so this is a legal expectation as well as a good practice.
• What is the provenance of the vendor's training data? Ask about licensing, consent, and any known restrictions.

3. What security evidence can the vendor show?

Standard security diligence still applies, and AI adds a few items to it.

• Current ISO/IEC 27001:2022 certificate with the scope statement, or a SOC 2 Type II report covering the relevant systems. Read the scope, because a certificate that excludes the AI platform tells you little.
• Controls for AI-specific attacks: prompt injection, data poisoning, model extraction, and adversarial inputs.
• Access controls separating customer environments, especially for shared or multi-tenant models.
• Penetration testing results that include the AI components, not only the web application around them.
• Incident response plan, including notification timelines and what counts as an AI-related incident.

If you want a deeper treatment of how the security management system fits alongside AI governance, our page on ISO 27001 covers the baseline.

4. Does the vendor have real AI governance?

This is where I see the biggest difference between vendors who are serious and vendors who are decorating a pitch deck.

• Is there an AI management system, and is it certified to ISO/IEC 42001:2023 or at least aligned to it? Ask for the certificate, the certification body, and the scope.
• Who owns AI risk inside the vendor's organization, and to whom do they report?
• Is there a documented AI risk assessment process consistent with clause 6.1.2 and an impact assessment process consistent with clause 6.1.4 of the standard?
• Does the vendor maintain a policy on responsible or acceptable AI use that it can share?
• How does the vendor train staff on AI risk? The EU AI Act's Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among their staff.

A vendor without an AI management system is not automatically a bad choice, but it should change how much you rely on their word and how much you verify yourself.

5. How was the model tested for performance, bias, and safety?

• What are the documented performance metrics, on what data, and under what conditions? A single accuracy number with no context is not evidence.
• Has the model been evaluated for bias across relevant groups, and can the vendor share the method and results? For hiring tools in New York City, Local Law 144 requires an annual independent bias audit of automated employment decision tools, so ask for the audit summary.
• What testing covers harmful, false, or unsafe outputs, particularly for generative systems?
• What are the known limitations and out-of-scope uses? Good vendors write these down and bad ones say there are none.
• How does the vendor test after updates, and does it re-run evaluations when the underlying model changes?

6. Is the system transparent and explainable enough for your use?

• What documentation will you receive: model cards, system cards, technical documentation, instructions for use?
• Can the vendor explain how outputs are produced at a level your reviewers and, if relevant, regulators can follow?
• For decisions affecting individuals, how does the product support the rights described in GDPR Article 22 on automated decision-making, including human review?
• Does the product tell end users when they are interacting with AI or viewing AI-generated content?

7. What human oversight does the design allow?

• Can your staff review, override, or stop the system's outputs before they take effect?
• What logging exists, and can you export logs to support your own audits and investigations?
• Are there confidence indicators or flags that help reviewers know when to look harder?

For high-risk systems, human oversight is a legal design requirement for the provider under the EU AI Act, and a deployer must assign oversight to people with the competence and authority to do it. A tool that makes oversight difficult is a tool that makes your compliance difficult.

8. How does the vendor manage change?

• How are model updates communicated, and how much notice do you get before a material change?
• Can you pin a model version, or are you moved automatically?
• What triggers re-validation, and who performs it?
• If the vendor switches its upstream foundation model, are you told before or after?
• What is the deprecation policy for versions you depend on?

Change management is the question I would put near the top for any generative AI tool. A model that was acceptable in March may behave differently in June, and your approval should not be a permanent pass.

9. What do the legal and contractual terms say?

• Intellectual property: who owns outputs, and does the vendor offer indemnity against infringement claims arising from outputs or training data?
• Liability caps and carve-outs for data breaches, IP claims, and regulatory fines.
• Audit rights, or at least the right to receive independent assurance reports annually.
• Notification duties for security incidents, regulatory inquiries, and material model changes.
• Allocation of responsibilities consistent with ISO/IEC 42001:2023 control A.10.2, written down in plain terms.
• Data processing agreement compliant with GDPR Article 28(3), covering instructions, confidentiality, security, sub-processors, assistance, deletion or return, and audit.
• Exit terms: data return, deletion certification, and transition support.

10. Can the vendor survive and keep supporting you?

AI is a young market and many vendors are small, heavily funded, and dependent on a single upstream provider.

• Financial health and runway, not only revenue.
• Dependency concentration: what happens if the upstream model provider changes pricing, terms, or availability?
• Business continuity and disaster recovery plans that cover the AI components specifically.
• Escrow or portability options where the system is critical to operations.

How do you decide how deep to go?

Running all ten domains at full depth for every vendor will stall procurement and annoy everyone. A tiering step before the assessment keeps the effort proportional. Here is the structure I recommend.

Penalties give a sense of the stakes. Article 99 of the EU AI Act sets administrative fines of up to 35 million euros or 7 percent of worldwide annual turnover (whichever is higher) for prohibited practices, and up to 15 million euros or 3 percent for breaches of most other obligations, including those of operators. Those are ceilings, not predictions, but they tell you how the legislator weighed the risk.

What red flags should stop or slow a purchase?

Some answers should make you pause no matter how good the demo looked.

• The vendor cannot or will not name its upstream model providers.
• Customer data is used for training by default, with no contractual opt-out.
• The vendor describes the system as "unbiased" or "error-free." No credible vendor makes that claim.
• Security certifications exclude the AI platform from scope.
• No documented process for notifying customers of material model changes.
• The vendor treats governance questions as a sales obstacle instead of a normal part of enterprise buying.
• Liability is capped at a nominal amount while the use case touches consequential decisions about people.

I would add one softer flag: when answers arrive slowly and inconsistently from different people. It often means nobody owns the topic inside the vendor, and that is itself a finding.

How should you monitor AI vendors after signing?

Approval at the start of a contract is a snapshot. The checklist only works if it becomes a cycle.

1. Set a review cadence by tier. Annual for Tier 2, semiannual or event-driven for Tier 3 is a reasonable starting point.
2. Collect fresh evidence. Updated certificates, new audit reports, current sub-processor lists, and release notes for model changes.
3. Track incidents and complaints. Keep a record of output errors, user complaints, and security events linked to each AI vendor.
4. Re-assess on triggers. A change of upstream model, a new use case, a change of ownership, a regulatory shift, or a security incident should each reopen the assessment.
5. Feed findings back into your AI risk register. ISO/IEC 42001:2023 expects risks to be assessed and treated as part of the management system, and vendor findings belong in that same loop.

NIST's AI RMF follows a similar rhythm. GOVERN 6 calls for policies and procedures that deal with AI risks from third-party software and data, and the framework's MEASURE and MANAGE functions expect ongoing tracking rather than a one-time check.

How does this connect to ISO 42001 certification?

If your organization is working toward ISO/IEC 42001:2023 certification, the vendor assessment becomes part of your audit evidence. An auditor will look for a documented supplier selection and evaluation process, evidence it was followed, defined responsibilities between you and your suppliers, and records of ongoing monitoring. A tidy checklist with completed assessments, tier assignments, and review dates answers most of that in one place.

I would suggest running a gap assessment against Annex A before you build the process, so you know which controls your current procurement practice already satisfies. Our ISO 42001 gap assessment page describes how that works, and the ISO 42001 consultant page explains where outside help is most useful.

A practical way to roll this out

If I were starting from nothing in a mid-sized company, I would do it in this order.

First, inventory what you already have. Ask each department which tools use AI, including features switched on inside software you bought years ago. Shadow adoption is common, and you cannot assess what you cannot see.

Second, write a one-page intake form that routes each new purchase to a tier. Procurement should not have to guess, and business owners should not be able to skip the form.

Third, build the questionnaire from the ten domains above, trimming for Tier 1 and keeping everything for Tier 3. Pair it with standard contract language so legal is not drafting from zero each time.

Fourth, decide who signs off at each tier. Tier 3 approvals should include legal, security, and the business owner who will answer for the outcome.

Fifth, schedule the first review cycle before the first vendor is approved. If the monitoring step is not on the calendar, it will not happen.

The honest truth is that the checklist will not make a vendor safe. What it does is make the risk visible, assign it to a person, and give you a record showing that someone asked the right questions before the contract was signed. That record is what regulators, auditors, and your own board will want to see when something eventually goes wrong with a tool nobody thought to question.

Frequently asked questions

What is a third-party AI vendor risk assessment? It is a structured review of a supplier's AI products or AI-enabled services before purchase and during the contract. It covers data use, security, governance, testing, transparency, change management, contract terms, and vendor viability, and it produces a documented risk rating and decision.

Who is responsible if a vendor's AI system causes harm? Responsibility is shared and depends on your role and the law that applies. Under the EU AI Act, deployers of high-risk systems have their own duties under Article 26 even when the provider built the system. Contracts can allocate cost and indemnity, but they cannot remove your regulatory obligations.

Does ISO 42001 require a vendor risk assessment? ISO/IEC 42001:2023 clause 8.1 requires control of externally provided processes, products, or services relevant to the AI management system, and Annex A control A.10.3 addresses suppliers. In practice, certification auditors expect to see a documented supplier evaluation process and evidence that it is applied.

How often should AI vendors be reassessed? Set the cadence by risk tier, and also reassess on triggers such as a change in the upstream model, a new use case, a security incident, or a change in ownership. Annual review is a common baseline for moderate-risk vendors, with more frequent review for those influencing decisions about people.

What is the most commonly missed question in AI procurement? Whether your data will be used to train the vendor's models. The answer should be written into the contract, along with the retention period for prompts and outputs and a list of sub-processors.

Last updated: 2026-11-03