GPAI : les obligations des modèles d'IA à usage général

Depuis le 2 août 2025, les modèles d’IA à usage général — les GPAI, dont font partie GPT, Mistral, Gemini ou Claude — sont directement encadrés par l’AI Act. La plupart des entreprises françaises ne développent pas ces modèles ; elles les utilisent. La vraie question, pour un DSI ou un juriste conformité, n’est donc pas « suis-je fournisseur de GPAI ? » mais « à quel moment est-ce que j’en deviens un sans le savoir ? ». Voici le régime exact, et où se situe le piège.

Qu’est-ce qu’un modèle d’IA à usage général (GPAI) ?

Le règlement (UE) 2024/1689 (l’AI Act) définit un modèle d’IA à usage général comme un modèle entraîné sur de grandes quantités de données, présentant une généralité significative, capable d’exécuter un large éventail de tâches distinctes et intégrable dans des systèmes ou applications en aval. En clair : les grands modèles de langage et les modèles multimodaux qui servent de brique de base à des milliers d’applications.

Il faut distinguer deux notions que la pratique confond souvent. Le modèle (le GPAI, par exemple GPT-4) est le moteur. Le système d’IA est le produit fini construit autour de ce modèle (un chatbot de service client, un outil de génération de comptes rendus). L’AI Act encadre les deux, mais par des régimes différents : le modèle relève du chapitre V (articles 51 à 56), le système relève, lui, de la logique de classification des risques IA. Un même GPAI peut alimenter un système à haut risque comme un système sans risque particulier.

Ce chapitre V est une couche autonome, superposée au reste du règlement. Un GPAI n’est ni « interdit » au sens de l’article 5 sur les pratiques d’IA interdites, ni « à haut risque » par nature. Il obéit à ses propres obligations, centrées sur la transparence et la maîtrise des risques en amont de la chaîne.

Une architecture à deux étages

Le régime GPAI est bâti sur deux niveaux, et cette gradation est la clé de lecture de tout le chapitre V.

Le socle commun : tous les GPAI (Art. 53-54)

Tout fournisseur d’un modèle à usage général doit, au titre de l’article 53 :

• Établir et tenir à jour une documentation technique du modèle (procédé d’entraînement, tests, évaluations), à disposition de l’AI Office et des autorités nationales. On retrouve la même logique que pour la documentation technique de l’AI Act applicable aux systèmes à haut risque, mais adaptée au niveau du modèle.
• Fournir les informations nécessaires aux acteurs en aval — les intégrateurs qui construisent un système sur le modèle — pour qu’ils comprennent ses capacités et ses limites et respectent à leur tour leurs obligations.
• Mettre en place une politique de respect du droit d’auteur de l’Union, notamment en matière de fouille de textes et de données (opt-out des ayants droit).
• Publier un résumé suffisamment détaillé des contenus utilisés pour l’entraînement, selon un modèle de formulaire fourni par l’AI Office.

L’article 54 ajoute une obligation pour les fournisseurs établis hors de l’Union : désigner un mandataire (représentant autorisé) dans l’UE. La distinction entre celui qui conçoit le modèle et celui qui l’exploite est la même que celle, structurante, entre fournisseur et déployeur dans l’AI Act.

Deux allègements notables. Les fournisseurs de modèles publiés sous licence libre et open source sont partiellement exemptés (documentation technique et information aux déployeurs), à condition que les paramètres et l’architecture soient rendus publics — sauf s’il s’agit d’un modèle à risque systémique. Et les PME bénéficient de modalités simplifiées de mise en conformité.

L’étage renforcé : les GPAI à risque systémique (Art. 55)

Un modèle bascule dans la catégorie « à risque systémique » lorsqu’il présente des capacités à fort impact. L’AI Act pose une présomption chiffrée : un modèle dont l’entraînement a mobilisé une puissance de calcul cumulée supérieure à 10²⁵ opérations en virgule flottante (FLOP) est présumé présenter un risque systémique. La Commission peut aussi désigner un modèle sur la base d’autres critères.

Pour ces modèles — aujourd’hui une poignée de très grands modèles de frontière —, l’article 55 empile des obligations lourdes :

• Réaliser des évaluations du modèle, y compris des tests contradictoires (adversarial testing) pour identifier et atténuer les risques systémiques.
• Évaluer et atténuer les risques systémiques au niveau de l’Union.
• Documenter et notifier à l’AI Office les incidents graves et les mesures correctives.
• Assurer un niveau adéquat de cybersécurité du modèle et de son infrastructure physique.

Dans mon expérience de conseil, ce second étage ne concerne quasiment aucune entreprise française cliente : il vise les laboratoires qui entraînent les modèles de frontière. En revanche, le premier étage produit des effets en cascade sur toute la chaîne d’intégration.

Le point aveugle : quand un intégrateur devient fournisseur

C’est ici que se joue l’essentiel pour les lecteurs de ce site. La plupart des organisations ne sont pas fournisseurs de GPAI : elles consomment un modèle via une API. Mais l’AI Act prévoit un basculement.

Lorsqu’un acteur en aval modifie de façon substantielle un modèle à usage général, ou le réentraîne (fine-tuning) au point d’en modifier significativement les capacités, il peut être requalifié en fournisseur du modèle modifié — et hériter des obligations du chapitre V pour la partie qu’il a modifiée. Le considérant 109 et l’article 25 du règlement encadrent cette bascule de responsabilité.

Concrètement, une entreprise qui se contente d’appeler l’API d’un GPAI et d’écrire des prompts reste un simple déployeur du système qu’elle construit. Mais celle qui réalise un fine-tuning lourd sur ses propres données, modifie l’architecture ou redistribue le modèle sous son nom entre dans une zone à risque. La frontière n’est pas toujours nette, et c’est précisément le type d’analyse — qualification des rôles, cartographie des modèles utilisés, suivi des obligations associées — que des outils comme Legiscope permettent d’industrialiser plutôt que de traiter au cas par cas.

