AI Vendor Risk Assessment Checklist (2026) — 35 Questions for Provider, Deployer, and GPAI Risk

A complete AI-vendor due-diligence checklist that maps to AI Act Articles 25 + 26, ISO 42001 supplier controls, and standard TPRM workflows — with the new GPAI questions classical TPRM checklists miss.

AI procurement has changed. The EU AI Act introduced a vocabulary — provider, deployer, GPAI, Article 12 logging, Article 73 incident notification — that doesn't exist in any third-party risk management (TPRM) template written before 2024. Classical vendor questionnaires ask about SOC 2, penetration testing, and subprocessor lists. They don't ask which side of the provider/deployer line your vendor sits on, whether the system is classified high-risk under Annex III, or what human oversight features the vendor actually exposes.

That gap is a procurement liability. If an AI system you deploy causes a discriminatory decision, a GDPR breach, or a regulatory fine, the question your auditors will ask is: did you do the right due diligence before you signed the contract?

This checklist gives you 35 specific questions organized by stage — pre-contract, AI Act-specific, contractual, and ongoing monitoring — so your TPRM process keeps pace with the regulatory reality of 2026. It sits alongside the complete AI compliance checklist and extends it specifically for the third-party procurement context.

Why AI vendor risk is not classical vendor risk {#why-ai-vendor-risk-is-different}

Classical vendor risk asks: is this vendor secure, reliable, and solvent? Those questions still matter. But AI vendor risk adds a second, distinct layer: does this vendor's system operate within legally permissible boundaries — and do you, as the organization deploying it, have the oversight mechanisms to prove that?

The distinction matters because liability under the AI Act doesn't stop at the vendor's door. You are exposed as a deployer the moment you put a third-party AI system to work in your organization.

Provider vs. deployer obligations under the AI Act {#provider-vs-deployer}

The AI Act draws a hard line between providers (organizations that develop and place an AI system on the market) and deployers (organizations that put a provider's system to use in their own context).

For high-risk AI systems, the split looks like this:

Provider obligations (Articles 9–17): Technical documentation, risk management system, training data governance, Article 12 automatic logging, instructions for use, human oversight design, conformity assessment, EU database registration.
Deployer obligations (Article 26): Receive and implement the instructions for use, assign qualified human oversight persons, use the system only within its declared intended purpose, report anomalies to the provider, conduct a Fundamental Rights Impact Assessment (FRIA) where required.

When you procure a third-party AI system, you become the deployer. You cannot outsource the deployer obligations — you can only verify that the provider has done their part, then demonstrate that you have done yours. This checklist covers both sides.

GPAI (general-purpose AI) — the new vendor category {#gpai-vendor-category}

General-purpose AI models (GPAI) — foundation models and large language models placed on the EU market — carry their own obligations under Articles 52–56, applicable since August 2025. GPAI vendors must maintain technical documentation, publish a training-data summary consistent with copyright law, and (if their model exceeds 10^25 FLOPs training compute or is designated systemic-risk by the AI Office) conduct adversarial testing and establish incident reporting.

If any vendor you are evaluating provides or integrates a GPAI model, the questions in Section 2 below apply on top of the standard high-risk checklist. Classical TPRM questionnaires have no GPAI section at all.

Pre-contract questions — 12 due-diligence questions {#pre-contract-questions}

Run these before any AI contract signature or renewal. They establish the baseline facts your legal and compliance teams need to determine which AI Act obligations apply.

Model documentation and Article 11 evidence {#model-documentation}

1. What is the intended purpose of the AI system as declared by the provider in its technical documentation, and does that declaration match the use case you are procuring it for?

2. Has the provider completed and made available to you the technical documentation required under Article 11 and Annex IV of the AI Act? Request the document index — not just a written assurance that documentation exists.

3. What is the AI system's risk classification under Articles 6(1) and 6(2) / Annex III? Has the classification been reviewed by independent legal counsel on the provider's side?

4. If the vendor claims an Article 6(3) exception (system is in an Annex III domain but not classified high-risk), what evidence supports that claim and has it been independently reviewed?

Training data lineage and IP exposure {#training-data-lineage}

5. What are the sources, provenance, and quality controls for the training data used in the system? Does the vendor maintain a data governance log consistent with Article 10?

6. Does the training data include personal data? If so, what legal basis was used, and is that documentation available for your review?

7. Does the system incorporate third-party models or datasets subject to copyright, licensing, or export-control restrictions? What are those restrictions, and do they affect your permitted use cases?

Security posture and ISO 27001 / SOC 2 baseline {#security-posture}

8. Does the vendor hold current ISO 27001 certification or SOC 2 Type II attestation? Request the most recent certificate or report (not a summary slide).

9. What AI-specific threat controls does the vendor implement for adversarial inputs, prompt injection, model extraction, and data poisoning? Ask for the threat model document, not a verbal assurance.

For a structured approach to supplier controls under the AI management standard, see the ISO 42001 checklist for AI management.

10. What is the vendor's patch and update cadence for the AI model itself — not just the platform? How are you notified of model updates that may change the system's behavior?

11. Where is inference processing performed — in the vendor's EU infrastructure, or in third-country data centers? What international data transfer safeguards (SCCs, adequacy decisions) apply?

12. What is the vendor's documented sub-processor list for the AI system specifically? How are changes to that list notified to you, and what is the lead time?

AI Act-specific questions — 10 must-have additions to your TPRM template {#ai-act-specific-questions}

These ten questions have no equivalent in classical TPRM frameworks. They map directly to obligations that determine whether you — as deployer — can demonstrate compliance.

Risk classification of the vendor's system {#risk-classification}

13. Has the vendor registered this AI system in the EU AI database under Article 49? Provide the registration reference. For a full breakdown of what constitutes a high-risk system, see the guide to AI Act high-risk systems.

14. If the system is classified high-risk, has the provider completed a conformity assessment under Article 43? Was this a self-assessment or a third-party notified-body assessment? Provide the conformity declaration.

15. Does the system process any Annex III domains — biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration, or justice? Even if the vendor does not classify the system as high-risk, document your own review of this question.

Human oversight features the vendor exposes {#human-oversight-features}

16. What human oversight mechanisms does the system expose to deployers under Article 14? Specifically: can a designated human monitor, interrupt, and override system outputs in real time? How is this functionality delivered — UI, API, configuration?

For implementation patterns, see the human-in-the-loop AI policy template.

17. Does the vendor provide interpretable, auditable outputs that support the human overseer's ability to understand and evaluate the system's recommendations? What explainability features are available in your contracted tier?

18. What training does the vendor provide or recommend for human oversight persons designated under Article 26? Is this training documented, and can you evidence it to your auditors?

Logging, traceability, and Article 12 evidence {#logging-traceability}

19. Does the system implement automatic logging under Article 12? What events are logged — inputs, outputs, confidence scores, anomalies, operator interventions? Are logs immutable and timestamped?

20. What is the log retention period, and is it configurable to meet your internal retention requirements or sector-specific obligations? Who controls log deletion?

21. Can you export logs in a format suitable for regulatory audit? What is the process, and what is the contractual SLA for log retrieval on regulatory request?

Generate AI vendor clauses and policies The AI policy template generator produces ready-to-use vendor questionnaire templates, Article 28 GDPR DPA clauses, and deployer-side AI Act documentation — free to use.

Incident notification SLAs (Article 73) {#incident-notification}

22. What is the vendor's contractual SLA for notifying you of serious incidents as defined under Article 73 of the AI Act? The Article requires providers to notify market surveillance authorities — but your contract must also require notification to you as deployer, before or simultaneous with regulatory notification.

Contractual clauses to insist on {#contractual-clauses}

A vendor that answers the pre-contract questions satisfactorily but refuses to put those answers into the contract is a vendor whose answers you cannot rely on. These three areas must be in writing.

Audit rights and evidence-on-demand {#audit-rights}

23. Does the contract give you (or your designated auditor) the right to audit the vendor's AI compliance documentation, including technical documentation, conformity assessment records, and incident logs, on reasonable notice?

24. Does the contract require the vendor to provide updated technical documentation and risk classification evidence within a defined period following any significant system modification?

25. Does the contract specify a maximum response time for producing compliance evidence on regulatory authority request — covering both your internal needs and any direct requests from a market surveillance authority to the vendor?

Sub-processor changes and AI-specific notification {#sub-processor-notification}

26. Does the contract require the vendor to notify you before making sub-processor changes that could affect the AI system's behavior, data processing geography, or compliance posture — with a minimum notice period sufficient for you to conduct a review?

27. Does the contract address model updates specifically — including retraining on new data, architecture changes, and capability expansions — as events that trigger a notification to you and, where relevant, a revised conformity declaration?

Liability allocation for AI-caused harm {#liability-allocation}

28. Does the contract specify liability allocation for harm caused by the AI system's outputs — distinguishing between harm arising from the provider's system design (provider liability) and harm arising from your deployment choices (deployer liability)?

29. Does the indemnification clause cover regulatory fines and penalties, not just third-party civil claims? The AI Act penalty regime (up to €35 million or 7% of global annual turnover for prohibited practice violations) makes this a material exposure.

30. Does the contract include a termination right triggered by a change in the AI system's regulatory status — e.g., if a system that was not high-risk at contract signature is subsequently classified as high-risk by regulation or regulatory authority decision?

Ongoing monitoring — what a quarterly vendor review looks like {#ongoing-monitoring}

Procurement due diligence is a point-in-time exercise. The AI Act creates continuous deployer obligations that require ongoing monitoring of your vendor relationship. A quarterly review should cover:

31. Has the vendor issued any updated technical documentation, revised conformity declarations, or new instructions for use since the last review? Have you received them and reviewed them against your deployment context?

32. Have there been any AI Act Article 73 incidents reported by the vendor to market surveillance authorities? What was the nature of the incident and what remediation was applied?

33. Has the AI system been updated — model version change, retraining, capability addition — since the last review? What change-management process did the vendor follow, and does the update affect your risk classification as deployer?

For a framework to structure your ongoing AI compliance monitoring program, the NIST AI RMF implementation guide provides a practical MANAGE-function template, and the AI compliance automation in fintech guide covers continuous monitoring tooling for regulated industries.

34. Are your designated human oversight persons still current in their training and responsibilities? Has role or system change created a gap in qualified oversight coverage?

35. Has your own use of the vendor's system evolved in ways that could affect the deployer risk profile — new use cases, new data categories, expanded user populations, higher-volume processing?

Disqualifiers — when to walk away from an AI vendor {#disqualifiers}

Some vendor responses are not remediation opportunities — they are disqualifiers. Walk away or escalate to legal counsel before proceeding when:

The vendor cannot produce technical documentation on request, or asserts it is proprietary and non-disclosable in its entirety. Partial redaction of commercially sensitive detail is acceptable; total non-disclosure is not.
The vendor asserts that no classification review has been conducted for systems operating in Annex III domains.
The vendor has no Article 12 logging in place for a system it classifies as high-risk.
The vendor refuses any form of audit right in the contract.
The vendor's incident notification SLA exceeds your internal reporting window to your DPA or sector regulator.
The vendor is unable to confirm that the AI system's indemnification clause covers AI Act regulatory penalties.
The vendor's response to the GPAI questions (if applicable) is that GPAI obligations are not their concern as a model provider. They are.

Any of these responses signals either a compliance posture incompatible with your deployer obligations, or a contractual risk exposure that legal counsel needs to quantify before you proceed.

Frequently Asked Questions

Is the AI vendor risk assessment a separate process from our existing TPRM, or an extension?

It is an extension, not a parallel process. The 35 questions here map onto and supplement your existing TPRM workflow — they don't replace it. In practice, the cleanest approach is to add an AI Act section to your existing vendor questionnaire template, triggered when the vendor provides any AI system component, and to add an AI risk classification checkpoint to your contract review checklist. Procurement teams that run AI vendor risk as a separate silo tend to find that contracts execute before the AI review completes — the integration point is the contract red-line stage, not a standalone workstream.

What is the most common reason an AI vendor fails due diligence in 2026?

The most common failure point is logging and traceability: the vendor has not implemented Article 12-compliant automatic logging, or what they call "logging" is application-level access logs rather than AI event logs (inputs, outputs, anomalies, human interventions, confidence scores). The second most common failure is the absence of a documented risk classification for systems operating in Annex III domains — vendors often assume that because they did not intend the system for a regulated use case, classification review is unnecessary. Intended purpose is not the only trigger; actual deployment context is also relevant.

Do I need a different questionnaire for GPAI vendors vs. domain-specific AI vendors?

Yes. GPAI vendors face a distinct obligation set under Articles 52–56, and the questions you need to ask are structurally different: training data copyright compliance, the training compute threshold for systemic-risk designation, adversarial testing programs, and the AI Office's ongoing oversight regime. Domain-specific AI vendors (a credit-scoring model, a document-processing system, a hiring tool) are assessed against Articles 9–17 provider obligations for their specific system. In practice, many domain-specific AI systems now integrate GPAI model components — in that case, run both question sets. The GPAI questions apply to the model layer; the high-risk questions apply to the application layer built on top of it.

How do I evidence AI vendor compliance to my own auditors?

Your audit package for each AI vendor should include: the signed vendor questionnaire with the vendor's responses, a copy of the technical documentation index or table of contents (full documents where provided), the conformity declaration or self-assessment record, the contract clauses covering audit rights, incident notification, sub-processor notification, and liability allocation, and your own risk classification review memo confirming how you assessed the system against Annex III. Supplement this with your quarterly review records, including any updated documentation received and any incident disclosures. The test your auditors will apply is whether you had a documented, repeatable process — not whether the vendor scored perfectly.

Can a vendor's ISO 42001 certification replace our internal due-diligence checklist?

No. ISO 42001 certification tells you that the vendor has implemented an AI management system that meets the standard — it says nothing about the specific system you are procuring, its risk classification, its Article 12 logging implementation, or the contractual terms you need in place as a deployer. The certification is evidence of management maturity; the checklist is an inquiry into the specific system and the specific relationship. Use the ISO 42001 certificate as positive context that reduces (but does not eliminate) the depth of management-system questions in Section 3 of your review, and direct the time saved toward the AI Act-specific and contractual sections, which the certification does not address.

Take the next step

This checklist gives you the question framework. What most procurement teams need next is the clause language: contract provisions that translate "the vendor must provide Article 12 logs on regulatory request within 5 business days" into enforceable contractual text, and deployer-side documentation templates that demonstrate your oversight obligations are met.

The AI policy template generator produces ready-to-use vendor questionnaire templates, deployer-side AI Act obligation checklists, and Article 28 GDPR DPA clauses for AI processors — free to generate.

If you are mid-procurement and need a faster path — a review of your current vendor contracts against the AI Act's deployer obligations, identification of the highest-exposure gaps, and a prioritized remediation plan — book a 20-minute compliance review with the Knowlee team.