Buying AI Without Becoming Its Provider: Article 25, the EU Model Contractual Clauses, and the Vendor Due-Diligence Pack

The EU AI Act draws a sharp line between the organisation that builds an AI system and the organisation that buys one. Most buyers assume they sit safely on the second side of that line. Article 25 says otherwise. If you are running an AI procurement process in the EU right now, the single most expensive mistake available to you is signing a contract that quietly converts your organisation into the provider of a high-risk AI system.

A quick disambiguation, because the search results are noisy: this is not a post about AI in procurement, meaning software that automates sourcing, spend analysis or supplier matching. This is about how to procure AI itself, safely, and how to keep provider obligations where they belong.

Here is the scenario. A buyer licenses a general-purpose AI tool. It is not classified as high-risk. The vendor's terms say so. Someone in HR points it at CV screening. That use case sits in Annex III. Under Article 25(1)(c), modifying the intended purpose of an AI system, "including a general-purpose AI system, which has not been classified as high-risk... in such a way that the AI system concerned becomes a high-risk AI system in accordance with Article 6", makes the modifier a provider. No procurement decision was made. No contract was renegotiated. The buyer is now the provider, carrying the full Article 16 obligation set.

The stakes went up this summer. The Digital Omnibus inserts point (da) into Article 99(4), so breaches of Article 25(2) and (4) now attract fines of up to EUR 15,000,000 or 3% of total worldwide annual turnover. The information flow between vendor and buyer is no longer a commercial nicety. It is a directly sanctionable obligation.

This is general information, not legal advice.

The three ways a buyer becomes a provider under Article 25 AI Act

Article 25(1) states that "Any distributor, importer, deployer or other third-party shall be considered to be a provider of a high-risk AI system" and shall be subject to the provider obligations under Article 16, in any of three circumstances.

White-labelling. Article 25(1)(a) catches a party that puts its name or trademark on a high-risk AI system already placed on the market or put into service, "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated".

Read that carve-out carefully. It is the only one in the article. The words "without prejudice to contractual arrangements" appear in point (a) and nowhere else. You cannot contract your way out of points (b) or (c). This is the most commonly misread sentence in the whole provision, and vendors sometimes cite it as if it covered all three triggers. It does not.

Substantial modification. Article 25(1)(b) applies where a party makes a substantial modification to a high-risk system already on the market "in such a way that it remains a high-risk AI system" pursuant to Article 6.

Changing the intended purpose. Point (c), above, is the one that catches ordinary enterprise buyers. It does not require you to touch the model. It does not require engineering work. It requires only that you use the system for something that lands it in Article 6 territory. Deployment decisions taken by a business unit, not by procurement, are where this usually happens.

That is the practical lesson for EU AI Act procurement: the risk classification of what you bought is not fixed at signature. It moves with how you use it.

What the original provider owes you, and the disclaimer that switches it off

When a buyer becomes a provider, the supplier does not simply walk away. Article 25(2) provides that the initial provider "shall no longer be considered to be a provider of that specific AI system" and "shall closely cooperate with new providers and shall make available the necessary information and provide the reasonably expected technical access and other assistance".

"Reasonably expected assistance" was vague. The Digital Omnibus fixed that. Article 25(2) now itemises the duty as "(a) making available of technical documentation sufficient to assess compliance with... Article 16; (b) informing the new providers about known limitations and failure modes; and (c) providing the new providers with targeted technical access, including for testing and validation" (Digital Omnibus).

That is a meaningful upgrade for buyers. It is also switchable.

The escape hatch to search vendor terms for

Article 25(2) "shall not apply in cases where the initial provider has clearly specified that its AI system is not to be changed into a high-risk AI system".

Read that again. A vendor can disclaim the entire cooperation duty with a single clearly drafted sentence in its standard terms. If that sentence is present, and you then change the intended purpose anyway, you become the provider and the vendor owes you nothing under Article 25(2). You would be assembling Annex IV technical documentation for a system whose internals you cannot see.

