Obligations GPAI au titre du règlement sur l’IA expliquées

Si votre entreprise utilise ChatGPT, Claude, Gemini, Llama, Mistral, Stable Diffusion ou tout autre modèle de fondation, que ce soit par une API, une variante affinée, ou comme composant dans votre propre produit, les obligations relatives aux modèles d’IA à usage général (GPAI) du règlement sur l’IA s’appliquent à votre chaîne d’approvisionnement. Ces obligations sont devenues exécutoires le 2 août 2025, ce qui en fait l’une des exigences les plus précoces du règlement. Contrairement aux règles des systèmes à haut risque, qui visent des cas d’usage précis (et, depuis le Digital Omnibus, s’appliquent à compter du 2 décembre 2027 pour l’annexe III), les obligations GPAI s’attachent au modèle lui-même, indépendamment de la manière dont il est finalement déployé, et suivent le modèle de l’entraîneur d’origine jusqu’au déployeur final.

Ce guide couvre qui a la qualité de fournisseur GPAI, ce que ces fournisseurs doivent faire, quand les règles de risque systémique se déclenchent, comment le code de bonnes pratiques façonne la conformité, et ce que les entreprises en aval doivent comprendre.

L’essentiel : les obligations GPAI en un coup d’œil

• Un modèle d’IA à usage général est tout modèle d’IA capable d’exécuter un large éventail de tâches, y compris les modèles entraînés avec de grandes quantités de données par auto-supervision à grande échelle. GPT-4, Claude, Gemini, Llama, Mistral et Stable Diffusion y entrent tous.
• Les obligations GPAI sont devenues exécutoires le 2 août 2025, plus tôt que la plupart des autres exigences du règlement sur l’IA.
• Tous les fournisseurs GPAI doivent respecter l’article 53 : documentation technique, respect du droit d’auteur, et devoirs de transparence / d’information en aval.
• Les modèles entraînés avec un volume de calcul dépassant 10²⁵ opérations en virgule flottante (FLOP) sont présumés présenter un risque systémique et font face à des obligations supplémentaires au titre de l’article 55 : tests contradictoires, mesures de cybersécurité, signalement d’incidents et évaluations du modèle.
• Le code de bonnes pratiques GPAI, publié le 10 juillet 2025 et entériné le 1er août 2025, fournit le principal référentiel de conformité.
• Les modèles GPAI sous licence libre et ouverte reçoivent une exemption limitée de certains devoirs de documentation et de transparence, mais pas des obligations de droit d’auteur ni des règles de risque systémique.
• Lorsqu’un modèle GPAI est intégré dans un système d’IA à haut risque, le fournisseur à haut risque doit assurer la conformité complète aux deux jeux d’exigences. Les obligations autonomes à haut risque s’appliquent à compter du 2 décembre 2027 (règlement (UE) 2026/1744).
• Les sanctions pour manquement GPAI atteignent 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, appliquées directement par le bureau de l’IA de la Commission européenne.
• Classez vos systèmes d’IA maintenant pour comprendre quelles obligations s’appliquent.

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

Le règlement sur l’IA définit un modèle d’IA à usage général à l’article 3 comme un modèle d’IA, y compris lorsqu’il est entraîné avec une grande quantité de données par auto-supervision à grande échelle, qui présente une généralité significative, est capable d’exécuter de manière compétente un large éventail de tâches distinctes, et peut être intégré dans une variété de systèmes ou d’applications en aval.

Caractéristiques clés

Trois traits distinguent un modèle GPAI d’un système d’IA étroit, à une seule destination :

1. Généralité significative : le modèle n’est pas conçu pour une tâche unique. Il peut traiter traduction, résumé, génération de code, classification, raisonnement, et davantage, sans être réentraîné pour chaque tâche.

2. Entraînement auto-supervisé à grande échelle : la plupart des modèles concernés sont entraînés sur de grands jeux de données diversifiés, par des méthodes d’apprentissage non supervisé ou auto-supervisé. C’est la marque du paradigme du modèle de fondation.

