You assess an AI vendor under the AI Act by establishing up front which risk category the system falls into, whether the vendor can demonstrate conformity, what technical documentation and transparency information it provides, how data governance is arranged, and whether a general-purpose AI model (GPAI) sits underneath it. You record those answers in your procurement file and split the provider and deployer obligations in the contract, so it is clear who is responsible for what. A vendor that cannot or will not provide this information is itself a risk signal.
The reason to do this up front is practical. Once you procure an AI system and put it into use, you are in many cases the deployer under the AI Act and carry your own obligations, regardless of what the vendor promises. Anyone who only discovers after signing that the system is high-risk, or that the documentation is missing, is locked into a contract without the safeguards the law requires. This guide walks through the questions you ask, what you put in the contract, and how you divide the roles.
What changes and when?
The AI Act phases in, and that determines how strictly you need to question vendors now. The prohibited practices have applied since 2 February 2025 and are enforceable. Article 4 on AI literacy has also applied since 2 February 2025. The transparency obligations of Article 50 take effect on 2 August 2026 and have not been postponed. The GPAI model obligations have applied since 2 August 2025, with full enforcement and fines from 2 August 2026. The heaviest high-risk obligations for standalone Annex III systems have shifted to 2 December 2027, and for high-risk AI embedded in products under Annex I to 2 August 2028.
For procurement this means you already need to be able to determine whether a system is high-risk, even though the hard compliance deadline falls later. Contracts you sign today often run past those deadlines. The runway is meant to get ahead, not to defer, because the evidence file and conformity assessment of a high-risk system are heavy.
The Digital Omnibus, which seeks to amend parts of the AI Act, was endorsed by the European Parliament on 16 June 2026, but as of late June 2026 it is not yet formally adopted law. Until publication in the Official Journal, the original text of Regulation (EU) 2024/1689 applies legally. So plan against the current dates and obligations.
Which questions do you ask the vendor?
The core of vendor due diligence is a structured set of questions. You want to know not only what the system does, but whether the vendor understands and can substantiate its legal position. The checklist below organises the questions along six themes.
| Theme | Question to the vendor | What you want to see |
|---|---|---|
| Risk classification | Which AI Act category does this system fall into, and on what reasoning? | A substantiated answer referencing Annex III or the Article 6 exceptions, not just "not high-risk" |
| Conformity | Can you provide a conformity assessment, CE marking or declaration of conformity? | For high-risk systems: an EU declaration of conformity and registration; for others: a substantiation of why these are not required |
| Technical documentation | Do you supply the technical documentation and instructions for use under Annex IV and Article 13? | Documentation on purpose, capabilities, limitations, performance and the conditions for human oversight |
| Transparency Article 50 | Does the system mark AI-generated or manipulated content and make AI interaction known? | Concrete labelling, watermarking or disclosure functionality you can use as the deployer |
| Data governance | How were training, validation and test data composed, and how was bias tested? | Insight into data sources, representativeness and measures against bias under Article 10 |
| GPAI status | Is there a general-purpose AI model underneath, and is the model provider itself compliant? | Disclosure of the model used, the model provider and its documentation and GPAI status |
If the vendor answers these questions readily and with documents, you procure on a substantiated basis. If the answers come vaguely or only after persistent pressure, the burden of proof shifts to you and your risk as deployer rises.
Watch the classification question. A vendor has an interest in saying "not high-risk", because that lightens its own obligations. Have that conclusion substantiated and test it yourself against Annex III, because as the deployer you share the consequences of a wrong classification.
How do you determine whether the system is high-risk?
Classification determines nearly everything that follows, so it deserves its own step. A system is in principle high-risk if it falls under one of the areas of Annex III, such as AI in recruitment and selection, education, essential private and public services, law enforcement, migration or the administration of justice. In addition, AI is high-risk as a safety component of a product covered by existing EU product legislation (Annex I). Article 6 contains an exception route: a system that appears to fall under Annex III but poses no significant risk to health, safety or fundamental rights can stay outside high-risk, provided the vendor documents this.
Determine the scope of use
Describe concretely what the system does and in which context you deploy it. A generic tool can be low-risk in one application and fall under an Annex III area in another.
Test against Annex III and Annex I
Assess the Article 6 exception
If the vendor claims the exception applies, ask for the substantiation. Documenting that assessment is itself an obligation and belongs in your file.
Record the outcome and the reasoning
It is not only the conclusion that counts, but also the traceable reasoning. In an inspection the supervisor wants to see how you arrived at the classification.
What do you put in the contract?
The contract is where the verbal assurances become enforceable. Without clauses that anchor the AI Act obligations, you are left empty-handed after delivery if it turns out that documentation or conformity is missing. The following elements belong in an AI procurement contract.
- A warranty that the system complies with the applicable AI Act obligations, stating the classification on which that is based.
- The vendor's obligation to provide and keep current the technical documentation, instructions for use and any declaration of conformity.
- Access to the information you need as the deployer for human oversight, logging and, where applicable, a fundamental rights impact assessment under Article 27.
- Arrangements for changes: does the vendor report substantial modifications to the model or system that affect the classification or the risk?
- A GPAI clause: if a general-purpose model sits underneath, the vendor warrants that the model provider meets the associated obligations and makes the required documentation available.
- Cooperation in incidents and in requests from the supervisor, including the information you need for incident reporting.
- A clear division of responsibilities between provider and deployer, so that no obligation falls between the cracks.
A contract that only contains functional specifications and standard legal boilerplate does not cover the AI Act obligations. The compliance layer must be explicit in the contract, otherwise it is not enforceable at delivery.
Who is provider and who is deployer?
The AI Act distributes obligations across roles, and in procurement that role split is your compass. The provider is the party that develops the AI system or places it on the market under its own name. The deployer is the party that uses the system under its own authority, usually your organisation. The heaviest obligations, such as the conformity assessment, the technical documentation and the CE marking for high-risk, lie with the provider. But the deployer has its own duties and cannot contract them away.
| Obligation | Provider | Deployer |
|---|---|---|
| Conformity assessment and technical documentation | Responsible | Requests and keeps in file |
| CE marking and registration of high-risk | Responsible | Verifies presence |
| Use in line with the instructions | Supplies instructions | Responsible |
| Human oversight under Article 14 | Makes it possible | Sets it up and carries it out |
| Transparency to end users (Article 50) | Builds the functionality | Deploys it and informs those affected |
| Fundamental rights impact assessment (Article 27) | Supplies required information | Responsible where required |
| Monitoring and incident reporting | Reports from its own role | Monitors use and reports incidents |
Important is the exception that flips the role. If you substantially modify a high-risk system, place it on the market under your own name, or change the intended purpose such that it becomes high-risk, you can become the provider yourself and inherit all the associated obligations. When procuring AI agents and highly configurable systems this is a real scenario, so test it explicitly.
How do you carry this out in practice?
For carrying out the vendor and contract assessment under the AI Act, Embed AI offers an AI vendor and contract check that walks through the risk classification, the conformity documents, the transparency and data governance questions and the provider versus deployer split, and translates these into concrete contract clauses. Instead of designing the entire question list and role split yourself, you receive a structured assessment that you can include directly in your procurement file.
The same check fits within Embed AI's broader AI Act preparation, in which an AI governance scan and a 30-day Readiness Sprint order scope, AI register, risk classification and evidence. Vendor due diligence is a logical part of that, because procured systems have to flow into your register and your evidence file. As a price indication: the governance scan costs 2,950 euro and is creditable, the Readiness Sprint 9,900 euro, and the bundle of both 21,900 euro.
Alongside the contractual side, the human side counts. The people who assess AI vendors, run the questioning and use the outcomes need sufficient AI literacy to ask the right questions and weigh the answers. LearnWize records that literacy per role in a demonstrable way with assessments, learning paths, training records and an Article 4 evidence file, so that buyers, lawyers and project leads not only sign, but also understand what they are signing. For the legal background to the role split, the article on Article 26 deployer obligations helps, and for the transparency side Article 50 provider versus deployer.
What if the vendor does not cooperate?
A vendor that cannot substantiate the classification, withholds the technical documentation or refuses to include AI Act clauses gives you a clear signal. You are then procuring not just a system, but also a compliance risk that you carry as the deployer. In that case it is wise to reconsider the purchase, look for an alternative vendor, or make the arrangements firm before you sign.
The reverse also holds. A vendor that proactively shares the classification, supplies the documentation and makes the role split clear lowers your risk and accelerates your own compliance file. Vendor due diligence is therefore not only a control, but also a way to choose for parties that take the AI Act seriously.
Frequently asked questions about assessing AI vendors under the AI Act
Short, citable answers for procurement, legal teams and governance leads testing AI vendors under the AI Act.