Make this a named check in every AI vendor due diligence exercise. Search the vendor's terms, acceptable use policy and documentation for any statement that the system is not to be changed into a high-risk system. If it is there, either negotiate it out, buy a supported high-risk configuration instead, or accept that the use case is closed to you.

There is a second written-agreement duty worth pairing with it. Article 25(4), as amended, requires the high-risk provider and any third party supplying an AI system, AI model, tools, services, components or processes to "by written agreement, specify the necessary information, capabilities, technical access and other assistance", with free and open-source tools other than GPAI models excluded.

Expect pushback. Article 25(5) states that paragraphs 2 and 3 are "without prejudice to the need to observe and protect intellectual property rights, confidential business information and trade secrets". That is the anchor vendors reach for. It is a legitimate limit, not a blanket refusal, and the right response is a scoped confidentiality regime, not an abandoned request.

Substantial modification, and the fine-tuning confusion

Article 3(23) defines substantial modification as "a change to an AI system after its placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment carried out by the provider and as a result of which the compliance... with Chapter III, Section 2 is affected or results in a modification to the intended purpose for which the AI system has been assessed".

The escape route is planning. Under Article 43(4), changes pre-determined by the provider at the initial conformity assessment and documented under Annex IV point 2(f) do not require a new conformity assessment. So ask your vendor which changes are already inside the assessed envelope. A documented list of foreseen changes is one of the most useful artefacts a buyer can extract, because it tells you exactly how far you can configure before you cross the line.

Do not import the one-third compute threshold

This is the correction worth internalising. Fine-tuning a general-purpose AI model is governed by a different test: the Commission's GPAI guidelines use an indicative threshold of more than one third of the original model's training compute, together with a significant change in generality, capabilities or systemic risk, and most fine-tuning does not make the modifier a GPAI provider (Commission GPAI guidelines FAQ).

That threshold concerns GPAI model provider status. It says nothing about Article 3(23) substantial modification of a high-risk AI system. There is no Commission guidance applying a compute threshold to Article 3(23).

The two tests are frequently conflated in vendor briefings and in internal policy documents. A small fine-tune that consumes a trivial fraction of the original training compute can still affect Chapter III Section 2 compliance or modify the assessed intended purpose. Compute spent is not the measure. Effect on conformity is.

The EU model contractual clauses for AI: useful, voluntary, and out of date

The most established drafting resource for AI contract clauses in this space is the EU AI Model Contractual Clauses. The MCC-AI were developed by the Community of Practice on the Procurement of AI, hosted in the Public Buyers Community, a site managed by DG GROW (MCC-AI).

The current version was published on 5 March 2025, updating the original clauses of 29 September 2023. There are three artefacts: a full version for high-risk AI aligned with the AI Act as adopted on 13 June 2024, a customisable light version for non-high-risk AI, and a Commentary on how to use, customise and apply them. Translations into 24 EU languages were published on 16 June 2025 (MCC-AI).

Now the gap. There has been no MCC-AI update following the Digital Omnibus, which entered into force on 27 July 2026. As of today the clauses still reference the AI Act as adopted on 13 June 2024. Anyone dropping the model contractual clauses AI package into a tender pack unmodified is contracting against a superseded timeline and a superseded version of Article 25(2). Use them as a drafting base, then overlay the current text yourself.

Two further points of precision. The MCC-AI are voluntary and non-binding. And they are not the same instrument as the Article 25(4) "voluntary model terms", which is a separate AI Office deliverable that remains unpublished. Do not let a bid document conflate them.

For a live example of the direction of travel: on 20 February 2026 the Irish Office of Government Procurement launched a public-sector AI procurement market consultation, explicitly inviting supplier feedback on proposed AI-specific contractual clauses (Public Buyers Community).

The vendor due-diligence evidence pack

Requests should be specific and tied to an article. Vague asks get vague answers.