3. Intégrabilité : le modèle peut être embarqué dans de nombreuses applications, produits et systèmes en aval. Un modèle qui ne fonctionne qu’à l’intérieur d’une application propriétaire peut quand même y entrer, mais l’intégrabilité est un indice fort.

Quels modèles y entrent ?

La définition capture les grands modèles qui dominent le paysage actuel :

La définition couvre aussi spécifiquement les modèles d’IA générative : même si un modèle est commercialisé uniquement comme « outil de création de contenu », il entre dans le régime GPAI s’il satisfait les critères de généralité et d’échelle. La définition s’applique quelle que soit la manière dont le modèle est mis sur le marché : API, plateforme, poids téléchargeables, ou embarqué dans un produit.

Qui a la qualité de fournisseur GPAI ?

Au titre du règlement sur l’IA, le fournisseur de modèle GPAI est la personne physique ou morale qui développe un modèle d’IA à usage général, ou le fait développer, et le met sur le marché. La « mise sur le marché » inclut le fait de rendre le modèle disponible, à titre onéreux ou gratuit, à des entreprises en aval, à des développeurs ou au public.

Fournisseur, fournisseur en aval, déployeur

La chaîne GPAI implique souvent plusieurs couches :

1. Fournisseur GPAI en amont : l’entreprise qui entraîne le modèle de base et le rend disponible (par exemple OpenAI, Anthropic, Meta, Google). Cette entité porte les obligations centrales de l’article 53 et, le cas échéant, les obligations de risque systémique de l’article 55.

2. Fournisseur en aval : une entreprise qui prend un modèle GPAI, l’affine, le modifie ou l’intègre dans son propre système d’IA, puis met ce modèle ou ce système modifié sur le marché sous son propre nom. Cette entité peut devenir fournisseur GPAI à son tour, surtout si la modification est substantielle. Pour le détail des changements de rôle, voir obligations du fournisseur et du déployeur.

3. Déployeur : une entreprise qui utilise un système fondé sur un GPAI sous sa propre autorité, sans le mettre sur le marché. Les déployeurs ne sont pas des fournisseurs GPAI, mais ils ont des obligations distinctes, surtout si le système qualifie comme à haut risque.

La question critique : quand une entreprise en aval devient-elle fournisseur ?

Une entreprise devient fournisseur GPAI lorsqu’elle :

• Met sur le marché, sous son propre nom ou sa propre marque, une version substantiellement modifiée du modèle
• Affine un modèle et rend la variante affinée disponible comme produit ou service distinct
• Intègre un modèle GPAI dans un système et met ce système sur le marché comme nouveau système d’IA

Une entreprise ne devient pas fournisseur GPAI du seul fait de :

• Utiliser un modèle GPAI via une API pour ses propres opérations internes
• Déployer un modèle GPAI dans son organisation sans le rendre disponible à des tiers
• Ajouter des invites de couche applicative, des enveloppes d’interface ou une automatisation de processus autour d’un modèle existant, sans modifier le modèle lui-même

Considérations pour les modèles sous licence libre

Le règlement sur l’IA prévoit une exemption limitée pour les modèles GPAI publiés sous une licence libre et ouverte. Au titre de cette exemption, les fournisseurs GPAI en licence libre sont relevés de certaines obligations de documentation et de partage d’information, mais seulement si les conditions suivantes sont réunies :

• Les paramètres du modèle (poids, informations d’architecture, informations d’usage) sont rendus publiquement disponibles
• Le modèle n’est pas classé comme présentant un risque systémique

Si un modèle est sous licence libre mais dépasse le seuil de calcul de 10²⁵ FLOP, ou est désigné par la Commission comme présentant un risque systémique, l’exemption ne s’applique pas et l’ensemble des obligations GPAI, y compris les devoirs de risque systémique, s’applique intégralement.

Surtout, l’exemption pour licence libre ne couvre jamais le respect du droit d’auteur. Tous les fournisseurs GPAI, licence libre ou non, doivent respecter les obligations liées au droit d’auteur.

Obligations pour tous les fournisseurs GPAI (article 53)

