Model Lifecycle and ‘Placed on the Market’: When Fine-Tuning Makes You a Provider

Fine-tune a general-purpose AI model enough, and the AI Act stops treating you as a customer and starts treating you as a provider — with a full provider’s obligations attached. Most organisations doing serious in-house fine-tuning have never checked which side of that line they’ve landed on.

The AI Act’s provider obligations were written with model developers in mind — technical documentation, risk management for systemic-risk models, incident reporting, the machinery most organisations assume is someone else’s problem because they’re “just” using a model, not building one. Article 25 removes that assumption for anyone who modifies a general-purpose AI model enough to trigger a “significant change” in its generality, capabilities, or systemic risk. At that point, the modifier inherits provider obligations for the modification, whether or not they set out to become a provider of anything.

Where the actual line sits

The European Commission’s guidance offers an indicative criterion rather than a bright line: if the training compute used for a modification exceeds roughly one-third of the compute used to train the original model, that’s treated as a strong signal a new model has effectively been created — with the downstream party now carrying provider obligations for it. Below that threshold, responsibility defaults to remaining with the original provider, even for a modification that provider never touched, which creates its own quiet problem: if nobody updates the model documentation for a below-threshold fine-tune that nonetheless changes the model’s biases and behaviour, the AI Act’s transparency intent is being defeated by a modification too small to trigger the rule and too consequential to go undocumented.

The guidance is deliberately silent on whether repeated fine-tuning over time — several modifications that individually stay under the one-third threshold but cumulatively exceed it — should be aggregated. Given the emphasis elsewhere in the Act on provider responsibility across a model’s full lifecycle, the cautious reading is to assume cumulative modifications count, and to track total compute spent on fine-tuning a given model over its lifetime, not just per individual run. Organisations doing this ought to be prepared to defend either reading rather than assume the generous one applies by default.

What crossing the line actually obligates you to do

Where a modification does trigger provider status, the resulting obligations are limited to the modification itself — not the full weight of documenting the original model from scratch, but genuinely supplementing the original provider’s documentation with the specifics of what changed: new data sources, new training methods, and an honest account of how capabilities or risk profile shifted as a result. For a financial institution that fine-tunes a general-purpose model into a high-risk hiring or credit-decisioning tool, this is not a hypothetical edge case — it’s a financial institution voluntarily and often unknowingly stepping into full provider obligations for a high-risk AI system, the moment the fine-tuning crosses the threshold, regardless of the institution’s intent to remain a mere deployer.

The practical fix is unglamorous: track cumulative training compute against the original model’s training compute for every fine-tuning programme, treat the one-third figure as a planning threshold rather than a legal certainty, and document the modification’s rationale and data sources as the work happens rather than reconstructing it retrospectively if the threshold question is ever raised.

None of this requires a data science team to become AI Act specialists. It requires one governance step added to an existing model-development process: log training compute against the threshold, every run, from the start of the programme rather than the moment someone asks. That single habit is the difference between a documented, defensible position and a discovery made under regulatory pressure.

This matters most for exactly the sectors this site writes about most: any regulated entity doing meaningful in-house fine-tuning of a foundation model — for underwriting, for compliance drafting, for customer-facing decisioning — needs to know in advance which side of the significant-change threshold its work sits on, because discovering the answer after a regulator asks is a materially worse position than having tracked training compute against the threshold from the start.

A fintech’s data science team fine-tuned an open-weight foundation model over several iterations to power a credit pre-screening tool, each individual fine-tuning run comfortably under the one-third compute threshold in isolation. Nobody had tracked the cumulative compute across all the iterations combined, because each run was scoped and approved separately, by different people, months apart. Added together, the cumulative training compute exceeded the threshold — meaning the firm had, without anyone deciding to, likely taken on provider obligations for a high-risk credit-decisioning system, and had no documentation trail reflecting that status at any point in the process.

Once provider status is established, the actual engineering obligations are covered in the AI Act’s obligations translated into engineering deliverables.

Determining whether an in-house fine-tuning programme has crossed into provider obligations under Article 25 — and what documentation that triggers — is exactly the kind of AI governance scoping a technology control assessment is built to establish before a regulator, rather than after.