Your team took a capable third-party model, fine-tuned it on your own data, wrapped it in some logic of your own, and shipped it to the business. Nobody signed a form that said "we are now an AI provider". But under the EU AI Act, you may have become one anyway, and the obligations that come with that are a different order of work from the ones you had the day before.
This is the trap in Article 25, and it catches exactly the organisations least expecting it: not AI vendors, but ordinary companies that customised someone else's model and assumed they were still just a user of it.
The two roles, in one line
The Act sorts everyone into two roles, and the gap between them is large. A deployer uses an AI system under its own authority; its duties are real but contained. A provider develops an AI system, or has it developed, and puts it on the market under its own name; its duties are the heavy ones - risk management, technical documentation, conformity assessment, registration.
Most organisations are deployers, and rightly assume they are. The trap is that you do not stay a deployer just because you started as one. Certain things you do to a system move you across the line, and they are things engineering teams do routinely, without anyone thinking of it as a legal event.
For the full breakdown of what each role owes, our earlier piece on EU AI Act Provider vs Deployer sets it out. This one is about the moment you cross from the first into the second.
What actually flips you into a provider
Under Article 25, a deployer takes on provider obligations in a few specific situations.
Three are worth knowing by heart, because they map onto ordinary product decisions.
The first is putting your own name on it. Take a high-risk system already on the market, badge it as your own, and you become its provider in the eyes of the Act, even though someone else built the underlying model.
The second is substantial modification. If you change a high-risk system substantially - enough to affect how it performs or whether it still meets the Act's requirements, you become the provider of the modified system.
The original provider's documentation does not cover what you changed, so the responsibility for the changed system shifts to you.
The third is changing the purpose. Take a system that was not high-risk and put it to a use that is, for instance repurposing a general capability into a hiring or credit-decision tool, and you have created a high-risk system that is, for regulatory purposes, yours.
Why "substantial modification" is the one that catches people
Own-name placement is usually a conscious decision. Repurposing is at least visible. Substantial modification is the trap, because the things that count as it are the everyday work of building with AI.
One clarification first, because it decides whether any of this applies. The substantial-modification trigger bites when the system you are changing is already high-risk. If you are modifying an ordinary, non-high-risk model, you are usually on the other path, the one where a change of purpose pushes a previously low-risk system into high-risk territory.
Either way you can end up a provider; the point is that the fine-tuning question only matters once high-risk is in the picture, by one route or the other.
Fine-tuning a model on your proprietary data can be a substantial modification. Restructuring how a system retrieves and uses information - the kind of change a team makes when it builds a retrieval pipeline around a model, can be one too. Custom-training on a domain-specific dataset can qualify.
None of these feels like "becoming a manufacturer of an AI system". All of them can be exactly that under the Act.
There is some direction to be had even without a bright line. The clearest trigger is a change of intended purpose - the modification most likely to count, because it goes to the heart of how the system was assessed in the first place.
At the other end sits the light touch: a small fine-tune that leaves the system doing the same job, at the same risk level, is less likely to cross the line. The changes that should make a team pause are those that alter what the system does, or who it affects.
And here is the sharp edge: the definition of substantial modification in the Act is not precise. There is no clean threshold that tells an engineering team "past this point you are a provider". The European Commission has been working on guidance that touches these value-chain questions, but until it is finalised the boundary is a matter of judgement, not a lookup.
Which means the safe assumption, when a team is meaningfully altering a high-risk model, is that provider obligations may now be in play, and to check before shipping, not after.
What crossing the line actually costs
The reason this matters is the size of the jump. A deployer's obligations, while real, are operational: use the system as instructed, keep humans in oversight, retain logs, notify people. A provider's obligations are a different category of work.
Becoming the provider of a high-risk system means owning its risk-management system, its technical documentation, its conformity assessment before it goes to market, and its registration, the full build-side compliance stack.
You inherit all of it for the modified system, and you inherit it whether or not you realised the modification put you there. The original vendor's compliance does not transfer to cover your version.
That is why Article 25 is worth understanding before a project starts, not after a contract or an audit surfaces it. The most expensive way to discover you are a provider is to be told by a regulator.
The practical takeaway
The point is not to avoid customising AI - customisation is how most of the value gets created. The point is to treat "are we substantially modifying a high-risk system" as a question the organisation asks deliberately, at the moment of the change, rather than a status it discovers later.
I will be straight about the limit. Without a bright-line test, no one can hand you a definitive yes or no for every case, and the honest answer for borderline modifications is that they need legal judgement, not a checklist.
What an organisation can do is build the trigger into how it works: when a team fine-tunes, rebuilds around, or repurposes a high-risk model, that is the cue to check the role - before the modified system ships under the company's name and quietly makes it a provider.
Frequently asked questions
Does fine-tuning an AI model make you a provider under the EU AI Act?
Montro's position is that it can. Under Article 25, substantially modifying a high-risk AI system makes you the provider of the modified system, and fine-tuning on proprietary data is one of the changes that can amount to a substantial modification.
It does not automatically do so in every case - the Act lacks a bright-line test, but a team meaningfully altering a high-risk model should assume provider obligations may apply and check before shipping.
What counts as a "substantial modification" under the EU AI Act?
The Act defines it, in Article 3(23), as a change that affects the AI system's compliance with the Act's requirements or its performance and risk profile.
In practice, actions like fine-tuning a model, restructuring how it retrieves and uses data, or custom-training it on a specific dataset can qualify. Because the definition is not precise and Commission guidance is still developing, borderline cases are a matter of legal judgement rather than a fixed threshold.
When does a deployer become a provider under Article 25?
In three main situations: when you place your own name or trademark on a high-risk system already on the market; when you substantially modify a high-risk system so that responsibility for the modified system shifts to you; and when you repurpose a system that was not high-risk into a high-risk use.
Any of these turns a deployer into a provider for that system, bringing the full provider obligation set with it.
What obligations do you inherit if you become a provider?
The heavy, build-side ones: a risk-management system, technical documentation, conformity assessment before the system goes to market, and registration. These are substantially more demanding than the deployer's operational duties, and the original vendor's compliance does not transfer to cover your modified system. This is why crossing the Article 25 line is consequential enough to check for deliberately, rather than discover in an audit.