L’article 53 établit trois piliers d’obligation qui s’appliquent à chaque fournisseur GPAI, indépendamment de la classification de risque du modèle. Ces obligations visent à garantir que les fournisseurs en aval, les déployeurs et les autorités ont les informations dont ils ont besoin pour respecter leurs propres exigences.

Exigences de documentation

Les fournisseurs GPAI doivent établir et tenir à jour une documentation technique du modèle, y compris son processus d’entraînement et d’essai et les résultats de son évaluation. La documentation doit contenir, au minimum :

• Une description générale du modèle, y compris ses tâches prévues, la date de publication, les modalités (texte, image, audio, etc.) et l’architecture
• Une description des données d’entraînement : sources, taille, méthode de curation, techniques de préparation des données, et procédures d’étiquetage le cas échéant
• Les ressources de calcul utilisées pour l’entraînement (y compris les FLOP), la méthodologie d’entraînement et les choix de conception clés
• Des informations sur les capacités et les limites du modèle, y compris les risques raisonnablement prévisibles et les mesures prises pour y répondre
• Un résumé d’évaluation couvrant les bancs d’essai de performance, la méthodologie de test et les modes de défaillance connus

Cette documentation doit être fournie au bureau de l’IA sur demande, et tenue à jour lorsque le modèle est mis à jour ou modifié. Ces exigences de documentation se rapprochent de celles de la documentation technique de l’annexe IV pour les systèmes à haut risque, mais adaptées au niveau du modèle plutôt qu’à celui du système.

Respect du droit d’auteur

Tous les fournisseurs GPAI doivent mettre en place une politique de respect du droit d’auteur de l’Union, concrètement la directive sur le droit d’auteur (directive (UE) 2019/790). Cette obligation a deux composantes opérationnelles :

1. Mécanisme de réserve des droits : les fournisseurs doivent identifier et respecter les réserves de droits exprimées par les titulaires au titre de l’article 4, paragraphe 3, de la directive sur le droit d’auteur, en particulier l’option de retrait de la fouille de textes et de données. Cela signifie mettre en place un système pour détecter et respecter les signaux d’option de retrait lisibles par machine (directives robots.txt, balises meta, ou autres mécanismes normalisés) utilisés par les titulaires pour réserver leur contenu à l’entraînement de l’IA.

2. Transparence des données d’entraînement : les fournisseurs doivent établir et rendre publiquement disponible un résumé suffisamment détaillé du contenu utilisé pour entraîner le modèle GPAI. Le bureau de l’IA a publié un canevas pour ce résumé. Le résumé doit permettre aux parties ayant un intérêt légitime, y compris les titulaires de droits, de comprendre et d’exercer leurs droits.

Cette obligation s’applique également aux modèles sous licence libre et propriétaires. Il n’y a pas d’exemption pour les fournisseurs en licence libre s’agissant du droit d’auteur. Compte tenu des contentieux en cours et de l’attention des autorités autour des pratiques d’entraînement, c’est l’un des domaines de conformité les plus exposés pour les fournisseurs GPAI dans le monde.

Transparence et information en aval

Les fournisseurs GPAI doivent mettre à disposition des fournisseurs en aval qui intègrent le modèle dans leurs propres systèmes ou produits :

• La documentation technique décrite ci-dessus (ou un résumé utile de celle-ci)
• Les informations qui permettent aux fournisseurs en aval de respecter leurs propres obligations au titre du règlement sur l’IA, y compris les informations nécessaires à la documentation des systèmes à haut risque, aux obligations de transparence de l’article 50 (voir aussi le guide pratique de l’article 50), et à la gestion des risques
• Une description claire des capacités, des limites et des risques connus du modèle
• Des informations sur les changements du modèle susceptibles d’affecter la conformité en aval

C’est le lien qui tient la chaîne d’approvisionnement du règlement sur l’IA. En pratique, les fournisseurs GPAI devront établir des dispositifs structurés de partage d’information : fiches de modèle, documentation d’API, rapports de sûreté, et processus de notification des changements.

