Fine-tuning GPAI : quand devenez-vous provider sous l'Article 25 ?

1. Pourquoi cette question change tout

Dans notre article précédent, on a établi que votre wrapper GPT/Claude n'est PAS un GPAI. Le GPAI, c'est le modèle sous-jacent (GPT-4, Claude, Gemini) — et les obligations Art. 53 (documentation technique, politique copyright, transparence downstream) sont portées par OpenAI, Anthropic ou Google, pas par vous. Vous êtes deployer du modèle.

Sauf que. Le moment où vous commencez à MODIFIER ce modèle — fine-tuning, continual pretraining, intégration de données propres pendant l'entraînement —, vous entrez dans un terrain réglementaire différent. À un certain point, la modification devient suffisamment substantielle pour que vous deveniez provider du GPAI modifié aux yeux de l'AI Act. Et ce moment a des conséquences massives :

• →Obligations Art. 53 : documentation technique du modèle modifié, résumé des données d'entraînement, politique de droit d'auteur, information aux utilisateurs downstream, enregistrement dans la base de l'UE.
• →Obligations Art. 55 si risque systémique : si votre modèle modifié dépasse le seuil de calcul systémique (≥ 10²⁵ FLOPs sur l'entraînement cumulé), s'ajoutent les obligations d'adversarial testing, signalement d'incidents, mesures de cybersécurité, reporting énergétique.
• →Responsabilité : vous devenez l'acteur responsable du comportement du modèle pour les déployeurs en aval qui l'utilisent via votre API. Le provider originel (OpenAI, Anthropic) n'est plus en première ligne.

Autrement dit : si vous pensiez être à 20 000 € de conformité en tant que deployer, et que vous avez fait un fine-tuning qui vous propulse en provider de GPAI, vous êtes potentiellement à 200 000–500 000 € — plus les obligations continues. La question « suis-je provider du modèle modifié ? » mérite donc une vraie réponse, pas un haussement d'épaules.

2. Ce que dit l'Article 25

L'Article 25 s'intitule « Responsabilités le long de la chaîne de valeur de l'IA » (Responsibilities along the AI value chain). Son paragraphe 1 liste les trois situations dans lesquelles un distributeur, importateur, déployeur ou autre tiers devient un « provider » au sens de l'AI Act et prend l'ensemble des obligations provider :

Note : les formulations ci-dessus sont des reformulations fidèles basées sur la version officielle consolidée du Règlement 2024/1689 publiée au Journal Officiel. Pour le texte exact intégral, consultez la source EUR-Lex en bas d'article.

3. Qu'est-ce qu'une « modification substantielle » ?

L'Article 3(23) du règlement définit le terme. Une modification substantielle est un changement apporté à un système IA après sa mise sur le marché ou sa mise en service qui remplit DEUX conditions cumulatives :

1. 1.N'était pas prévu dans l'évaluation de conformité initiale. Autrement dit : le provider originel n'avait pas anticipé ce type de changement dans sa documentation technique et ses tests de conformité.
2. 2.Affecte la conformité du système OU modifie sa finalité. Les changements cosmétiques ou purement d'ergonomie ne comptent pas. Il faut que le changement touche soit à la manière dont le système respecte les exigences réglementaires, soit à ce que le système est censé faire.

Ces deux conditions se cumulent. Un changement prévu par le provider originel — par exemple, un fine-tuning léger fait via une API fine-tuning officielle d'OpenAI — est probablement hors périmètre, même s'il affecte le comportement, parce qu'il rentre dans ce qui était « prévu » par le provider. À l'inverse, un continual pretraining massif fait sur un modèle open-source (Llama par exemple) est potentiellement substantiel : il n'était pas prévu par Meta et il affecte à la fois les capacités et potentiellement la conformité (biais, sécurité, robustesse — tout ce que l'Art. 15 demande).

4. Le spectre des modifications, du plus léger au plus lourd

