More and more companies are making the leap from using AI to tuning it: they take an open model —Llama, Mistral or another— and fine-tune it with their own data so it speaks their language, knows their catalogue or follows their tone. It's a reasonable technical move, and an increasingly accessible one. What almost nobody tells them is that this move has a regulatory reading: under the AI Act, the distance between using a model and modifying it can be the distance between being a deployer and being a provider. And the obligations of one and the other don't look anything alike.
The ladder: using, modifying, rebranding
The AI Act allocates obligations according to the role you play in the chain. Simplifying, there are three rungs:
Using. You license or download a model and use it as it is, even with your own prompts and integrations. You're a deployer. For general-purpose AI models (GPAI), your direct obligations as such are minimal: you receive the information the provider must give you, and you use the system with the general diligence that applies.
Modifying. You retrain or fine-tune the model with your data. This is where this article's question opens up: at what point is the modification substantial enough that you become answerable as the provider of what you've created?
Rebranding. You place a high-risk system that is already on the market under your own name or trademark, you substantially modify a high-risk system so that it remains high-risk, or you change the intended purpose of a system that wasn't high-risk so that it becomes so. In these three scenarios — and only these — Article 25(1) is clear: you take on the role of provider, with everything that implies. Putting your brand on a minimal-risk system does not, by itself, make you a provider.
The threshold the Commission set
For the GPAI case, the European Commission's guidelines on the obligations of general-purpose AI model providers gave that line a quantitative criterion that the text of the Regulation didn't spell out: a modifier becomes a provider when the compute used in the modification exceeds one third of the training compute of the original model.
Two nuances make the criterion workable in practice:
- If you don't know the original's compute —the usual case with open models—, the guidelines offer fallback reference values by model type, so the assessment doesn't depend on a figure the original provider may never have published.
- The obligations are limited to your modification. If you cross the threshold, you don't inherit responsibility for the whole original model: you answer as the provider of the part you created. It's a proportionate split, and it's worth citing it that way.
For the vast majority of business fine-tunings —light adjustments with thousands or tens of thousands of examples—, the compute of the modification sits at an enormous distance from that third. The honest practical reading is reassuring: fine-tuning a model for your business does not, as a general rule, turn you into a GPAI provider. But it's a conclusion you need to be able to support, not one you can assume.
The two duties that are never waived
If you work on open models, it's worth knowing another piece of the guidelines: the exemptions for open-source models (which lighten certain documentation obligations) only apply to models under a genuinely free licence with public parameters, never to models of systemic risk, and there are two provider obligations that are never waived, under any circumstance: the copyright compliance policy and the public summary of the training data. If your modification did turn you into a provider, "it's open source" wouldn't get you out of those two.
And there's a complementary warning that comes from Spanish practical guidance material: fine-tuning and continuous learning by the deployer are expressly flagged as situations that can also trigger the change of role on the high-risk side — where the trigger isn't a compute threshold but a substantial modification or a change of purpose. The GPAI line and the high-risk line are two different tests; both are worth passing.
What to document if you're fine-tuning models
The operational takeaway fits into three lines of a file:
- Record the modification: which base model, which data, which technique, and a reasonable estimate of the compute used against the threshold. You don't need laboratory precision; you need documented judgement.
- Record the purpose: what it's being fine-tuned for, and what it isn't. This is what supports the case that there's no change of purpose towards high risk.
- Anchor the conclusion: "one-third compute criterion assessed; well below the threshold; deployer role unchanged; review if the technique or the scale changes". A sentence like that, dated and signed, is the difference between a defensible position and an assumption.
It's the same principle that runs through the whole Regulation, as we already noted when talking about the role of whoever coordinates AI governance at an SME: the AI Act's questions almost never demand heroic answers — they demand documented ones. And to answer them, you first need to know which models and systems the house actually has: the inventory, once again, is the foundation.
This article is for informational purposes only and does not constitute legal advice.