Pour les entreprises qui construisent sur des modèles de fondation, la qualité des informations de transparence en amont détermine directement votre propre posture de conformité. Si votre fournisseur GPAI ne peut pas fournir les informations nécessaires, vous affrontez un trou qu’aucun effort interne ne peut combler. La diligence de chaîne d’approvisionnement, vérifier que votre fournisseur de modèle satisfait ses devoirs de l’article 53, est une première étape critique.

Risque systémique : obligations supplémentaires (article 55)

Le règlement sur l’IA reconnaît que certains modèles, par leur échelle, leurs capacités et leur portée, posent des risques qui dépassent les cas d’usage individuels pour toucher la société, la sécurité publique, les droits fondamentaux ou l’économie de l’Union. Ils sont classés comme modèles GPAI présentant un risque systémique.

Qu’est-ce qui déclenche la classification en risque systémique ?

Deux voies mènent à cette classification :

Voie 1, seuil de calcul : un modèle GPAI est présumé présenter un risque systémique si le volume cumulé de calcul utilisé pour son entraînement dépasse 10²⁵ opérations en virgule flottante (FLOP). C’est une règle nette : si vous franchissez le seuil, la présomption s’applique. Début 2026, ce seuil capture la plupart des modèles de frontière d’OpenAI, Anthropic, Google DeepMind et Meta, tout en excluant la plupart des modèles plus petits, spécialisés ou affinés.

Voie 2, désignation par la Commission : la Commission européenne peut désigner un modèle GPAI comme présentant un risque systémique d’après les critères de l’annexe XIII, même si le seuil de calcul n’est pas atteint. Les critères incluent le nombre de destinataires finaux, le degré d’autonomie, la pénétration du marché, l’intégration dans des infrastructures critiques, et le potentiel de mauvais usage. Cela évite qu’un modèle largement déployé soit exempté simplement parce qu’il a été entraîné de façon économe.

Les fournisseurs GPAI doivent notifier la Commission lorsque leur modèle satisfait l’un ou l’autre critère. L’obligation de notification pèse sur le fournisseur : il n’existe pas de filtrage externe qui vous attrape automatiquement. Le défaut de notification est lui-même un manquement.

Obligations supplémentaires pour les modèles à risque systémique

Au-delà de tous les devoirs de l’article 53, les fournisseurs de modèles GPAI présentant un risque systémique doivent aussi respecter l’article 55 :

Pour les laboratoires d’IA de frontière, ces obligations formalisent des pratiques que beaucoup mènent déjà de façon volontaire, mais désormais avec une portée contraignante et des conséquences d’exécution.

Le code de bonnes pratiques GPAI

Le code de bonnes pratiques GPAI a été publié le 10 juillet 2025 et entériné par la Commission européenne le 1er août 2025, la veille du jour où les obligations GPAI sont devenues exécutoires. C’est le document de conformité le plus important pour les fournisseurs GPAI : il traduit les obligations de haut niveau des articles 53 et 55 en mesures concrètes et actionnables.

Statut juridique

Le code de bonnes pratiques est volontaire, mais s’y tenir crée une présomption de conformité aux obligations correspondantes. Vous pouvez vous conformer en suivant le code, ou démontrer la conformité par d’autres moyens, mais la charge de prouver l’équivalence pèse sur vous. En pratique, le bureau de l’IA utilisera le code comme base de départ pour apprécier la conformité. S’en écarter sans justification claire et documentée est un risque.

Structure et contenu

Le code de bonnes pratiques s’organise en trois chapitres :

Chapitre 1, obligations de transparence : spécifications détaillées pour la documentation technique, le partage d’information en aval et les résumés des données d’entraînement exigés par l’article 53. Inclut des canevas pour les fiches de modèle, les résumés de provenance des données et les informations sur les capacités.

Chapitre 2, obligations de droit d’auteur : orientation pratique pour mettre en œuvre le mécanisme de réserve des droits, détecter et respecter les signaux d’option de retrait, et publier le résumé des données d’entraînement. Traite l’intersection avec les exceptions de fouille de textes et de données de la directive sur le droit d’auteur.