Le code de bonnes pratiques : un outil volontaire, pas un texte de loi

Pour aider les fournisseurs à démontrer leur conformité avant que les normes harmonisées ne soient prêtes, l’AI Office a publié le code de bonnes pratiques pour l’IA à usage général le 10 juillet 2025. Il s’organise en trois chapitres : transparence, droit d’auteur, et sûreté et sécurité (ce dernier réservé aux modèles à risque systémique).

Trois points de vigilance juridique. D’abord, ce code est volontaire : y adhérer n’est pas une obligation. Ensuite, il ne crée pas de droit nouveau — il offre une voie présumée de conformité aux articles 53 et 55. Un fournisseur signataire bénéficie de davantage de sécurité juridique et d’une charge administrative allégée ; un non-signataire doit démontrer sa conformité par d’autres moyens. Enfin, c’est une recommandation d’application, pas une norme contraignante : il ne faut pas le confondre avec le règlement lui-même. Cette distinction entre obligation légale et outil d’accompagnement est la même que celle que l’on retrouve dans les recommandations de la CNIL sur l’IA.

Calendrier et sanctions : ce qui se déclenche le 2 août 2026

Le régime GPAI est déjà en application, mais son bras armé arrive plus tard. Trois dates structurent la mise en œuvre :

• 2 août 2025 : entrée en application des obligations du chapitre V. Tout modèle mis sur le marché à partir de cette date doit s’y conformer.
• 2 août 2026 : entrée en vigueur des pouvoirs d’exécution et du régime de sanctions de l’AI Office (demandes d’informations, évaluations, mesures de restriction, retrait, amendes).
• 2 août 2027 : échéance de mise en conformité pour les modèles déjà sur le marché avant le 2 août 2025.

Sur le plan des sanctions, l’article 101 réserve aux fournisseurs de GPAI un régime spécifique : l’AI Office peut infliger des amendes pouvant atteindre 3 % du chiffre d’affaires annuel mondial ou 15 millions d’euros, le montant le plus élevé étant retenu. Ce plafond est distinct du régime général de l’article 99 et des amendes de l’AI Act applicable aux autres manquements. À noter : jusqu’au 2 août 2026, l’AI Office privilégie une approche de coopération de bonne foi plutôt que la sanction immédiate.

L’articulation avec le RGPD

Encadrer le modèle ne dispense pas de respecter le droit des données personnelles. Un GPAI est entraîné sur d’immenses corpus qui contiennent, presque toujours, des données personnelles — ce qui soulève des questions de base légale, de minimisation et d’information des personnes. Ces enjeux relèvent du RGPD et non de l’AI Act, et se posent avec acuité pour l’IA générative et les données personnelles. Les deux régimes se cumulent : la conformité AI Act d’un modèle ne présume en rien de sa conformité RGPD, et inversement.

Ce qu’il faut retenir

• Les modèles d’IA à usage général (GPAI) sont encadrés par le chapitre V de l’AI Act (Art. 51 à 56), en application depuis le 2 août 2025, indépendamment du régime des systèmes à haut risque.
• Le régime est à deux étages : un socle commun (Art. 53-54 : documentation, information des acteurs en aval, droit d’auteur, résumé des données d’entraînement) et un étage renforcé (Art. 55) pour les modèles à risque systémique présumés au-delà de 10²⁵ FLOP.
• Le vrai risque pour une entreprise française n’est pas d’être fournisseur, mais de le devenir en modifiant substantiellement ou en réentraînant un modèle (Art. 25) — et d’hériter alors des obligations du chapitre V.
• Le code de bonnes pratiques (publié le 10 juillet 2025) est un outil volontaire de présomption de conformité, pas une obligation légale.
• Les pouvoirs de sanction (jusqu’à 3 % du CA mondial ou 15 M€, Art. 101) entrent en vigueur le 2 août 2026.

FAQ

Mon entreprise utilise ChatGPT ou Mistral via API : suis-je concernée par les obligations GPAI ?

En principe non, si vous vous limitez à consommer le modèle via une API et à l’intégrer dans votre propre système. Les obligations du chapitre V pèsent sur le fournisseur du modèle. Vous restez, vous, déployeur du système que vous construisez, avec les obligations correspondantes. La situation change si vous réentraînez ou modifiez substantiellement le modèle.

Quelle est la différence entre un modèle GPAI et un système d’IA ?

Le modèle est le moteur (par exemple un grand modèle de langage) ; le système d’IA est le produit fini construit autour de lui (un chatbot, un outil d’analyse). Le modèle relève du chapitre V de l’AI Act ; le système relève de la classification par niveau de risque. Un même modèle peut alimenter des systèmes de niveaux de risque très différents.

Qu’est-ce qu’un GPAI « à risque systémique » ?

C’est un modèle présentant des capacités à fort impact. L’AI Act pose une présomption : un modèle entraîné avec une puissance de calcul supérieure à 10²⁵ opérations en virgule flottante (FLOP) est présumé à risque systémique. Ces modèles (Art. 55) supportent des obligations renforcées d’évaluation, d’atténuation des risques et de notification d’incidents.

Le code de bonnes pratiques GPAI est-il obligatoire ?

Non. Il s’agit d’un outil volontaire publié par l’AI Office en juillet 2025. Le signer offre une présomption de conformité aux articles 53 et 55 et allège la charge administrative, mais un fournisseur peut démontrer sa conformité par d’autres moyens. Il ne remplace pas le texte du règlement.