Evidence to request	Why it matters	Article
EU declaration of conformity and CE marking	Confirms the system was actually assessed and is lawfully on the market; absence tells you the classification story is incomplete	Article 16
Annex IV technical documentation, plus the Annex IV point 2(f) list of pre-determined changes	Tells you the assessed envelope and how far you can configure before triggering a new conformity assessment	Articles 11 and 43(4)
Instructions for use	The foundation for every deployer duty you hold; without it, compliant use is not demonstrable	Article 13
Proof of registration in the EU database	Confirms the provider met its pre-market registration duty and lets you locate the entry you may need to reference	Articles 49 and 71
Post-market monitoring plan	Shows how performance degradation and real-world failure are detected after deployment	Article 72
Serious incident reporting process and deadlines	You need the vendor's clock to line up with yours when something goes wrong	Article 73
A written Article 25(4) agreement covering information, capabilities and technical access	Now directly enforceable with fines up to EUR 15,000,000 or 3% of turnover	Articles 25(4) and 99(4)(da)
Written confirmation of whether the vendor disclaims Article 25(2)	If the disclaimer exists, the cooperation duty is switched off and you would be on your own	Article 25(2)

Article 13 requires instructions for use to be "concise, complete, correct and clear", containing at minimum the provider's identity and contact details and the "characteristics, capabilities and limitations of performance". Treat this as the single most important contractual artefact you can demand. Every deployer duty below depends on it.

The deployer duties your contract has to make possible

Article 26 requires deployers to use the system in accordance with the instructions for use (26(1)); to assign human oversight to natural persons with "the necessary competence, training and authority, as well as the necessary support" (26(2)); where the deployer controls input data, to ensure it is "relevant and sufficiently representative" (26(4)); and to monitor operation, suspend use and inform the provider and market surveillance authority on an Article 79(1) risk (26(5)).

Each one implies a contract term. Oversight requires vendor-supplied training and documentation of what the overseer can actually see and override. Input data representativeness requires knowing what the system was trained and validated on. Suspension requires a contractual right to stop using the system without penalty, plus a vendor notification channel that works to your timeline.

Article 26(6) requires deployers to keep automatically generated logs under their control "for a period appropriate to the intended purpose... of at least six months", unless other Union or national law provides otherwise. In a SaaS arrangement the logs sit on vendor infrastructure. Specify export format, retention, and access on termination.

Article 26(7) requires employers to inform workers' representatives and affected workers before putting a high-risk system into service at the workplace. Build the lead time into your deployment plan, not your go-live week.

Article 27 applies the fundamental rights impact assessment to deployers that are bodies governed by public law, private entities providing public services, and deployers of Annex III points 5(b) and (c), meaning creditworthiness and life and health insurance pricing. The Digital Omnibus amended Article 27(4) and (5) so that deployers may cross-reference or incorporate parts of a GDPR Article 35 DPIA into the FRIA, and the AI Office must develop a questionnaire template including an automated tool to simplify FRIA compliance (Digital Omnibus).

On incidents: Article 73 sets reporting not later than 15 days by default, 2 days for a widespread infringement or an Article 3(49)(b) incident, and 10 days where a person has died, with incomplete initial reports permitted. A vendor SLA that promises a response "within a reasonable period" does not survive contact with a two-day clock.

What applies now, and why today's contracts outlive the runway

Regulation (EU) 2026/1744, the Digital Omnibus on AI of 8 July 2026, entered into force on 27 July 2026 (Official Journal).

It replaced Article 113 third paragraph point (c): Chapter III Sections 1, 2 and 3, which contain Articles 6 to 27 and therefore Articles 13, 25, 26 and 27, apply from 2 December 2027 for AI systems classified high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those under Article 6(1) and Annex I. These are fixed dates in the final text, not conditional on a standards decision.

Certain new Article 5 prohibitions apply from 2 December 2026.

