Buying AI: supplier due diligence before you sign

The supplier sends you a slide: "our software is AI Act compliant." That is a claim, not evidence. The right question, before you sign, is a different one: which documents will you hand over, which controls will you leave me, and what happens when the system changes? When the authority knocks, the supplier will not answer in your place: each party answers for its own role.

The contract is where compliance becomes verifiable

Regulation (EU) 2024/1689 (the AI Act) assigns different obligations to whoever provides an AI system and whoever uses it under their own authority (the deployer). If you buy software, you are almost always a deployer — but the deployer obligations in Article 26 can be met only if the supplier has given you certain things: complete instructions for use, human oversight tools, exportable logs.

The legislator says so openly. Article 25(4) requires the provider of a high-risk system and the third parties supplying it with tools, services or components to settle by written agreement the information, capabilities and technical access needed for compliance (with an exemption for components released under a free and open-source licence). The same logic applies downstream, towards you: if it is not in the contract, you will not have it.

This is not a theoretical problem. Article 99(4) provides for fines of up to EUR 15 million or 3% of total worldwide annual turnover for infringements of, among others, the obligations in Articles 25(2) and (4), 26 and 50. For SMEs and start-ups, Article 99(6) applies the lower of the two figures: a mitigation, not an exemption.

The three doors through which you become a provider without noticing

Article 25(1) lists three situations in which a buyer becomes a provider, inheriting the Article 16 obligations:

1. Branding. You put your name or trademark on a high-risk system already placed on the market or put into service: the classic white label.
2. Substantial modification. You substantially modify a high-risk system that remains high-risk. Article 3(23) defines a substantial modification as a change not foreseen in the initial conformity assessment that affects compliance with the requirements or changes the intended purpose.
3. Change of purpose. You change the intended purpose of a system — including a general-purpose AI system — that was not classified as high-risk, so that it becomes high-risk.

Two lines in a commercial proposal ("customisation with client branding", "fine-tuning on your data") can shift the entire regulatory weight onto you. Read them carefully and, if necessary, rewrite them.

The questions to ask before signing

What exactly am I buying

• Is the product an AI system within the meaning of Article 3(1)? Does it integrate a third-party general-purpose AI model? Which one, and which version?
• What is the declared intended purpose, and does my use case fall within it? Stepping outside it is the fastest route into Article 25(1)(c).
• Does the supplier consider the system to fall under Annex III? Who performed that classification, and on the basis of which documentation?

Documentation that must be delivered, not "available on request"

• Instructions for use compliant with Article 13(3): the provider's identity and contact details; intended purpose, context and conditions of use; the level of accuracy including its metrics, robustness and cybersecurity; known or foreseeable circumstances that may create risks to health, safety or fundamental rights; input data specifications; human oversight measures; the computational resources needed, expected lifetime and maintenance; a description of the logging mechanisms.
• If a third-party GPAI model sits underneath: the documentation its provider must make available to downstream integrators under Article 53(1)(b) and Annex XII.

Operational control: will I actually be able to comply with Article 26?

• Logs. Does the system generate them, and can I export and retain them? Article 26(6) requires the deployer to keep them for at least six months, unless other law provides otherwise. If they stay in the supplier's cloud and cannot be exported, the obligation is unworkable.
• Human oversight. Which technical tools do you give me to interpret the output and intervene? Article 26(2) requires me to assign oversight to people with the necessary competence, training and authority: without tools, that authority is fiction.
• Input data. Where I control it, Article 26(4) requires it to be relevant and sufficiently representative in view of the intended purpose. What guidance do you give me to ensure that?
• Incidents and changes. Through which channel, and within what timeframe, will you notify me of malfunctions, serious incidents or a change of the underlying model?

Personal data and parallel obligations

• A processing agreement under Article 28 GDPR, with one point always to be clarified: are my data and my employees' prompts used to train your models? If so, how do I opt out?
• Does the Article 13 information reach me in a form usable for my DPIA? Article 26(9) assumes exactly that step.
• If the system generates synthetic content or interacts with people: who applies the Article 50 markings and disclosures — you in the product, or me downstream?
• If I deploy it at the workplace, Article 26(7) requires me to inform workers' representatives and affected workers before putting it into service.

The EU model clauses: a tender document already written

There is no need to start from scratch. On 5 March 2025 the Community of Practice on Public Procurement of AI, supported by the European Commission, published the updated EU model contractual clauses for AI procurement (MCC-AI): a full version aligned with the Chapter III requirements for high-risk systems; a light, customisable version for non-high-risk systems; and a commentary explaining how and when to use them. They are available in 24 EU languages.

Two caveats: they are voluntary — no rule imposes them — and they are written for public buyers. For a private SME they nonetheless remain the best free starting point available: use them as a negotiation checklist on transparency, risk management, data governance, human oversight, cybersecurity and lifecycle monitoring, even when you do not adopt them verbatim.

The dates matter more than they seem

A software contract typically runs three to five years; the legal framework, in the meantime, moves. After Regulation (EU) 2026/1744 (the "Digital Omnibus" on AI, published in the Official Journal on 24 July 2026 and in force since 27 July 2026), the calendar looks like this:

The practical consequence is a single one: the system you buy today as "not high-risk" may be reclassified — by a change in your use case or by later guidance. Put in the contract a supplier commitment to maintain compliance at the future application dates, with a notice obligation and a right to terminate if they do not get there.

And remember that some rules already apply today: the prohibitions in Article 5, the AI literacy obligation in Article 4 — reformulated by the Omnibus in terms of "effective and proportionate" measures, without requiring a guaranteed level of literacy for any given individual — and, in Italy, the client disclosure on AI use introduced by Law 132/2025 for the intellectual professions.

Where to start

Before negotiating, you need to know what you are buying and which role it puts you in. An independent gap assessment of your application estate — which systems you have, what risk they carry, which documents are missing — turns a negotiation made of claims into a specification with verifiable requirements. It is the best-spent hour of the project: far cheaper than a migration decided afterwards.