AI Vendor Assessment Tool

AI vendor due diligence

EU AI Act Vendor Due Diligence

Evidence-led prompts for a defined service, intended use and human review.

Use this guide to collect facts about an AI system, its intended purpose, your organization’s role, and the vendor evidence available for the proposed use. The EU AI Act applies by role and context. This guide supports due diligence; it is not a legal classification, compliance determination, or substitute for advice from qualified counsel.

Identify the system and the parties

Begin with the specific AI system, version, configuration, and intended purpose in the deployment you are considering. Record which entities place the system or model on the market, put it into service, use it under whose authority, supply or integrate components, and control branding or material changes. A vendor’s role label is useful evidence of its position, but it does not settle how the law applies to the arrangement.

For an EU AI Act provider vs deployer review, describe what each party actually does and which facts support the role assumptions. Article 25 identifies circumstances in which a distributor, importer, deployer, or other third party may be treated as provider of a high-risk AI system, including specified name or trademark changes, substantial modifications, or a change of intended purpose that makes a system high-risk. Whether those conditions apply depends on the system and facts. Ask counsel to examine the current text and provisions relevant to the use.

Use the EUR-Lex consolidated Artificial Intelligence Act text reviewed for this draft, consolidated 27 July 2026. Check for later changes and relevant dates before relying on it.

Questions for an AI vendor

Use these AI vendor EU AI Act compliance questions to structure a discussion, not to reach a legal conclusion:

  • What is the system’s intended purpose, version, configuration, and documented limitation? Which uses are outside that purpose?
  • What role does the vendor believe it has for this system and proposed use? What facts and legal assumptions support that view?
  • Which model, provider, integration, and downstream services are inside the system boundary? How are relevant changes communicated?
  • What instructions, human-oversight information, monitoring or incident channels, and customer actions relate to this use?
  • What information is available to this customer in its actual role? What is confidential, unavailable, or outside the vendor’s control?

Do not assume every provider must give every customer identical technical documentation. Ask the vendor to explain the basis for materials it provides or withholds, record the answer, and have counsel evaluate it.

Third-party and supply-chain responsibilities

For EU AI Act third party obligations and EU AI Act supply chain responsibilities, map the actual relationships: the system provider, model provider, importer or distributor where relevant, deployer, integrator, hosting service, and subprocessors. Note who controls configuration and intended purpose, who communicates changes, which party maintains customer-facing instructions, and who receives incident reports. A contract can allocate tasks between parties, but the review should still identify which entity performs each task and which legal provisions may apply.

Request product and system documentation with its owner, version, date, intended audience, system boundary, and access conditions. Depending on the system and the organization’s role, relevant materials may include product instructions, limitations, version history, security and privacy details, data-flow diagrams, subprocessor information, monitoring and incident channels, and scoped assurance evidence. Record missing materials as unavailable or not yet received, with an owner and next step. A missing document alone does not establish that an obligation was breached.

Separate GDPR and privacy questions

A GDPR AI vendor assessment should examine personal-data processing alongside, rather than as a substitute for, the AI Act role and system review. Map data subjects, data types, purposes, instructions, access, locations, subprocessors, retention, deletion, and rights handling. Determine whether the parties act as controller, processor, joint controllers, or another role from the facts; do not infer those roles from product labels.

Where the GDPR applies, assess the actual processing and agreement against its requirements. Article 28 addresses processor contracts when that relationship applies. Ask privacy counsel to review the facts and the official GDPR text.

Use third-party risk frameworks as organizing aids

NIST AI RMF third party risk questions can help organize voluntary review across Govern, Map, Measure, and Manage. The AI RMF Core is not a checklist and does not determine compliance with EU law. For cybersecurity supplier questions, NIST SP 800-161 Rev. 1 Update 1 addresses cybersecurity supply-chain risk management for systems and organizations.

For an OCC third party risk management guidance AI review, distinguish general supervisory guidance from AI-specific legal requirements. The interagency guidance applies within its scope and provides third-party risk-management context; it does not classify an AI system or replace review of current requirements. Tailor frameworks to the service, decision, and organization, and keep the legal analysis with qualified reviewers.

Keep a decision record

Maintain a dated record of the system and version, intended purpose, deployment context, parties and role assumptions, evidence reviewed and its scope, unresolved questions, assigned reviewer, decision, conditions, and change triggers. Reopen the review when the model, purpose, integration, data flow, subprocessor, or relevant legal text changes. Keep uncertainty visible; avoid collapsing it into a single “compliance” score.

Worked hypothetical example: A support team considers a vendor assistant that drafts replies from published help articles for EU customers. The vendor’s product sheet describes general drafting but does not address a proposed integration that would sort complaints by urgency. The vendor says it handles AI Act compliance but provides no service-specific explanation of roles, system boundary, or material-change process. The buyer records the role analysis as unresolved pending evidence and legal review. It tests only with synthetic data and excludes complaint sorting and production use until the intended purpose, documentation, and roles have been reviewed. This example is not a legal determination or an assessment of a real supplier.

Frequently asked questions

Does a vendor’s stated role settle who is provider or deployer?

No. Treat the statement as one input. Document the system, purpose, parties, and actual responsibilities, then have qualified counsel assess the current legal text.

Does every customer receive the same technical documentation?

Do not assume so. Ask what materials are available to your organization in its actual role, the conditions for access, and the vendor’s basis for any limitation.

Does GDPR review replace an EU AI Act review?

No. Map personal-data processing and applicable GDPR roles separately from the AI Act system, intended-purpose, and operator-role questions.

Does an unanswered diligence question prove non-compliance?

No. Record the gap, its decision relevance, the person responsible for follow-up, and whether the proposed use should be limited or deferred while it remains unresolved.

For practical assessment questions, see the AI Contract Clauses and DPA Checklist, the AI Vendor Assessment Questionnaire, and the AI vendor evaluation guide.

Updated 2026-10-08. Sources are linked on this page.