EU AI Act Vendor Due Diligence: AI Supplier Compliance Guide

Organizations increasingly rely on third-party AI systems, models and AI-enabled software. That makes supplier assessment an important AI governance and procurement control.

But EU AI Act vendor due diligence is not a yes-or-no exercise based on asking whether a supplier is "EU AI Act compliant." The EU AI Act assigns responsibilities according to defined legal roles, the AI system or model involved, its intended purpose, its classification and how it is actually placed on the market, put into service or used.

The purchasing organisation therefore needs to understand what is being supplied, identify the relevant regulatory roles, assess its proposed use, test supplier claims against appropriate evidence, establish contractual protections and continue monitoring the system after deployment.

A practical framework is:

Supplier claim → required evidence → buyer verification → contractual protection → ongoing monitoring

This guide explains how to apply that framework throughout the AI procurement lifecycle.

Legal position checked: 24 September 2026. The legal baseline for this article is the current consolidated version of Regulation (EU) 2024/1689 on EUR-Lex, reflecting Regulation (EU) 2026/1744, which entered into force on 27 July 2026. Article 50 transparency obligations apply from 2 August 2026, subject to a transition until 2 December 2026 for Article 50(2) marking obligations for relevant generative AI systems placed on the market before 2 August 2026. The main high-risk rules apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product-related systems. GPAI obligations have applied since 2 August 2025, with Commission enforcement powers applying from 2 August 2026.

This article provides general regulatory information, not legal advice for a specific system or transaction.

What Is EU AI Act Vendor Due Diligence?

EU AI Act vendor due diligence is the process of assessing an AI supplier, the supplied system, intended use, regulatory roles, evidence, risks and contractual arrangements so an organisation can make an informed procurement and governance decision.

"Vendor" and "supplier" are practical commercial terms. They are not standalone operator categories under the AI Act.

The AI Act's current definitions instead include provider, deployer, importer, distributor, product manufacturer and authorised representative. The Act separately regulates providers of general-purpose AI models.

That distinction matters because supplier assessment and statutory compliance are not the same thing.

A generic statement that a product is "EU AI Act compliant" does not establish who the provider is, whether the buyer's use matches the provider's intended purpose, whether Article 50 applies, whether a future high-risk classification is relevant, or what obligations remain with the buyer.

Supplier information should therefore feed into the organisation's own governance analysis. For the broader regulatory framework, see the EU AI Act compliance guide.

Who Is Responsible Under the EU AI Act: Provider, Deployer or Supplier?

The first legal question in AI procurement is not "Who is the vendor?" It is "Which legal role does each relevant party perform for this system or model?"

Provider

Under Article 3, a provider is broadly the person or entity that develops an AI system or GPAI model, or has it developed, and places it on the market or puts the AI system into service under its own name or trademark.

The commercial supplier and legal provider therefore need not be identical.

A reseller might contract with the buyer while another company is the provider. A software company may integrate a GPAI model supplied by a separate model provider. A systems integrator may combine several upstream components.

Procurement should identify the contracting supplier and the legal provider or providers relevant to the solution.

Deployer

A deployer is broadly a person or organisation using an AI system under its authority, except for personal, non-professional use.

Purchasing an AI system does not automatically transfer the buyer's deployer responsibilities to the supplier.

This becomes particularly important for high-risk systems. Once the relevant high-risk provisions apply, Article 26 addresses matters including use in accordance with instructions, appropriately assigned human oversight, monitoring and incident-related actions. The Commission's current AI Act implementation information for high-risk providers and deployers summarises these responsibilities.

When a Buyer Can Become a Provider

Article 25 addresses specific circumstances in which a distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system.

These include situations where the actor:

• puts its name or trademark on a high-risk AI system already placed on the market or put into service;

• makes a substantial modification to an existing high-risk AI system so that it remains high-risk; or

• changes the intended purpose of a previously non-high-risk AI system, including a general-purpose AI system, so that it becomes high-risk.

Article 25 does not mean that every configuration, integration, customisation or rebranding exercise automatically converts the buyer into a provider. The statutory conditions must be assessed against what actually changed.