Legacy systems get a narrower reprieve than buyers often assume. Amended Article 111(2) catches legacy high-risk systems only if subject to "significant changes in their designs" after the Chapter III date, but "providers and deployers of high-risk AI systems intended to be used by public authorities shall take the necessary steps to comply... by 2 August 2030". For the public sector that is a hard backstop regardless of whether the system changes.

Draft Commission guidelines on the classification of high-risk AI systems under Article 6 were published on 19 May 2026, non-binding, with a targeted consultation that closed on 23 July 2026 (draft guidelines).

Here is the timing point that matters for procurement. The obligations bite in December 2027. A five-year framework signed this quarter runs well past that. A three-year enterprise licence signed today expires in 2029. The deadline does not land on your compliance team in 2027. It lands on your contracts now, because the terms you agree this autumn are the terms you will be operating under when the obligations apply. Renegotiating mid-term, from a weaker position, costs more than drafting correctly today.

One note on sources: artificialintelligenceact.eu is a helpful consolidation, and anyone drafting binding contract language should verify against the Official Journal text.

The public-buyer angle

Public bodies carry an extra layer. Under Article 49, providers register themselves and the system in the EU database under Article 71 before market, and deployers that are public authorities, Union institutions or bodies, or persons acting on their behalf must register themselves and register the use of an Annex III high-risk system, except Annex III point 2, before putting it into service. That registration is a gate on go-live, so build it into the project plan, not the closeout.

Policy direction reinforces the same posture. The Apply AI Strategy, COM(2025) 723, adopted 8 October 2025, states that the Commission promotes a "buy European" approach "particularly for the public sector, with a focus on open source AI solutions" and an "AI first policy" (Apply AI).

Open source deserves a caution here. Article 25(4) excludes free and open-source tools other than GPAI models from the written-agreement requirement. That removes a supplier obligation, it does not remove your obligation. If you self-host an open component and put it to a high-risk purpose, there is no counterparty to ask for Annex IV documentation. The Irish consultation of 20 February 2026 is the live example of a national buyer working through exactly these questions in the open.

A contracting checklist

1. Classify the use case, not the product. Ask whether any planned or foreseeable use lands the system in Article 6 or Annex III, and record the answer.
2. Search the vendor's full terms for any statement that the system is not to be changed into a high-risk AI system. Escalate immediately if found.
3. Do not rely on the Article 25(1)(a) contractual carve-out for anything other than white-labelling.
4. Demand the Annex IV point 2(f) list of pre-determined changes and treat it as your configuration boundary.
5. Ban the compute-threshold argument from internal risk memos. Article 3(23) turns on effect on conformity, not on training compute.
6. Put an Article 25(4) written agreement in place covering information, capabilities, technical access and assistance, scoped for confidentiality under Article 25(5).
7. Contract for the Article 13 instructions for use as a named, versioned, updateable deliverable.
8. Secure log export and at least six months of retention under your control, per Article 26(6).
9. Align vendor incident SLAs to the Article 73 clocks of 15, 10 and 2 days.
10. Build in worker information lead time (Article 26(7)) and, for public bodies, Article 49 registration before go-live.
11. Start from the MCC-AI, then patch them against the Digital Omnibus. Do not use them off the shelf.
12. Add a regulatory change clause covering the 2 December 2026, 2 December 2027, 2 August 2028 and 2 August 2030 dates.

Closing

Article 25 does not punish buying AI. It punishes buying AI without knowing which side of the provider line your use case sits on, and signing terms that leave you there alone. The good news is that almost all of this is solvable at the drafting stage, cheaply, while you still have commercial leverage and the vendor still wants the deal.

If you are running a tender, renewing a framework, or reviewing a portfolio of AI vendor contracts that will still be live in December 2027, get in touch. A structured read of your existing terms against Article 25, Article 26 and the Digital Omnibus amendments usually takes less time than one procurement committee meeting, and it tends to surface the disclaimer clause before it matters.