Chapitre 3, obligations de sûreté en cas de risque systémique : spécifications pour les protocoles d’évaluation du modèle, les méthodes de tests contradictoires, les socles de cybersécurité et les procédures de signalement d’incidents pour les modèles classés comme présentant un risque systémique au titre de l’article 55.

Comment utiliser le code pour la conformité

Pour les entreprises soumises aux obligations GPAI : faites correspondre vos obligations des articles 53 et 55 aux chapitres correspondants du code, mettez en œuvre les mesures précises, documentez votre respect, et lorsque vous vous en écartez, documentez vos mesures alternatives et leur justification. Pour les fournisseurs en aval et les déployeurs, le code sert de point de référence pour évaluer la conformité du fournisseur en amont : si un fournisseur revendique la conformité mais ne peut pas démontrer le respect des mesures du code, c’est un signal d’alerte dans la diligence.

Calendrier et périodes transitoires

Les obligations GPAI au titre de l’article 51 et des dispositions suivantes suivent un calendrier d’application distinct dans le calendrier plus large du règlement sur l’IA. Pour les dates en vigueur après le Digital Omnibus, voir aussi échéances après le Digital Omnibus.

Ce que « préexistant » signifie

• Modèles mis sur le marché après le 2 août 2025 : doivent respecter immédiatement toutes les obligations GPAI applicables. Pas de période transitoire.
• Modèles mis sur le marché avant le 2 août 2025 : bénéficient d’une période transitoire de deux ans qui expire le 2 août 2027. Les fournisseurs doivent travailler vers la conformité, mais ne sont pas soumis à l’exécution pendant la transition.

Nuance importante : si un modèle préexistant est modifié de façon substantielle après le 2 août 2025, il peut être traité comme un modèle nouvellement mis sur le marché, ce qui déclenche une conformité immédiate. Un réentraînement majeur, des changements d’architecture ou des élargissements de capacités y entreront probablement.

Pouvoirs d’exécution de la Commission

Le bureau de l’IA est le seul organe d’exécution des obligations GPAI : les autorités nationales ne font pas appliquer les règles GPAI. Les pouvoirs d’exécution du bureau de l’IA sont pleinement opérationnels depuis le 2 août 2026, même s’il pouvait déjà mener des enquêtes préliminaires et publier des orientations.

Scénarios concrets de conformité

Comprendre quelles obligations s’appliquent exige de situer votre rôle précis dans la chaîne GPAI. Les scénarios suivants montrent comment les règles fonctionnent en pratique.

Exemple concret : une jeune pousse qui affine Llama pour la recherche juridique. LexAI, une jeune pousse parisienne, prend Llama 3 de Meta (poids ouverts) et l’affine sur de la jurisprudence européenne, des bases législatives et des commentaires juridiques. LexAI rend le modèle affiné disponible comme produit SaaS aux cabinets, sous la marque « LexAI ». LexAI devient fournisseur GPAI parce qu’elle met un modèle modifié sur le marché sous son propre nom. LexAI doit respecter toutes les obligations de l’article 53 : documentation technique couvrant le processus d’affinage et les données juridiques d’entraînement, respect du droit d’auteur en s’assurant que les données d’entraînement ont été obtenues licitement, et transparence vis-à-vis des destinataires en aval sur les limites du modèle et la couverture juridictionnelle. LexAI a peu de chances de déclencher le risque systémique : le calcul d’affinage sera très en dessous de 10²⁵ FLOP. LexAI bénéficie toutefois de la conformité en amont de Meta pour le modèle Llama de base. LexAI devrait aussi évaluer si le produit final déclenche la classification à haut risque de l’article 6 lorsqu’il est utilisé pour un conseil juridique ou des dépôts judiciaires.