Regulation (EU) 2026/1744 also amended Article 25. Where the circumstances in Article 25(1) occur, the initial provider is required, subject to the provision's conditions and exception, to cooperate with the new provider by supplying necessary information, reasonably expected technical access and other assistance. The amendment also expressly includes AI models within the value-chain agreement provision in Article 25(4).

Because Article 25 sits within the deferred high-risk provisions, the relevant rules apply from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I product-related systems. Organisations should nevertheless consider potential Article 25 consequences when designing procurement, integration and change-management arrangements now.

Why AI Supplier Due Diligence Matters Before You Buy

AI supplier claims can be accurate but incomplete.

A supplier may classify its product based on one intended purpose while the buyer plans to use it differently. A software product may contain AI functionality the procurement team did not initially identify. A service may depend on an external GPAI model whose capabilities, limitations or versions can change.

Documentation also matters. If procurement accepts a classification, performance or compliance claim without understanding its basis, the organisation may later discover that it lacks the information needed to operate, monitor or reassess the system.

GPAI dependencies are a good example. Article 53 requires providers of GPAI models to maintain specified technical documentation and provide specified information and documentation to downstream providers integrating the model into their AI systems. It also imposes copyright-policy and training-content-summary obligations. These duties have applied since 2 August 2025, and the Commission's current GPAI provider guidelines explain their scope.

That does not mean every enterprise customer automatically receives the GPAI provider's full Article 53 technical file. The buyer should instead establish who the upstream model provider is, how its model is used in the supplied product, and what relevant model information the direct supplier can provide.

Procurement is therefore an important AI governance control point. It is the stage at which information rights, supplier cooperation and change obligations can be addressed before the system becomes operationally embedded.

What Should You Check in an AI Vendor Due Diligence Assessment?

1. Supplier and AI System Identity

Start by establishing exactly what is being supplied.

Record the legal contracting entity, the AI system or product name, the legal provider, the relevant version, material AI functionality and significant third-party dependencies.

Where relevant, identify:

• underlying GPAI or other model providers;

• systems integrators and subcontractors;

• relevant subprocessors;

• importers or distributors;

• authorised representatives where legally applicable.

The objective is a traceable system and supply-chain record. A supplier's corporate name alone is not sufficient.

2. Intended Purpose and Actual Use Case

Article 3 defines intended purpose by reference to the use intended by the provider, including the specific context and conditions reflected in instructions for use, promotional or sales materials, statements and technical documentation.

Compare that documented purpose with what the purchasing organisation actually intends to do.

Ask:

• Which business process will the system support?

• Who will use it?

• Who could be affected by its output?

• Will its outputs inform or determine consequential decisions?

• Is the buyer's use within the supplier's documented operating conditions?

• What reasonably foreseeable misuse should be considered?

Classification should be assessed against the actual use case, not merely the product's marketing category.

3. AI Risk Classification

First determine whether the relevant functionality falls within the AI Act's scope. Then assess the provisions that may apply, including prohibited-practice, high-risk and transparency requirements.

For high-risk AI, Article 6 contains two principal routes. One concerns specified AI used as a safety component of, or itself constituting, a product covered by Annex I legislation. The other covers use cases listed in Annex III. Article 6(3) also contains conditions under which certain Annex III systems are not treated as high-risk, although an Annex III system performing profiling of natural persons remains high-risk.

Do not ask only:

"Is this product high-risk?"

Ask:

"What intended purpose and Article 6 analysis support your classification, and what evidence can we review?"

The European Commission published draft high-risk classification guidelines in May 2026. As of 24 September 2026, those guidelines remain draft, with final guidance expected by the end of 2026. They are useful interpretative material, but they should not be treated as binding legislation.

Article 50 should be assessed separately because its transparency obligations are already applicable. Depending on the system and role, they address direct interaction with AI, machine-readable marking of specified synthetic content, emotion recognition and biometric categorisation notices, deepfake disclosure and specified public-interest text. The Commission's final Article 50 transparency guidelines provide current implementation guidance.

4. Regulatory Documentation and Evidence

Request evidence that corresponds to the supplier's claim, the system and the applicable legal role.

Depending on the circumstances, relevant material can include:

• instructions for use;

• classification documentation;

• appropriate technical-documentation evidence;

• conformity-assessment information;

• an EU declaration of conformity;

• CE-marking information;

• applicable registration information;

