The EU AI Act's Definition of "Substantial Modification"

Change a high-risk AI system enough and you become its provider, or owe it a fresh conformity assessment. Article 3(23) is the definition that decides how much is enough, and it does less work than most people expect — because it does not apply to models at all.

The definition, clause by clause

Article 3(23) of Regulation (EU) 2024/1689 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 either the compliance of the system with the requirements in Chapter III Section 2 is affected, or there is a modification to the intended purpose for which the system was assessed. The text is at EUR-Lex.

Read it as three cumulative elements and a disjunction:

• A change to an AI system. Not a model. Not a dataset in the abstract. An AI system as defined in Article 3(1), after it has been placed on the market or put into service. A change made before that moment is simply development.
• Not foreseen or planned in the initial conformity assessment. This is the element that gives providers control, and it is the one to design around. What was assessed as possible is not a substantial modification when it happens.
• Either compliance with Chapter III Section 2 is affected, or the intended purpose changes. Chapter III Section 2 is Articles 8 to 15: risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy and robustness and cybersecurity. A change that touches none of those and does not alter the intended purpose is not substantial however large it is in engineering terms.

That last point is the one that surprises engineers. Rewriting the serving stack, changing the inference hardware or refactoring the application is not a substantial modification if accuracy, robustness, logging, oversight and purpose are unaffected. Conversely, a two-line change to a decision threshold that shifts the false-negative rate is a change to the system’s accuracy characteristics and therefore engages the second limb. The test is about the regulated characteristics, not about the size of the diff.

What triggering it costs

Two provisions attach, and they are separate consequences that can both fire or only one.

Article 43(4) requires that a high-risk AI system which has already been subject to a conformity assessment undergo a new conformity assessment whenever it is substantially modified, regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer. That last clause closes the obvious gap: modifying a system you already deployed, for your own continued use, does not exempt you.

Article 25(1)(b) provides that a distributor, importer, deployer or other third party is considered a provider — with the full Article 16 obligation set — where it makes a substantial modification to a high-risk AI system already placed on the market or put into service, in such a way that it remains a high-risk system under Article 6. Article 25(2) then removes provider status from the original provider for that specific system, and obliges it to cooperate with the new provider and supply the information and reasonably expected technical access needed — unless it had clearly specified that its system is not to be changed into a high-risk AI system.

So a deployer that substantially modifies a system takes on conformity assessment, technical documentation, quality management, registration, post-market monitoring and incident reporting for it, and the original vendor steps out. That is a very large transfer of obligation to trigger by accident, and it is the reason the definition is worth reading carefully rather than delegating to a vendor questionnaire. Article 25(1)(c) is the parallel route without any modification at all: change the intended purpose of a system that was not high-risk, including a general-purpose AI system, so that it becomes high-risk, and you are the provider. See the integrator obligations page for that route.

The predetermined-change carve-out

Article 43(4) contains the provision that makes continuously learning systems workable. For high-risk AI systems that continue to learn after being placed on the market or put into service, changes to the system and to its performance 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 Annex IV point 2(f), do not constitute a substantial modification.

That is an invitation to specify your change envelope up front. If the conformity assessment documents that the model is retrained monthly on data of a described distribution, with performance monitored against stated thresholds and rollback on breach, then a monthly retrain within that envelope is not a substantial modification and does not require reassessment. If it does not, every retrain is arguably an unforeseen change affecting Article 15 accuracy characteristics.

The pattern is recognisable to anyone who has worked with the US medical device regime, where a predetermined change control plan performs the same job for adaptive device software. The instruments are unrelated and the wording is different, but the design lesson transfers exactly: the cost of a modification is set at assessment time, by how carefully you described what you intended to change later. Teams that write a narrow envelope to get through assessment quickly pay for it on every subsequent release.

Fine-tuning a GPAI model is a different question

Here is the part the definition does not reach, and the part most searches for “substantial modification” are actually about. Article 3(23) is about AI systems and about conformity assessment under Chapter III. General-purpose AI models are regulated under Chapter V, which has no conformity assessment, no notified body and no concept of substantial modification. Fine-tuning a general-purpose model is therefore not a “substantial modification” in the Article 3(23) sense, whatever the compute budget. The question is a different one: does fine-tuning make you a provider of a general-purpose AI model, with the Article 53 obligations that come with it.

The Regulation itself does not answer that in an article. Its recitals indicate that where a modification or fine-tuning is made to a model, the obligations of the downstream modifier should be limited to that modification or fine-tuning — for example by complementing the existing technical documentation with information on the changes, including new training data sources. That is a proportionality principle rather than a test, and it leaves the threshold question open.

The Commission’s guidelines on the scope of the obligations for providers of general-purpose AI models, published in July 2025 alongside the general-purpose model tranche taking effect, propose an indicative criterion based on the amount of compute used for the modification relative to the compute used to train the original model, with a threshold expressed as a fraction of it. They are published by the Commission.

The practical consequence for most teams is reassuring and worth stating plainly: an ordinary supervised fine-tune or a LoRA adapter on a frontier model uses a vanishingly small fraction of the original training compute, and on the Commission’s own indicative approach is nowhere near making the fine-tuner a provider of the model. A team that trains a substantial continued-pretraining run on an open-weights base is in genuinely uncertain territory and should take advice. And a team that fine-tunes past the systemic-risk compute threshold in Article 51 has a different and much larger problem.

Deciding in practice

The question “is this a substantial modification” is answerable in four steps, in order, and the first two dispose of most cases.

1. Is this an AI system already placed on the market or put into service, and is it high-risk? If it is a general-purpose model, Article 3(23) is not your provision — go to the Chapter V analysis above. If the system is not high-risk, there is no conformity assessment to redo, though Article 25(1)(c) may still make you a provider if the purpose change makes it high-risk.
2. Was the change foreseen in the initial conformity assessment? Check the technical documentation, specifically the Annex IV point 2(f) material on pre-determined changes. If it is inside the documented envelope, stop.
3. Does the change affect compliance with Articles 8 to 15? Work through them individually rather than as a category: does it change the risk profile, the data, the documentation, what is logged, what deployers are told, how oversight works, or the accuracy, robustness or security characteristics.
4. Does the intended purpose change? The intended purpose is what the provider stated in the instructions for use and the technical documentation. Selling the same system into a new context is the clearest way to change it, and it is a business decision made by people who will not think to ask this question.

Whoever answers those steps should write down the answer and why, every time, including the negative answers. A file that records “this change was considered against Article 3(23) on this date, for these reasons it was not substantial” is worth far more to a market surveillance authority than a correct but undocumented conclusion, and it is the same discipline the compliance evidence work asks for everywhere else in the Regulation.