The three triggers in Article 25(1)
"We only fine-tuned it" is an answer to a question Article 25 never asks. The provision that turns a buyer into a provider counts no training runs and no GPU hours. It asks three questions, and only one has anything to do with training.
Article 25(1) states the consequence first, then the causes: "Any distributor, importer, deployer or other third-party shall be considered to be a provider of a high-risk AI system for the purposes of this Regulation and shall be subject to the obligations of the provider under Article 16, in any of the following circumstances". Then the three circumstances, quoted in full:
(a) "they put their 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".
(b) "they make a substantial modification to a high-risk AI system that has already been placed on the market or has already been put into service in such a way that it remains a high-risk AI system pursuant to Article 6".
(c) "they modify the intended purpose of an AI system, including a general-purpose AI system, which has not been classified as high-risk and has already been placed on the market or put into service in such a way that the AI system concerned becomes a high-risk AI system in accordance with Article 6".
| Trigger | Who usually fires it | Was the system already high-risk? | Does anything technical change? |
|---|---|---|---|
| Name or trademark Art 25(1)(a) | White-labeller, reseller, integrator shipping under its own brand | Yes | No, the branding act is the whole test |
| Substantial modification Art 25(1)(b) | In-house ML team retraining or extending a bought system | Yes, and it stays high-risk | Yes, but the test is Art 3(23), not volume |
| Change of intended purpose Art 25(1)(c) | Product team repurposing a general tool into an Annex III use | No, the only trigger reaching non-high-risk systems | Not necessarily, a new stated purpose is enough |
The consequence is identical in all three cases, and it is the whole of Article 16 rather than a subset: the Chapter III Section 2 requirements, your name and contact address on the system or its packaging, a quality management system under Article 17, the Article 18 documentation and the Article 19 logs, the Article 43 conformity assessment, the Article 47 EU declaration of conformity, CE marking under Article 48, registration under Article 49(1), corrective action under Article 20 and the accessibility requirements of Directives (EU) 2016/2102 and (EU) 2019/882. Recital 84 records one sectoral limit: Article 16(2) of Regulation (EU) 2017/745 continues to apply to high-risk AI systems that are medical devices within that Regulation.
Article 99(4) does not list Article 25. It lists at point (a) the "obligations of providers pursuant to Article 16", which is exactly what a fired trigger imposes: up to 15,000,000 euro or 3 percent of total worldwide annual turnover, whichever is higher. That is not the prohibited-practices tier, and the penalties guide sets out the ladder in full.
The two triggers that need no code
Trigger (a) catches organisations that never opened the model. If a high-risk system is already on the market and you put your name or trademark on it, you are considered a provider. No modification requirement, no threshold, no grace for engineering that was somebody else's.
The clause that follows is read too generously. "Without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated" governs how the obligations sit between the parties. Nothing in Article 25 says a contract stops a person being considered a provider for the purposes of the Regulation. Draft the allocation, and the vendor due diligence checklist sets out what to ask for while you have leverage. Then build the Article 16 evidence anyway.
Trigger (c) is the wider one, and the only trigger reaching systems that sit entirely outside the high-risk regime. It fires when you modify the intended purpose of an AI system "which has not been classified as high-risk" so that it becomes high-risk under Article 6. Note the phrase in the middle: "including a general-purpose AI system". Article 3(66) defines a general-purpose AI system as one based on a general-purpose AI model, so this is the system layer, and reading the word as "model" changes the legal meaning entirely.
Trigger (c) can fire in a product brief. Take a general-purpose assistant already on the market, deploy it unchanged, and start routing it CVs to shortlist. No weights moved and no vendor was told. The intended purpose is now an Annex III point 4 employment use, and on the face of Article 25(1)(c) you are the provider of a high-risk AI system.
The Regulation supplies no threshold for how much repurposing counts. The test is whether the intended purpose has changed such that the system becomes high-risk under Article 6, which makes classification the whole question. The high-risk classification guide works through Annex I and Annex III in order, and the free triage classifier walks the Article 6 tests and names the provision each answer rests on.
What counts as a substantial modification
Trigger (b) is the only one an engineering team would recognise as engineering, and even here the test is documentary rather than technical. Article 3(23) defines a 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 of the AI system with the requirements set out in Chapter III, Section 2 is affected or results in a modification to the intended purpose for which the AI system has been assessed".
Read that as a gate and two doors. The gate: the change was not foreseen or planned in the initial conformity assessment. Past it, either limb suffices: compliance with the Chapter III Section 2 requirements is affected, or the assessed intended purpose is modified. A large retraining run the original provider anticipated and assessed does not pass the gate. A small configuration change that quietly defeats the human oversight design does.
Article 43(4) supplies the consequence. A high-risk system already through a conformity assessment "shall undergo a new conformity assessment procedure in the event of a substantial modification, regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer". Those closing words kill the common internal argument that a change kept inside the organisation and never shipped escapes reassessment.
The second subparagraph is the relief, and it is conditional on paperwork. For systems that continue to learn after being placed on the market, changes "that have been pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation referred to in point 2(f) of Annex IV, shall not constitute a substantial modification". Both must hold, so a retraining cadence everyone understood but nobody wrote into the Annex IV pack is not pre-determined in the sense the provision means. The Annex IV technical documentation guide sets out what point 2(f) expects.
Recital 128 supplies the worked examples: a change of operating system or software architecture may affect compliance, and where the intended purpose changes the system "should be considered to be a new AI system which should undergo a new conformity assessment".
So the question for anyone planning a fine-tune of a bought high-risk system is not how big the run is. It is whether the vendor's initial conformity assessment anticipated it, in writing, which is not answerable from your side of the contract.
What the original provider owes you, and when it owes you nothing
Once a trigger fires, the initial provider "shall no longer be considered to be a provider of that specific AI system" under Article 25(2). The seat is not shared, so you need the underlying material, and the Digital Omnibus rewrote the paragraph to be explicit about what you can ask for.
As replaced by Regulation (EU) 2026/1744, Article 25(2) requires the initial provider to "closely cooperate with new providers and shall make available the necessary information and provide the reasonably expected technical access and other assistance". A new third subparagraph itemises that, where relevant: "(a) making available of technical documentation sufficient to assess compliance with the requirements laid down in 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."
Then the carve-out, the sentence to read before you plan anything. The paragraph "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 and therefore does not fall under the obligation to cooperate with the new providers and hand over the documentation". The Omnibus widened what that disapplies: the 2024 text disapplied the obligation to hand over the documentation, the replacement disapplies the obligation to cooperate as well.
Check the upstream terms before the roadmap, not after. A clear statement in the vendor's terms that its system is not to be turned into a high-risk system is not a warning label. It is a switch that leaves you holding the entire Article 16 set with no entitlement to its technical documentation, no duty on it to disclose known failure modes, and no right to testing access.
Article 25(3) puts the product manufacturer in the provider seat where a high-risk system is a safety component of a product covered by Annex I Section A harmonisation legislation, on either of two limbs: placed on the market with that product under the manufacturer's name or trademark, or put into service under that name after the product has been placed. Article 25(5) preserves intellectual property rights, confidential business information and trade secrets, but only as against paragraphs 2 and 3. The provider and deployer guide maps how the roles travel through a supply chain.
Supplying tools into someone else's high-risk system
The duty runs in the other direction too, and the Omnibus enlarged it. Article 25(4), first subparagraph, as replaced, requires that "the provider of a high-risk AI system and the third party that supplies an AI system, AI model, tools, services, components, or processes that are used or integrated in a high-risk AI system shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance based on the generally acknowledged state of the art, in order to enable the provider of the high-risk AI system to fully comply with the obligations set out in this Regulation".
Two words there are new. The 2024 text read "an AI system, tools, services, components, or processes"; Regulation (EU) 2026/1744 inserted "AI model". Anyone shipping a model into a customer's high-risk pipeline is now named in the provision rather than argued into it. The obligation is a written agreement, not goodwill, and the benchmark is the generally acknowledged state of the art.
The exception is narrow and its final words decide most real cases. The paragraph "shall not apply to third parties making accessible to the public tools, services, processes, or components, other than general-purpose AI models, under a free and open-source licence". Publishing a general-purpose AI model under an open licence therefore does not buy the exception, because such models are expressly excluded from it. The open-source exemptions article walks the same pattern across the other exemptions.
The second subparagraph lets the AI Office develop and recommend voluntary model terms for these contracts, published free of charge. Note what Article 25(5) does not do: its saving for intellectual property, confidential business information and trade secrets is expressed to cover paragraphs 2 and 3, so a supplier declining to specify anything in the written agreement on trade-secret grounds is not relying on Article 25(5) as drafted.
Fine-tuning a general-purpose AI model is a different question
Here is the separation most internal memos miss. Article 25 makes you the provider of a high-risk AI system. It cannot make anyone the provider of a general-purpose AI model. That belongs to Chapter V, and the honest description of Chapter V is that the AI Act contains no trigger article for it at all.
What the Act does contain is two recitals. Recital 97 records the practice: "These models may be further modified or fine-tuned into new models." Recital 109 supplies the limiting principle, that "the obligations for providers of general-purpose AI models should be limited to that modification or fine-tuning", with the example of complementing the existing technical documentation with information on the modifications and new training data sources. Neither is an article, and Article 3(68) does not fill the gap: it defines a "downstream provider" as a provider of an AI system that integrates an AI model, which is the system layer again.
If you do become the provider of a general-purpose AI model, Article 53(1) sets the baseline: Annex XI technical documentation for the AI Office, Annex XII information for downstream providers, a copyright policy including the Article 4(3) rights reservation under Directive (EU) 2019/790, and a public summary of the training content. Article 53(2) exempts the first two for qualifying free and open-source releases, but not for models with systemic risk. The general-purpose AI obligations guide covers the rest of Chapter V.
The Regulation does give a number here, and it is not the number usually quoted. Article 51(2) presumes high impact capabilities where "the cumulative amount of computation used for its training measured in floating point operations is greater than 10^25", and recital 111 confirms the count includes pre-training, synthetic data generation and fine-tuning. So fine-tuning compute counts towards the systemic-risk presumption, which is a different question from who the provider is.
The one-third test lives elsewhere. In its guidelines on the scope of the obligations for general-purpose AI models, C(2025) 5045 final of 18 July 2025, the Commission takes the view at paragraph 62 that a downstream modifier becomes the provider of the modified model "only if the modification leads to a significant change in the model's generality, capabilities, or systemic risk", and at paragraph 63 offers as an indicative criterion that the training compute used for the modification exceeds a third of the original model's training compute, with fallbacks at paragraph 64 where the original figure is unknown. Paragraph 68 applies recital 109's limitation, paragraph 69 adds the Article 54 authorised representative, and paragraphs 70 and 71 state the Commission's position that modifying a systemic-risk model so as to become its provider yields a model presumed to have high-impact capabilities, with an Article 52(1) notification to follow.
Treat the one-third figure as what it is. Paragraph 9 of the same guidelines states that they "are not binding for providers of general-purpose AI models" and that an authoritative interpretation of the AI Act may only be given by the Court of Justice of the European Union. That version is dated 18 July 2025 and predates Regulation (EU) 2026/1744. A compute ratio is a useful planning input and a poor legal position to stand on alone.
What the Digital Omnibus changed, and what it did not
Regulation (EU) 2026/1744 of 8 July 2026, published at OJ L, 2026/1744, 24.7.2026 and in force since 27 July 2026, touched Article 25 in exactly two places. Paragraph 2 was replaced, gaining the itemised cooperation list and the widened carve-out. The first subparagraph of paragraph 4 was replaced, gaining "AI model". The Digital Omnibus guide covers the wider package.
What it left alone matters more for anyone assessing exposure now. Article 25(1), Article 3(23) and Article 43(4) were not amended, so all three triggers, the definition of substantial modification and the conformity-assessment consequence read exactly as adopted in 2024. Articles 51 to 55 were not amended either, so the 10^25 presumption and the Article 53 obligations stand.
One further amendment bears on legacy systems. Article 111(2) was replaced, swapping the fixed date trigger for a cross-reference to the date of application of Chapter III referred to in Article 113, while leaving the operative test intact: systems placed on the market before that date come into scope "only if, as from that date, those systems are subject to significant changes in their designs". Omnibus recital 39 confirms that any such change triggers full compliance with the provisions applicable to high-risk AI systems, conformity assessment included. Mind the vocabulary gap, though: Article 3(23) defines "substantial modification", while "significant changes in their designs" is left undefined, and recital 128 speaks only to the former. Nothing equates the two, so Article 3(23) is the nearest defined benchmark, not the governing test.
Four things worth settling before the next model change ships:
- Record the assessed intended purpose of every high-risk system you operate, in the vendor's words, so a departure from it is detectable rather than arguable.
- Get the vendor to state which modifications its initial conformity assessment foresaw. That answer decides trigger (b) for every change you make afterwards.
- Read the upstream terms for a clear specification that the system is not to be changed into a high-risk system: that sentence disapplies Article 25(2) entirely.
- Keep the two analyses apart. Article 25 governs the system and has three statutory triggers. Chapter V governs the model, has none, and rests on recital 109 plus guidance binding nobody.