Voici comment lire concrètement le spectre des modifications possibles d'un GPAI. Chaque ligne est une lecture raisonnable du texte — pas un verdict juridique.

5. Les seuils quantitatifs — ce qu'on sait et ce qu'on ne sait pas

Il circule dans la presse tech et certains blogs juridiques des chiffres précis du type « si le fine-tuning représente plus d'un tiers des FLOPs d'entraînement du modèle original, vous êtes provider du modèle modifié ». Soyons clairs : ces seuils ne sont PAS dans le texte du Règlement 2024/1689.

Le seul seuil quantitatif explicite dans le règlement concerne la classification GPAI à risque systémique : Recital 110 et Art. 51 fixent 10²⁵ FLOPs d'entraînement cumulé comme seuil présumé de risque systémique. Pour la modification substantielle elle-même, aucun chiffre n'est donné. Le texte reste qualitatif : « change not foreseen and affects compliance or intended purpose ».

Des guidelines plus précises relèveront du Bureau de l'IA européen (European AI Office). À la date de rédaction de cet article, ces guidelines n'ont pas été publiées. Elles sont attendues progressivement entre 2026 et 2027. Certains Code of Practice GPAI volontaires, en cours d'élaboration par des groupes d'industrie coordonnés par l'AI Office, aborderont probablement la question des modifications substantielles — mais ces codes ne sont pas du hard law.

6. Checklist : suis-je provider d'un GPAI modifié ?

Si vous répondez oui à une ou plusieurs des questions suivantes, vous devez traiter sérieusement la possibilité d'être provider au sens de l'Art. 25(1)(b) ou (c) :

1. 1. Avez-vous effectué un entraînement (fine-tuning ou continual pretraining) sur les poids du modèle, pas juste sur le prompt ou le contexte d'inférence ?
2. 2. Le modèle modifié a-t-il acquis une capacité que le modèle original ne démontrait pas ? (nouveau domaine, nouvelle langue, nouveau comportement, nouveau niveau de performance)
3. 3. Votre modification a-t-elle potentiellement affecté la sécurité, la robustesse, la cybersécurité ou la gestion des biais du modèle de manière non documentée par le provider originel ?
4. 4. Utilisez-vous le modèle modifié dans un cas d'usage qui correspond à l'Annexe III (emploi, crédit, éducation, services publics, biométrie, justice, migration), rendant le système IA à haut risque ?
5. 5. Mettez-vous le modèle modifié à disposition de tiers (distribution interne à grande échelle, API publique, client-facing product) ?

Trois « oui » ou plus = prenez conseil juridique spécialisé AI Act avant de déployer. Un « oui » à la question 3 ou 4 seule peut suffire à faire basculer votre cas.

7. Que faire concrètement

1. 1. Documentez votre baseline. Quel modèle utilisez-vous ? Quelle version ? Quelle documentation technique le provider originel a-t-il rendue disponible (model card, system card, usage policy) ? Conservez une copie datée.
2. 2. Documentez votre modification. Pour chaque fine-tuning ou entraînement : type (LoRA, full fine-tune, continual pretraining), volume de données, durée, compute utilisé, objectif métier, tests effectués avant/après.
3. 3. Documentez l'effet. En quoi le comportement a-t-il changé ? Quels tests avez-vous faits pour vérifier que votre modification n'introduit pas de biais ou de régression de sécurité ? Si vous n'avez pas testé, c'est un red flag.
4. 4. Prenez position. Sur la base de votre documentation, formulez par écrit votre position : êtes-vous, à votre avis, provider du modèle modifié au sens de l'Art. 25(1)(b) ? Oui, non, ou incertain ? C'est précisément ce que le rapport Sprinkling Act produit — un artefact de position daté, basé sur le texte, que vous pouvez ensuite remettre à un avocat pour validation.
5. 5. Si incertain : conseil juridique. Les cas borderline méritent un avis d'avocat spécialisé. Notre rapport n'est pas un avis juridique — c'est la pré-qualification structurée qui permet à votre avocat de travailler plus vite et moins cher.