• testing and evaluation evidence;

• performance characteristics and known limitations.

These documents do not apply to every AI system or every supplier.

For high-risk systems, the AI Act contains requirements covering technical documentation, information for deployers, conformity assessment, declaration of conformity, CE marking and registration where the respective provisions apply. The consolidated Regulation should be used when determining the exact requirement for the system concerned.

Evidence collected during supplier assessment can also support a wider EU AI Act compliance audit, but a vendor evidence review is not itself proof of organisational compliance.

5. Human Oversight and Operational Controls

Determine what users need to know and do when operating the system.

Assess how users can:

• understand relevant capabilities and limitations;

• interpret outputs appropriately;

• identify anomalies or unexpected performance;

• intervene or override an output;

• stop or suspend use where appropriate;

• escalate concerns.

For future high-risk deployments, Article 26 requires deployers to assign human oversight to people with the necessary competence, training and authority, along with necessary support.

Supplier documentation should therefore be tested against the buyer's operating environment. A technically available override mechanism is of little value if the organisation has no defined person authorised to use it.

6. Data Governance and Privacy

Establish what data enters, leaves and is retained by the service.

Review:

• categories of customer and personal data;

• data sources;

• retention;

• training, fine-tuning or product-improvement use;

• subprocessors;

• relevant hosting or transfer arrangements;

• deletion and data-return mechanisms.

Statements such as "we do not train on customer data" should be sufficiently precise to explain the treatment of prompts, uploaded files, feedback, logs and derived data.

EU AI Act due diligence does not replace GDPR due diligence.

Where personal data is processed, privacy teams should separately assess the GDPR and other applicable data-protection requirements.

7. Security, Logging and Incident Management

Assess the service's cybersecurity controls, available logging, monitoring, evidence retention and escalation arrangements.

For supplier due diligence, establish:

• what events the supplier monitors;

• what logs the customer can access;

• how security and AI incidents are investigated;

• when customers are informed;

• what information the supplier will provide;

• how the supplier supports regulatory investigations.

Do not invent one universal AI Act incident-notification deadline for every vendor relationship.

Article 73 creates serious-incident reporting obligations for providers of high-risk AI systems once the relevant high-risk regime applies, while Article 55 already imposes serious-incident obligations on providers of GPAI models with systemic risk. The Commission's current GPAI materials confirm that the latter obligations are already within the enforceable GPAI framework.

A buyer may need shorter contractual notification periods than the supplier's own statutory deadline so that the buyer has time to investigate and meet any obligations that apply to it.

8. Changes, Updates and Model Lifecycle

AI supplier risk is not static.

Establish how the supplier manages:

• model or version changes;

• replacement of upstream models;

• new AI functionality;

• changed data sources;

• material modifications;

• updated instructions or limitations;

• product retirement.

Define which changes require notification, reassessment or approval.

Version management matters because the organisation should be able to identify which product and evidence were actually assessed.

Exit planning should also cover data retrieval, deletion, continuity and preservation of records needed for governance or investigations.

What Evidence Should an AI Supplier Provide?

The evidence request should follow the claim being tested. Not every supplier must provide every document below.

Supplier responses that should trigger deeper review include an unsupported "fully AI Act compliant" statement, an inability to identify the legal provider, a risk classification with no intended-purpose analysis, unclear customer-data training terms, material product changes without notification, or conformity evidence that cannot be matched to the system version being purchased.

AI Vendor Due Diligence Questionnaire: Questions to Ask Suppliers

A useful AI vendor questionnaire should produce evidence, not a collection of yes/no assurances.

Supplier and Role Questions

• Who is the legal provider of the AI system?

• What AI Act role does the contracting supplier consider itself to perform?

• Which other entities materially contribute to the system?

• Are third-party AI models, GPAI models or subcontractors used?

• Is an authorised representative required and, if so, who is it?

Classification Questions

• What is the system's documented intended purpose?

• How has the system been assessed under the AI Act?

• Does the supplier identify an Article 6 or Annex III high-risk use case?

• What evidence supports the classification?

• Does the supplier rely on an Article 6(3) conclusion that an Annex III system is not high-risk? If so, what is the documented basis?

• Which Article 50 obligations, if any, does the supplier consider applicable to the provider and to the intended deployment?

