GPAI fine-tuning: when do you become a provider under Article 25?

1. Why this question changes everything

In our previous article, we established that your GPT/Claude wrapper is NOT a GPAI. The GPAI is the underlying model (GPT-4, Claude, Gemini) — and Art. 53 obligations (technical documentation, copyright policy, downstream transparency) are borne by OpenAI, Anthropic or Google, not you. You are a deployer of the model.

Except. The moment you start MODIFYING that model — fine-tuning, continual pretraining, training-time integration of proprietary data —, you enter a different regulatory terrain. At some point, the modification becomes substantial enough that you become a provider of the modified GPAI in the eyes of the AI Act. And that point has massive consequences:

• →Art. 53 obligations: technical documentation of the modified model, training data summary, copyright policy, downstream user information, EU database registration.
• →Art. 55 obligations if systemic risk: if your modified model crosses the systemic compute threshold (≥ 10²⁵ FLOPs on cumulative training), you also owe adversarial testing, incident reporting, cybersecurity measures, energy consumption reporting.
• →Liability: you become the accountable party for the model's behavior toward downstream deployers who use it through your API. The original provider (OpenAI, Anthropic) is no longer on the front line.

In other words: if you thought you were at €20K in compliance costs as a deployer, and you did a fine-tuning that propels you into GPAI provider territory, you are potentially looking at €200K–500K — plus ongoing obligations. The question “am I a provider of the modified model?” deserves a real answer, not a shrug.

2. What Article 25 actually says

Article 25 is titled “Responsibilities along the AI value chain.” Its paragraph 1 lists the three situations in which a distributor, importer, deployer, or other third party becomes a “provider” within the meaning of the AI Act, inheriting the full set of provider obligations:

Note: the formulations above are faithful reformulations based on the official consolidated version of Regulation 2024/1689 published in the Official Journal. For the exact full text, see the EUR-Lex source at the bottom of the article.

3. What counts as a “substantial modification”?

Article 3(23) of the regulation defines the term. A substantial modification is a change made to an AI system after it has been placed on the market or put into service that meets TWO cumulative conditions:

1. 1.Was not foreseen or planned in the initial conformity assessment. In other words: the original provider did not anticipate that type of change in its technical documentation and conformity tests.
2. 2.Affects the system's compliance OR modifies its intended purpose. Cosmetic or purely ergonomic changes don't count. The change must affect either how the system meets regulatory requirements, or what the system is supposed to do.

Both conditions must apply together. A change that was foreseen by the original provider — say, a light fine-tuning performed through OpenAI's official fine-tuning API — is probably out of scope, even if it affects behavior, because it falls within what the provider “planned for.” Conversely, heavy continual pretraining done on an open-source model (Llama for example) is potentially substantial: it was not foreseen by Meta and it affects both capabilities and potentially compliance (bias, safety, robustness — all the things Art. 15 requires).

4. The spectrum of modifications, from lightest to heaviest

Here's how to read the spectrum of possible GPAI modifications in practice. Each line is a reasonable reading of the text — not a legal verdict.

5. Quantitative thresholds — what we know and don't know

Tech press and some legal blogs circulate precise numbers like “if fine-tuning represents more than one-third of the original training FLOPs, you are a provider of the modified model.” Let's be clear: these thresholds are NOT in the text of Regulation 2024/1689.

The only explicit quantitative threshold in the regulation concerns GPAI systemic risk classification: Recital 110 and Art. 51 set 10²⁵ FLOPs of cumulative training as the presumed systemic risk threshold. For substantial modification itself, no number is given. The text remains qualitative: “change not foreseen and affects compliance or intended purpose.”

More precise guidelines will come from the European AI Office. At the time of this article, those guidelines have not been published. They are expected progressively between 2026 and 2027. Some voluntary GPAI Codes of Practice, being drafted by industry working groups coordinated by the AI Office, will likely address substantial modification — but those codes are not hard law.

6. Checklist: am I a provider of a modified GPAI?

If you answer yes to one or more of the following, you must seriously consider the possibility of being a provider under Art. 25(1)(b) or (c):

1. 1. Did you perform training (fine-tuning or continual pretraining) on the model weights, not just on prompts or inference context?
2. 2. Has the modified model gained a capability the original did not demonstrate? (new domain, new language, new behavior, new performance level)
3. 3. Has your modification potentially affected the safety, robustness, cybersecurity, or bias handling of the model in a way not documented by the original provider?
4. 4. Are you using the modified model in a use case matching Annex III (employment, credit, education, public services, biometrics, justice, migration), making the AI system high-risk?
5. 5. Are you making the modified model available to third parties (large-scale internal distribution, public API, client-facing product)?

Three or more “yes” answers = seek specialized AI Act legal advice before deployment. A single “yes” to question 3 or 4 alone can be enough to tip your case.

7. What to do in practice

1. 1. Document your baseline. What model are you using? What version? What technical documentation did the original provider make available (model card, system card, usage policy)? Keep a dated copy.
2. 2. Document your modification. For each fine-tune or training run: type (LoRA, full fine-tune, continual pretraining), data volume, duration, compute used, business objective, before/after testing.
3. 3. Document the effect. How has behavior changed? What tests did you run to verify your modification does not introduce bias or safety regression? If you did not test, that's a red flag.
4. 4. Take a position. Based on your documentation, write down your position: in your view, are you a provider of the modified model under Art. 25(1)(b)? Yes, no, or uncertain? This is precisely what a Sprinkling Act report produces — a dated position artefact, grounded in the text, that you can then hand to a lawyer for validation.
5. 5. If uncertain: legal counsel. Borderline cases deserve specialized legal advice. Our report is not legal advice — it's the structured pre-qualification that lets your lawyer work faster and cheaper.