Exemple concret : une entreprise qui déploie GPT-4 via API pour le service client. NordicBank, une banque scandinave, intègre GPT-4 d’OpenAI via API dans son agent conversationnel de service client. NordicBank ne modifie pas le modèle : elle utilise la conception d’invites et la génération augmentée par récupération (RAG) à la couche applicative. NordicBank est déployeur, pas fournisseur GPAI. OpenAI porte les obligations des articles 53 et 55 pour GPT-4. Les obligations de NordicBank sont de niveau déployeur : assurer le contrôle humain, informer les clients qu’ils interagissent avec une IA (transparence de l’article 50, applicable depuis le 2 août 2026), conserver les journaux et surveiller les problèmes. NordicBank doit toutefois vérifier qu’OpenAI fournit les informations en aval exigées par l’article 53. Si l’agent conversationnel sert à l’évaluation de la solvabilité ou à des décisions financières, NordicBank peut devoir le traiter comme un système d’IA à haut risque, ce qui déclenche des obligations de fournisseur pour le système intégré (à compter du 2 décembre 2027 pour l’annexe III).

Exemple concret : une entreprise qui entraîne un modèle de fondation propriétaire. SovereignAI, une entreprise berlinoise, entraîne un modèle de fondation multimodal propriétaire à partir de zéro avec 5 × 10²⁵ FLOP et l’offre via API à des clients d’entreprise dans la santé, la finance et le secteur public. SovereignAI est un fournisseur GPAI en amont soumis à l’article 53 et à l’article 55. Le seuil de calcul est clairement dépassé, donc le modèle est présumé présenter un risque systémique. SovereignAI doit : (1) préparer une documentation technique d’ensemble, y compris la provenance des données d’entraînement et les détails d’architecture ; (2) mettre en œuvre le respect du droit d’auteur avec détection des réserves de droits et un résumé public des données d’entraînement ; (3) fournir aux clients en aval les informations nécessaires pour satisfaire leurs propres obligations ; (4) mener des évaluations du modèle et des tests contradictoires ; (5) mettre en place des protections de cybersécurité ; et (6) établir le signalement des incidents graves au bureau de l’IA. SovereignAI doit aussi notifier à la Commission la classification de son modèle en risque systémique. Compte tenu du déploiement dans la santé et le secteur public, SovereignAI devrait s’attendre à une attention accrue du bureau de l’IA et des autorités sectorielles.

Comment les obligations GPAI interagissent avec les règles à haut risque

L’un des aspects les plus complexes de l’architecture du règlement sur l’IA est l’interaction entre les obligations des modèles GPAI et les exigences des systèmes d’IA à haut risque. Ce sont deux voies réglementaires distinctes qui convergent lorsqu’un modèle GPAI est intégré dans un système à haut risque.

Le modèle de conformité à deux couches

Le règlement sur l’IA fonctionne selon un principe de responsabilité en couches :

• Couche modèle : le fournisseur GPAI est responsable des obligations au niveau du modèle (documentation, droit d’auteur, transparence, et devoirs de risque systémique le cas échéant) au titre des articles 53 et 55.
• Couche système : le fournisseur du système d’IA qui intègre le modèle GPAI est responsable des obligations au niveau du système (gestion des risques, gouvernance des données, exactitude, robustesse, contrôle humain, évaluation de la conformité) au titre des règles à haut risque.

Ces couches sont cumulatives, pas alternatives. Un système à haut risque bâti sur un modèle GPAI doit satisfaire les deux jeux d’exigences. Les obligations de la couche système autonome (annexe III) s’appliquent à compter du 2 décembre 2027, reportées du 2 août 2026 par le Digital Omnibus (règlement (UE) 2026/1744).

Implications pratiques pour les fournisseurs en aval

Si vous intégrez un modèle GPAI dans un système qui qualifie comme à haut risque, vous devez :

1. Obtenir la documentation en amont : demander et vérifier que le fournisseur GPAI a respecté ses obligations de l’article 53. La documentation du fournisseur GPAI forme le fondement de votre propre documentation technique pour le système.

2. Mener la gestion des risques au niveau du système : les évaluations de modèle du fournisseur GPAI ne se substituent pas à votre propre appréciation des risques au niveau du système. Vous devez évaluer les risques nés du cas d’usage précis, du contexte de déploiement et de l’interaction avec d’autres composants du système.

3. Procéder à l’évaluation de la conformité : votre système doit suivre la procédure d’évaluation de la conformité appropriée. Le statut de conformité du modèle GPAI ne vous en dispense pas.