Documentation Questions

• What regulatory and operating documentation is available to the customer?

• What limitations and instructions accompany the system?

• What conformity evidence applies, if any?

• Where Article 50 applies, how can the buyer verify disclosure or machine-readable marking functionality?

• How are documentation changes communicated?

• Which documents are version-specific?

Data and Security Questions

• What customer and personal data does the system process?

• Is customer information used for model training, fine-tuning or service improvement?

• Which relevant subprocessors and model providers are involved?

• What security and AI incident process applies?

• What logging is available to the customer?

• What evidence can be preserved or exported after an incident?

Lifecycle Questions

• How are significant model, feature or provider changes communicated?

• How are versions identified and managed?

• What events trigger regulatory or risk reassessment?

• Can the underlying model be replaced without customer notice?

• What happens to data, records and functionality when the service is discontinued?

The strongest questionnaires connect each answer to a decision: accept the evidence, request clarification, apply a control, change the contract, restrict the use case, or escalate the procurement.

What Should an AI Vendor Contract Cover?

The EU AI Act does not prescribe one universal set of clauses for every AI purchasing contract.

There is, however, a specific value-chain provision in Article 25(4). Once applicable to the relevant high-risk system, the provider of a high-risk AI system and a third party supplying an AI system, AI model, tools, services, components or processes used or integrated in that high-risk system must specify certain necessary information, capabilities, technical access and other assistance by written agreement, subject to the provision's scope and exceptions. Regulation (EU) 2026/1744 expressly amended this provision to include AI models.

Other contractual clauses are procurement controls rather than universal AI Act mandates.

A contract can allocate commercial responsibilities and cooperation duties. It cannot simply rewrite the legal role that follows from the Regulation and the parties' actual activities.

How to Run an EU AI Act Vendor Due Diligence Process

A repeatable supplier process should connect to the organisation's wider EU AI Act compliance process rather than operate as a standalone procurement form.

Step 1: Identify the AI System and Business Use

Describe the AI functionality being purchased and the business process, decision or service it will support. Avoid classifying an entire software suite when only particular functions use AI.

Step 2: Identify the Parties and Regulatory Roles

Map the contracting supplier, legal provider, buyer/deployer, relevant model providers and material intermediaries. Do not rely solely on labels used in the commercial contract.

Step 3: Assess Intended Purpose and Risk Classification

Compare the provider's documented purpose with the proposed deployment. Test the supplier's classification against the current Regulation and applicable Commission guidance.

Step 4: Send the Supplier Questionnaire

Tailor questions to the system and use case. A recruitment system, coding assistant and customer chatbot should not receive identical evidence requests.

Step 5: Collect and Verify Evidence

Connect significant supplier claims to documents or testable functionality.

Do not record:

"Supplier confirms compliance."

Record:

"Supplier states X. Evidence Y was reviewed. Buyer verification produced conclusion Z."

Step 6: Identify Compliance and Governance Gaps

Record missing evidence, unclear roles, unsupported assumptions, privacy or security concerns and operational controls that the organisation must implement.

Step 7: Resolve Gaps Before Procurement Approval

Resolve material issues through further evidence, restricted functionality, system configuration, additional controls, contractual commitments or a decision not to approve the proposed use.

Step 8: Address Requirements in the Contract

Translate continuing dependencies into enforceable obligations where appropriate, particularly evidence access, change notifications, incident cooperation and exit arrangements.

Step 9: Record the Assessment

Maintain the decision, intended use, roles, evidence reviewed, limitations, approvals, unresolved issues and reassessment triggers in the organisation's governance records.

Step 10: Reassess After Material Changes

Reopen the assessment when the system, underlying model, supplier structure, functionality, intended use or regulatory position changes materially.

Professionals building this workflow into a wider compliance programme can use an EU AI Act compliance audit to test whether role decisions, supplier evidence and controls remain current.

For deeper practical knowledge of the regulatory requirements behind these decisions, professionals can also explore EU AI Act compliance training.

How to Manage AI Vendors After Onboarding

Supplier due diligence should not end when the agreement is signed.

Monitor product releases, model replacements, new AI functionality, documentation updates, security or AI incidents, changes in important third-party dependencies and changes to the organisation's own use.

