AI Act : modèle d’IA à usage général présentant un risque systémique (articles 51, 52 et 55, annexe XIII)

L’AI Act (règlement (UE) 2024/1689 sur l’intelligence artificielle, IA) ajoute une seconde couche d’obligations au-dessus des modèles d’IA à usage général : celle des modèles dits « à risque systémique ». On y entre par un seuil de calcul d’entraînement de 10²⁵ FLOP (floating-point operations, opérations en virgule flottante) ou par une décision de la Commission, et on n’en sort que par une démonstration étayée ou une réévaluation. Cette page couvre la classification (article 51), la procédure de notification et de contestation (article 52), les obligations supplémentaires (article 55), l’annexe XIII et la section 2 de l’annexe XI.

→ Lire l’explication complète de la marmotte

Les obligations de base de l’article 53 (documentation de l’annexe XI section 1, informations aux fournisseurs en aval de l’annexe XII, politique droit d’auteur, résumé des données d’entraînement) sont traitées sur la page modèles d’IA à usage général. Elles restent dues ici : l’article 55 s’ajoute, il ne remplace rien.

Deux voies vers le risque systémique : seuil de 10²⁵ FLOP et désignation (article 51)

Trois définitions de l’article 3 portent tout l’édifice. Les « capacités à fort impact » (point 64) sont des capacités égales ou supérieures à celles des modèles d’IA à usage général les plus avancés. Le « risque systémique » (point 65) est un risque propre à ces capacités, avec une incidence significative sur le marché de l’Union européenne (UE) du fait de la portée du modèle ou d’effets négatifs réels ou raisonnablement prévisibles sur la santé publique, la sûreté, la sécurité publique, les droits fondamentaux ou la société, et susceptible de se propager à grande échelle le long de la chaîne de valeur. Le point 67 définit l’opération en virgule flottante.

L’article 51 §1 ouvre deux voies. Voie a) : le modèle a des capacités à fort impact, évaluées par des méthodologies et outils techniques appropriés (indicateurs, critères de référence). Voie b) : la Commission le désigne, d’office ou sur alerte qualifiée du groupe scientifique, en s’appuyant sur les critères de l’annexe XIII. L’article 51 §2 ajoute une présomption : au-delà de 10²⁵ FLOP de calcul cumulé d’entraînement, les capacités à fort impact sont présumées.

Position de la page : le seuil n’est pas la définition, c’est un raccourci de preuve. Un modèle à 8 × 10²⁴ FLOP n’est pas « hors du champ », il est seulement hors de la présomption, et reste désignable par la voie b). Inversement, franchir 10²⁵ FLOP n’interdit pas de plaider l’exception de l’article 52 §2. Raisonner en « dessous du seuil, rien à faire » revient à lire un panneau de limitation de vitesse comme une garantie de ne jamais être arrêté.

L’article 51 §3 permet à la Commission de modifier les seuils et de compléter critères et indicateurs par actes délégués (article 97). Conséquence d’architecture : toute logique interne de déclenchement doit lire le seuil comme un paramètre, pas comme une constante gravée dans un tableur de planification. Le règlement (UE) 2026/1744 (omnibus IA, Journal officiel du 24 juillet 2026, en vigueur le 27 juillet 2026) ne touche ni aux articles 51, 52 et 55, ni au seuil de 10²⁵ FLOP.

Annexe XIII : les critères de désignation par la Commission

La voie b) repose sur sept critères, qui forment aussi la grille de lecture la plus honnête pour un fournisseur qui veut savoir où il se situe :

a) nombre de paramètres du modèle ;
b) qualité ou taille du jeu de données, par exemple mesurée en tokens (unités de texte découpées par le modèle) ;
c) quantité de calcul d’entraînement, en FLOP ou par combinaison du coût, du temps et de l’énergie estimés ;
d) modalités d’entrée et de sortie, avec des seuils de l’état de l’art par modalité, séquences biologiques comprises ;
e) critères de référence et évaluations des capacités : tâches réalisées sans entraînement supplémentaire, capacité d’adaptation, degré d’autonomie, extensibilité, outils accessibles ;
f) impact sur le marché intérieur, présumé à partir de 10 000 utilisateurs professionnels enregistrés établis dans l’Union ;
g) nombre d’utilisateurs finaux inscrits.

Le critère f) est le plus sous-estimé. Un modèle entraîné avec un budget modeste mais distribué largement par une API (Application Programming Interface) à des entreprises européennes coche une case que le calcul ne coche pas. Aucun critère ne suffit seul : la Commission apprécie si le modèle a des capacités ou un impact équivalents à ceux de la voie a), au vu de l’ensemble de la grille. Le critère e) vise directement l’outillage : un modèle branché sur des outils, du code exécutable ou de la navigation gagne en autonomie évaluée, ce qui rejoint les surfaces décrites dans la page sur la sécurité des agents autonomes outillés. La présence du critère c) sous forme « coût, temps, énergie » ferme aussi une échappatoire : ne pas tenir de compteur de FLOP ne rend pas le calcul inestimable.