4. Maintenir une surveillance continue : vous êtes responsable de la surveillance après mise sur le marché du système, y compris la surveillance des problèmes qui naissent de la couche modèle GPAI, tels que la dérive du modèle, des comportements émergents, ou des capacités que le fournisseur en amont n’avait pas documentées.

5. Gérer les risques de mise à jour : lorsque le fournisseur GPAI met à jour le modèle sous-jacent, vous devez évaluer si la mise à jour affecte le statut de conformité de votre système. C’est particulièrement pertinent pour les intégrations par API, où les mises à jour de modèle peuvent intervenir sans adhésion explicite.

Qui porte la responsabilité ?

Le fournisseur GPAI est responsable des défaillances de la couche modèle (par exemple une curation insuffisante des données d’entraînement). Le fournisseur du système est responsable des défaillances de la couche système (par exemple l’absence de garanties pour le cas d’usage précis). Ce modèle en couches incite à des arrangements contractuels robustes, y compris le partage d’information adossé à des engagements de service, la notification des changements et la coordination de la réponse aux incidents. Pour une liste de contrôle couvrant les deux couches, voir la liste de contrôle du règlement sur l’IA.

Sanctions en cas de manquement

Le manquement GPAI entre dans le régime de sanctions du règlement sur l’IA établi à l’article 99. Le palier de sanctions propre aux violations GPAI est :

Jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial (le montant le plus élevé pour les grandes organisations ; le montant le plus faible pour les PME et les jeunes pousses).

C’est le même palier que pour les manquements aux systèmes à haut risque et aux manquements aux obligations de transparence. C’est le palier intermédiaire de la structure à trois paliers du règlement sur l’IA :

Pour le détail du calcul des amendes, y compris le mécanisme d’ajustement PME et la comparaison avec les sanctions du RGPD, voir le guide des sanctions du règlement sur l’IA.

Spécificités d’exécution pour le GPAI

Les obligations GPAI sont exécutées exclusivement par la Commission européenne via le bureau de l’IA, une autorité unique pour toute l’Union, ce qui élimine l’arbitrage juridictionnel. Le bureau de l’IA peut demander la documentation, mener des enquêtes, infliger des amendes et exiger des mesures correctives, y compris restreindre ou retirer un modèle du marché. Les pouvoirs d’exécution sont pleinement opérationnels depuis le 2 août 2026.

Questions fréquentes

L’usage de l’API ChatGPT fait-il de moi un fournisseur GPAI ?

Non. Si vous accédez à GPT-4 ou à tout autre modèle GPAI via une API et l’utilisez dans vos propres opérations, pour alimenter un agent conversationnel, générer du contenu ou automatiser des processus, vous êtes déployeur, pas fournisseur GPAI. OpenAI reste le fournisseur GPAI et porte les obligations des articles 53 et 55. Vos obligations sont de niveau déployeur : contrôle humain, transparence vis-à-vis des destinataires, conservation des journaux et surveillance. En revanche, si vous construisez un produit ou un service distinct que vous vendez à des tiers sous votre propre marque, surtout si vous affinez ou modifiez de façon substantielle le modèle, vous pouvez vous approcher du statut de fournisseur. La question clé est de savoir si vous mettez un modèle ou un système sur le marché sous votre propre nom.

Les modèles sous licence libre sont-ils pleinement exemptés des obligations GPAI ?

Non. Les modèles GPAI sous licence libre reçoivent une exemption limitée de certaines exigences de documentation et de partage d’information en aval. L’exemption ne s’applique pas aux obligations de droit d’auteur : tous les fournisseurs GPAI, quel que soit le régime de licence, doivent respecter les règles de droit d’auteur. Plus important, l’exemption pour licence libre ne s’applique pas si le modèle est classé comme présentant un risque systémique (soit parce qu’il dépasse le seuil de calcul de 10²⁵ FLOP, soit parce que la Commission le désigne). Llama 3 de Meta, par exemple, est à poids ouverts mais dépasse probablement le seuil de calcul, ce qui signifie qu’il doit respecter l’ensemble des obligations GPAI, y compris les devoirs de risque systémique.

