Fine-tuning and chatbots on an LLM: when your company becomes a "provider" under the AI Act

"We fine-tuned a model on our support tickets: are we now an AI provider like OpenAI?" It is one of the questions we hear most often. The short answer: you are almost certainly not the provider of the model, but you are almost certainly the provider of a system. These are two different things with different obligations, and confusing them leads to mistakes in both directions: worrying about obligations you don't have, or ignoring the ones you really do.

Three levels not to confuse

Regulation (EU) 2024/1689 (the AI Act) distinguishes:

The same company can sit on several levels at once. Let's take them one by one.

Level 1: fine-tuning and the one-third threshold

The Commission guidelines on the obligations of GPAI model providers (18 July 2025) clarify that whoever modifies or fine-tunes a third-party model — the "downstream modifier" — does not automatically take on the provider's obligations. It becomes a provider only if the modification is significant, and the Commission presumes this when the compute used for the modification exceeds one third of the compute used to train the original model.

If the original compute is unknown, substitute thresholds apply: one third of 10^23 FLOP (the indicative threshold for a model to be considered GPAI) or, for models with systemic risk, one third of 10^25 FLOP.

Two practical consequences:

• A typical corporate fine-tuning — a few thousand examples drawn from tickets, contracts or product sheets — generally uses a tiny fraction of a large model's training compute, and stays below the threshold.
• Even above the threshold, for a model without systemic risk the Article 53(1) obligations are limited to the modification: documenting the changes and the new training data, adopting a copyright policy, publishing the summary of the content used.

RAG and prompt engineering do not change the weights and involve no training: they do not count towards the calculation.

What to do anyway: record how much compute you used and on which base model. If someone ever asks why you don't consider yourself the model's provider, that number is the answer.

Level 2: whoever builds the application is the system provider

This is where the most common mistake lies. Under the AI Act, a provider is whoever develops an AI system and places it on the market or puts it into service under its own name — and putting into service includes own use. An internal assistant built on an LLM via API, a chatbot on your website, an email classifier: if you developed it (or had it developed for you), you are the provider of that system and, since it integrates someone else's model, a downstream provider (Article 3(68)).

There is no single package of obligations: they depend on the system's risk.

The most common obligations

• Transparency (Article 50(1)): if the system interacts with people, they must know they are dealing with an AI. This applies to systems placed on the market from 2 August 2026.
• Synthetic content (Article 50(2)): if it generates text, images or audio, outputs must be marked in a machine-readable format; for systems already on the market before 2 August 2026 the deadline is 2 December 2026.
• High risk: if the system falls under Annex III, the Article 16 obligations apply from 2 December 2027, following the postponement introduced by Regulation (EU) 2026/1744.

The system level is also where the GDPR lives: data flowing through prompts, retrieved documents or the fine-tuning dataset remains personal data, with all the legal bases and assessments that entails.

Level 3: changing the purpose can make you a high-risk provider

Article 25(1)(c) provides that whoever modifies the intended purpose of an AI system — including a general-purpose AI system — that has not been classified as high-risk, in such a way that it becomes high-risk, is considered the provider of a high-risk system. The original provider is then no longer considered the provider of that specific system (Article 25(2)).

A concrete example: using a general-purpose assistant to screen job candidates or assess customers' creditworthiness. No fine-tuning is needed: the new use is enough. The other two cases in Article 25(1) cover whoever puts their name or trademark on a high-risk system already on the market and whoever makes a substantial modification to it.

What you can demand from the model provider

If you integrate a GPAI model, you are entitled to a documentation baseline. Article 53(1)(b) requires the model provider to make available to those who integrate it the information in Annex XII: capabilities, limitations and what you need to meet your own obligations.

GPAI provider obligations have applied since 2 August 2025 (for models already on the market before that date, by 2 August 2027), and since 2 August 2026 the Commission can enforce them, including with fines of up to 3% of worldwide turnover or EUR 15 million (Article 101). In practice: you now have more leverage than before to ask for that documentation — and you should file it.

A five-step checklist

1. Inventory every application that uses a GPAI model, internal or external, and who developed it.
2. For each fine-tuning, record the base model, the dataset and the compute used, and compare it with the one-third threshold.
3. Qualify the system: does it interact with people? Does it generate content? Does it fall under Annex III?
4. Check the actual purpose of use, not the declared one: that is where Article 25(1)(c) kicks in.
5. Collect and file the model provider's Annex XII documentation, together with your own analysis.

Where to start

Role classification is the first step of any compliance programme: get it wrong and everything else rests on a false premise. An independent gap assessment maps your applications onto the three levels, checks the thresholds and tells you precisely which obligations you really have — and which you don't.