Estimer le calcul cumulé d’entraînement avant de le dépenser

Prérequis de mise en œuvre : avant tout grand entraînement, disposer d’une estimation chiffrée du calcul cumulé, de sa méthode et des hypothèses (paramètres, tokens, architecture, phases prévues). Les lignes directrices de la Commission du 18 juillet 2025 (source secondaire, à vérifier dans la version en vigueur) raisonnent en calcul cumulé d’entraînement et attendent une notification dès qu’il est raisonnablement prévisible que le seuil sera franchi, y compris avant le grand entraînement, accompagnée de l’estimation et de sa méthode.

Ordre de grandeur courant, sans valeur officielle : pour un transformeur dense, le calcul d’entraînement vaut environ 6 × nombre de paramètres × nombre de tokens. Cette approximation ignore les architectures à experts clairsemés, le recalcul d’activations et les phases annexes ; elle sert à savoir de quel côté de la ligne on joue, pas à plaider devant le Bureau de l’IA.

Le piège classique : additionner seulement le pré-entraînement principal. Le mot « cumulé » invite à intégrer les phases successives prévues sur le même modèle (pré-entraînement prolongé, réglage fin, alignement). Le chiffre qui pose problème est souvent celui de la phase « de finition » que personne n’avait mise dans le budget initial. La frise ci-dessous montre où se place la notification : au moment où l’estimation franchit le seuil, pas au moment où les GPU (Graphics Processing Units) ont fini de tourner.

Il faut y lire que la notification précède l’entraînement dès que la trajectoire est connue, et que le suivi sous le seuil n’est jamais terminé : chaque phase ajoutée relance le calcul.

Notification, contestation et désignation (article 52)

L’article 52 §1 impose de notifier la Commission sans tarder, au plus tard deux semaines après que le critère est rempli ou qu’il a été établi qu’il le sera. Si la Commission découvre un modèle non notifié qui remplit le critère, elle peut le désigner elle-même. L’article 52 §2 permet de joindre des arguments suffisamment étayés pour démontrer que, exceptionnellement, le modèle ne présente pas de risque systémique en raison de ses caractéristiques spécifiques. Si ces arguments sont jugés insuffisants (§3), ils sont rejetés et le modèle est considéré comme à risque systémique.

La désignation d’office ou sur alerte qualifiée (article 52 §4, renvoyant à l’article 90 §1 a)) suit les critères de l’annexe XIII. La réévaluation (§5) se demande sur requête motivée, avec des éléments objectifs, détaillés et nouveaux, au plus tôt six mois après la décision de désignation, puis six mois après chaque décision de maintien. La Commission publie et tient à jour une liste des modèles à risque systémique (§6). L’arbre suivant montre les branches : il faut y repérer que toutes les sorties « favorables » passent par une démonstration du fournisseur, jamais par le silence.

Recommandation propre à la page : ne plaider l’exception que sur des résultats d’évaluation mesurés, pas sur l’architecture ou l’intention. « Le modèle est spécialisé » n’est pas un argument ; « sur tel jeu de tests de capacités dangereuses, le modèle reste sous l’état de l’art pour telles raisons techniques documentées » en est un. Et préparer en parallèle le dispositif de l’article 55 comme si le rejet était acquis : un rejet découvert sans cadre d’évaluation prêt laisse le fournisseur sans rien à présenter. Le compromis central du sujet est là : notifier tôt expose plus tôt aux obligations, mais notifier tard expose à la désignation, à l’article 101 et à une réévaluation qui ne s’ouvre pas avant six mois.

Obligations de l’article 55 : évaluation, risques systémiques, incidents graves, cybersécurité

En plus des articles 53 et 54, l’article 55 §1 impose quatre obligations. La carte ci-dessous associe chacune à la preuve qu’un contrôle demandera : c’est la colonne de droite qui coûte, pas la gauche.

Le point a) parle d’essais contradictoires « réalisés et documentés » : une équipe rouge (red team, équipe chargée d’attaquer le modèle pour en trouver les failles) qui ne laisse pas de trace écrite n’existe pas au sens du texte. La méthode d’un exercice interne est décrite dans la page sur le red teaming d’un LLM local. Le point b) vise le niveau de l’Union, pas le seul produit : l’usage en aval par des intégrateurs fait partie des origines du risque, ce qui rejoint la répartition décrite dans rôles fournisseur et déployeur.