De quelle documentation ai-je besoin en tant que fournisseur GPAI ?

Au minimum : (1) une documentation technique couvrant l’architecture, le processus d’entraînement, les sources de données, le calcul, les évaluations, les capacités et les limites ; (2) un résumé public des données d’entraînement selon le format du bureau de l’IA ; (3) une politique documentée de respect du droit d’auteur avec détection des réserves de droits ; et (4) des dossiers d’information en aval pour les intégrateurs. Si vous êtes classé comme présentant un risque systémique, ajoutez les rapports d’évaluation du modèle, les résultats des tests contradictoires, la documentation de cybersécurité et une procédure de signalement d’incidents. Le code de bonnes pratiques fournit un canevas pour chacun.

L’affinage d’un modèle fait-il de moi un fournisseur GPAI ?

Cela dépend de ce que vous faites du résultat. Si vous affinez un modèle et l’utilisez uniquement au sein de votre propre organisation, pour des opérations internes, de la recherche ou de l’analyse, vous êtes déployeur, pas fournisseur. Si vous affinez un modèle puis le rendez disponible à des tiers, que ce soit par une API, un paquet téléchargeable ou un embarquement dans un produit, vous devenez fournisseur GPAI pour le modèle affiné. Vos obligations de l’article 53 porteraient sur la couche d’affinage : quelles données vous avez utilisées, comment vous avez évalué le modèle affiné, quelles capacités et limites ont changé. Vous n’auriez pas à redocumenter l’ensemble du modèle de base, mais vous devez vous assurer que la documentation du fournisseur en amont est disponible pour le modèle de base.

Comment le seuil de 10²⁵ FLOP fonctionne-t-il en pratique ?

Le seuil couvre le volume cumulé de calcul utilisé pour entraîner le modèle, mesuré en opérations en virgule flottante. C’est une règle nette : si votre course d’entraînement (y compris tout pré-entraînement, entraînement continu, ou affinage étendu fonctionnellement équivalent à un entraînement) dépasse 10²⁵ FLOP, le modèle est présumé présenter un risque systémique. Le fournisseur peut tenter de réfuter cette présomption en présentant à la Commission des arguments suffisamment étayés, mais la charge de la preuve pèse sur le fournisseur et la barre est haute. En pratique, le seuil capture les modèles de frontière actuels (classe GPT-4 et au-delà) tout en excluant la plupart des modèles plus petits, des modèles de domaine et des courses d’affinage typiques. La Commission a le pouvoir d’actualiser ce seuil à mesure que les capacités matérielles évoluent.

Que faire si mon fournisseur GPAI refuse de partager la documentation ?

C’est un vrai risque de conformité. Si votre fournisseur GPAI en amont ne peut pas ou ne veut pas fournir la documentation exigée par l’article 53, vous affrontez un trou dans votre propre chaîne de conformité, surtout si vous construisez un système d’IA à haut risque par-dessus le modèle. Vous devriez : (1) documenter vos demandes et les réponses du fournisseur pour démontrer la diligence ; (2) évaluer des fournisseurs alternatifs qui offrent une documentation conforme ; (3) apprécier si le trou est matériel au regard de vos propres obligations ; et (4) envisager de saisir le bureau de l’IA, qui peut contraindre les fournisseurs GPAI à partager les informations requises. Le règlement sur l’IA est conçu pour que le manquement en amont ne se répercute pas automatiquement sur les déployeurs, mais seulement si vous démontrez des démarches raisonnables pour obtenir l’information. Commencez par l’outil gratuit de classification des risques pour comprendre quelles obligations s’appliquent.

Les obligations GPAI ne sont pas une préoccupation future : c’est du droit en vigueur, avec de vraies conséquences d’exécution. Que vous entraîniez des modèles de frontière, affiniez des modèles sous licence libre, ou construisiez des applications sur des API de modèles de fondation, comprendre votre position dans la chaîne GPAI est la première étape vers la conformité. Situez votre rôle, évaluez vos obligations, vérifiez vos fournisseurs en amont, et documentez tout.

Évaluez vos obligations au titre du règlement sur l’IA maintenant →