Supplier performance should also be monitored against the commitments obtained during procurement. For example, if the contract requires notice before a material model change, that control needs an owner who receives and assesses the notice.

Use both periodic and event-driven reassessment.

The AI Act does not prescribe one universal annual or quarterly vendor-review frequency. Organisations should establish review intervals according to system impact, supplier dependency, rate of change and internal third-party risk policy.

Event-driven triggers can include:

• material system or model changes;

• new functionality;

• expansion to a new use case;

• significant incidents;

• changed supplier or model-provider arrangements;

• material documentation changes;

• new binding legislation or relevant regulatory guidance.

Keep these records linked to the organisation's AI inventory. For a broader operating model, EU AI Act compliance for compliance teams should connect supplier monitoring with legal, privacy, security, business and risk functions rather than leaving it solely with procurement.

Common AI Vendor Due Diligence Mistakes

Treating a "EU AI Act compliant" statement as sufficient

A general statement does not establish the supplier's role, classification, applicable obligations or evidence.

Correction: Convert the claim into specific propositions and ask what supports each one.

Using only a generic cybersecurity questionnaire

A security assessment can miss intended purpose, classification, transparency, human oversight and regulatory-role questions.

Correction: Add AI-specific regulatory, data, operational and lifecycle questions to the existing third-party process.

Failing to assess the buyer's intended use

Supplier classification may be based on a use that differs from the buyer's deployment.

Correction: Document the actual proposed use and compare it with the provider's intended purpose before approval.

Ignoring modifications and customisation

Changes can affect system performance, evidence and regulatory analysis. In specified future high-risk circumstances, Article 25 can also change which actor is treated as provider.

Correction: Put customisation and significant change within formal AI change management.

Checking compliance only before signing

Models, features and dependencies can change after approval.

Correction: Establish supplier notification rights, monitoring responsibilities and reassessment triggers.

Confusing certifications or standards with legal compliance

A standard, certification or management-system framework may provide useful evidence, but it should not automatically be treated as proof that every applicable AI Act obligation has been met.

Correction: Map the certification or assurance evidence to the specific claim it is intended to support.

Ignoring underlying GPAI or third-party model dependencies

The direct supplier may depend on an upstream model provider whose capabilities, acceptable-use conditions or versions affect the service.

Correction: Identify material model dependencies and determine what relevant information reaches the supplier and, where needed, the buyer. The Commission's GPAI guidance is particularly relevant where the supplier integrates a GPAI model.

EU AI Act Vendor Due Diligence Checklist

Use this operational checklist alongside the broader EU AI Act compliance checklist.

Before procurement

• Identify the AI system and relevant functionality.

• Identify the contracting supplier and legal provider.

• Define the buyer's intended use.

• Assess relevant prohibited, high-risk and Article 50 considerations.

• Map relevant regulatory roles.

Before contract signature

• Request evidence proportionate to the system and claims.

• Review classification and operating documentation.

• Review privacy and customer-data use.

• Review security, logging and incident arrangements.

• Address supplier cooperation, change and exit provisions.

Before deployment

• Confirm the approved intended use and operating limitations.

• Assign internal governance responsibilities.

• Confirm required human oversight.

• Establish monitoring and escalation arrangements.

• Record the assessment, evidence and approval.

During operation

• Monitor model, product and supplier changes.

• Track incidents and significant performance issues.

• Keep relevant documentation current.

• Reassess when the technology or intended use materially changes.

• Reassess the supplier according to organisational risk and policy.

Conclusion

Good EU AI Act vendor due diligence is evidence-based and lifecycle-based, not a one-time checkbox asking whether a supplier says it is compliant.

The practical sequence is:

clear roles → intended purpose and risk assessment → evidence → buyer verification → contractual controls → ongoing monitoring

An organisation should know what AI system it is buying, who provides it, how it will actually be used, what evidence supports the supplier's regulatory position, which responsibilities remain with the organisation, what information it can obtain after deployment and what events will trigger reassessment.

That approach turns AI procurement into a meaningful governance control rather than an exercise in collecting supplier assurances.

Professionals who need deeper knowledge of role mapping, classification, provider and deployer responsibilities, evidence and lifecycle governance can explore EU AI Act Compliance Training from AI Governance Courses.