L’annexe XI section 2 complète la documentation technique, uniquement pour ces modèles : description détaillée des stratégies d’évaluation et de leurs résultats (critères, indicateurs, méthodes d’identification des limites) ; le cas échéant, mesures d’essais contradictoires internes ou externes et adaptations du modèle (alignement, réglage fin) ; le cas échéant, architecture du système, c’est-à-dire comment les composants logiciels s’alimentent et s’intègrent.

L’article 55 §2 organise la preuve : codes de bonne pratique (article 56) jusqu’à publication d’une norme harmonisée, présomption de conformité par les normes harmonisées, ou autres moyens appropriés soumis à l’appréciation de la Commission. Le code de bonnes pratiques IA à usage général, version finale du 10 juillet 2025, jugé adéquat par la Commission et le Comité IA le 1er août 2025 (source secondaire, à vérifier dans la version en vigueur), réserve son chapitre « Sûreté et sécurité » au risque systémique : cadre de sûreté et de sécurité, rapport sur le modèle, et délais de signalement des incidents graves de 2 jours (perturbation grave d’une infrastructure critique), 5 jours (atteinte grave à la cybersécurité), 10 jours (décès), 15 jours (atteinte grave à la santé, aux droits fondamentaux, aux biens ou à l’environnement), avec rapport final au plus tard 60 jours après la résolution. Recommandation de la page : calquer la procédure interne d’incident sur ces délais même hors signature du code, parce que « sans retard injustifié » a toutes les chances d’être lu à leur aune. L’article 55 §3 renvoie la confidentialité des informations transmises à l’article 78.

Surface d’attaque du modèle et de son infrastructure physique (article 55 §1 d))

Le point d) protège deux objets distincts : le modèle et l’infrastructure physique. Un modèle à risque systémique, c’est d’abord un fichier de poids dont la fuite annule d’un coup toutes les mesures d’atténuation appliquées côté service. Un garde-fou au niveau de l’API ne suit pas les poids sur une clé USB.

Attaques connues et contre-mesures :

Vol des poids (accès interne, compte d’administration compromis, stockage objet mal cloisonné) : chiffrement au repos avec clés en HSM (Hardware Security Module) ou service de clés à accès journalisé, double validation pour tout export, segmentation du réseau d’entraînement, et suivi d’empreinte des fichiers.
Empoisonnement des données d’entraînement : provenance des corpus, contrôle d’intégrité des jeux de données, revue des sources ajoutées tardivement ; détail dans la page sur l’empoisonnement des données d’entraînement.
Compromission de la chaîne d’entraînement (dépendances, images de conteneur, scripts d’orchestration) : signature des artefacts, construction reproductible, comptes de service à privilèges minimaux.
Extraction ou distillation par l’API : limitation de débit par identité, détection de motifs de requêtes systématiques, contractualisation des usages.
Contournement des garde-fous en inférence : évaluation continue, pas seulement avant la mise sur le marché ; l’usage offensif de modèles est discuté dans attaquants et IA.

Le pendant système de ces mesures pour les systèmes à haut risque figure dans la page robustesse et cybersécurité ; le vocabulaire diffère, les contrôles se recoupent largement. L’expression « infrastructure physique » rappelle que le centre de calcul (accès aux salles, chaîne d’approvisionnement du matériel, élimination des disques) entre dans le périmètre. Un SOC (Security Operations Centre) qui ne voit que les journaux applicatifs ne couvre que la moitié du texte.

Ce que la classification ne garantit pas

Être notifié et outillé ne rend pas un modèle sûr : l’article 55 impose de chercher, mesurer et documenter, pas d’atteindre un niveau de risque nul. Une évaluation conforme à l’état de la technique d’aujourd’hui ne couvre pas une capacité émergente découverte par un utilisateur demain ; d’où l’exigence de suivi des incidents.

La classification ne transfère pas non plus d’obligations aux intégrateurs : un fournisseur de système à haut risque qui intègre ce modèle reste soumis à sa propre évaluation de conformité, et un déployeur qui consomme le modèle par API garde ses obligations propres, décrites dans AI Act et déploiement d’un modèle par API. Enfin, l’exemption open source ne joue pas : l’article 53 §2 l’exclut pour les modèles à risque systémique, et l’article 54 §6 écarte de même la dispense de mandataire. Publier les poids sous licence libre ne fait sortir de rien ; cela rend seulement le point d) plus difficile à tenir.

Conditions d’exploitation : secrets, rotation, supervision, reprise

Prérequis organisationnels avant la notification : un responsable identifié de la relation avec le Bureau de l’IA, un registre des estimations de calcul versionné, une procédure d’incident avec astreinte capable de tenir un délai de 2 jours, et un inventaire des copies de poids (entraînement, évaluation, production, sauvegardes, partenaires).

Clés et secrets (recommandations de la page) : rotation des clés de chiffrement des poids à chaque changement d’équipe ayant eu un accès privilégié, rotation des clés d’API des clients à fort volume, journalisation de tout déchiffrement. Supervision : alertes sur les exports de volumes comparables à la taille des poids, sur les motifs d’extraction côté API, et sur les signalements d’usage abusif en aval. Sauvegarde et reprise : les sauvegardes de poids héritent du même niveau de protection que l’original, ce qui interdit le stockage froid « hors périmètre » ; la reprise inclut la capacité à retirer ou restreindre une version du modèle si une mesure corrective l’exige.

Exemple : un laboratoire fictif planifie un entraînement autour de 10²⁵ FLOP

Un laboratoire fictif prévoit un transformeur dense de 70 milliards de paramètres, entraîné sur 15 000 milliards de tokens. Avec l’approximation 6 × paramètres × tokens, le pré-entraînement représente environ 6,3 × 10²⁴ FLOP : sous le seuil. La feuille de route prévoit ensuite une prolongation sur 10 000 milliards de tokens supplémentaires, soit environ 4,2 × 10²⁴ FLOP. Le cumul atteint environ 1,05 × 10²⁵ FLOP, au-dessus de la présomption. Le franchissement est donc connu dès la planification.

Lecture : la notification part sur le plan, pas sur le modèle fini. L’option « tailler la prolongation pour rester sous le seuil » existe, mais elle ne protège que de la présomption ; si le modèle est ensuite distribué à au moins 10 000 utilisateurs professionnels enregistrés dans l’Union, le critère f) de l’annexe XIII est présumé rempli et la voie b) redevient une hypothèse sérieuse, à capacités comparables. Recommandation de la page : choisir la taille du modèle sur des critères techniques, et traiter le seuil comme un coût de conformité à budgéter, pas comme une contrainte de conception à contourner par quelques milliards de tokens.

Sanctions et calendrier applicables

Le chapitre V s’applique depuis le 2 août 2025. Les modèles mis sur le marché avant cette date ont jusqu’au 2 août 2027 (article 111 §3). Les amendes de la Commission (article 101 §1) atteignent 3 % du chiffre d’affaires annuel mondial ou 15 000 000 EUR, le montant le plus élevé étant retenu, et sont applicables à partir du 2 août 2026 (article 113). Le détail des échéances figure dans le calendrier de l’AI Act. Pour savoir si un modèle donné relève de ces règles ou quelle est l’exposition d’une organisation précise, le texte de référence est le règlement (UE) 2024/1689 au Journal officiel, et la réponse appartient à un conseil juridique.

🐝 Ce qui arrive si on s’en passe

Sans estimation cumulée tenue phase par phase, le franchissement du seuil n’est détecté qu’après coup, et le délai de deux semaines est dépassé avant même d’avoir été ouvert. La Commission peut alors désigner le modèle sans que le fournisseur ait pu joindre d’arguments, et aucune demande de réévaluation n’est recevable avant six mois. Sans protection des poids et de l’infrastructure physique, une seule copie exfiltrée circule sans aucun des garde-fous appliqués côté service, et plus rien ne permet d’en retracer l’usage. Sans registre d’incidents, les délais de signalement courts deviennent intenables et aucune mesure corrective ne peut être justifiée. Depuis le 2 août 2026, chacun de ces manquements relève des amendes de l’article 101.

🦫 Explication de la marmotte 🍫

Une loi européenne encadre les très grands programmes d’intelligence artificielle capables de faire beaucoup de tâches différentes. Elle met à part les plus puissants, ceux dont un mauvais usage pourrait toucher toute la société. Pour les repérer, elle regarde surtout la quantité de calculs utilisée pour les fabriquer : au-delà d’un nombre très élevé, fixé par la loi, le programme est présumé dangereux. La Commission européenne peut aussi en désigner un elle-même, en regardant sa taille, ses capacités, ou le nombre d’entreprises qui l’utilisent. Celui qui fabrique le programme doit prévenir la Commission dans les deux semaines où il sait qu’il va dépasser ce nombre, souvent avant même de lancer la fabrication. Il peut expliquer, preuves à l’appui, pourquoi son programme ne présente pas ce danger ; si ses preuves sont jugées trop faibles, le programme reste classé. Une fois classé, il doit tester son programme en essayant volontairement de le faire mal se comporter, noter les résultats, étudier les dangers pour toute l’Europe, signaler rapidement les accidents graves et protéger le programme comme les ordinateurs qui le font tourner. S’il ne le fait pas, il risque une amende pouvant atteindre une part de son chiffre d’affaires mondial. Il peut demander à être réexaminé, mais seulement après six mois et avec des éléments nouveaux.

Pages voisines

La citent

AI Act : modèle d'IA à usage général présentant un risque systémique (articles 51, 52 et 55, annexe XIII)

Elle cite

: les deux pages se citent l’une l’autre.