AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPD

AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPD

Un fournisseur ou un déployeur de système d’IA relève rarement d’un seul texte européen : l’AI Act vise le système, le CRA le produit, NIS 2 l’entité qui exploite un service, le RGPD le traitement de données personnelles. Pour une même mesure de sécurité, un texte l’exige, un autre présume qu’elle est remplie, un troisième ne dit rien. La page trace ces ponts, isole ce qu’il faut faire deux fois et propose un dossier de preuve unique qui sert aux quatre.

Explication de la marmotte

Un même bâtiment peut recevoir la visite des pompiers, de l’inspecteur sanitaire et de l’assureur. Chacun a sa propre grille, mais beaucoup de leurs questions se ressemblent. Celui qui range ses papiers une seule fois, au bon endroit, répond aux trois sans tout refaire. Ici, les visiteurs sont quatre lois européennes, et le bâtiment est une intelligence artificielle.

→ Lire l’explication complète de la marmotte

La page n’est pas un avis juridique : elle cite les articles et renvoie au texte officiel (EUR-Lex, règlement (UE) 2024/1689). Savoir si une organisation donnée est en règle relève d’un avocat.

Qui relève de quoi : rôle, objet et texte applicable

Les quatre textes ne se recouvrent pas parce qu’ils parlent de la même chose, mais parce qu’un même projet cumule plusieurs objets. Le déclencheur diffère à chaque fois :

• AI Act (règlement (UE) 2024/1689, règlement sur l’intelligence artificielle) : déclenché par un système d’IA et par le rôle tenu à son égard (fournisseur, déployeur, importateur). Les obligations lourdes visent le haut risque. Voir rôles fournisseur et déployeur et classification haut risque.
• CRA (Cyber Resilience Act, règlement (UE) 2024/2847 sur la cyberrésilience) : déclenché par un produit comportant des éléments numériques mis sur le marché, y compris ses solutions de traitement de données à distance (art. 3 point 2 : traitement conçu sous la responsabilité du fabricant et dont l’absence empêche le produit d’exécuter une de ses fonctions). Détail dans la page Cyber Resilience Act.
• NIS 2 (Network and Information Security, directive (UE) 2022/2555) : déclenchée par l’entité (secteur, taille) qui exploite un service. C’est une directive : la loi nationale de transposition fait foi, pas le texte européen. Voir NIS 2 : obligations, périmètre, sanctions.
• RGPD (Règlement général sur la protection des données, règlement (UE) 2016/679) : déclenché par un traitement de données personnelles et par le rôle de responsable ou de sous-traitant. Voir ce que le RGPD impose à l’architecture.

La matrice ci-dessous se lit ligne par ligne : chaque objet du projet active un texte et un rôle, et un même projet coche souvent les quatre lignes.

Le dernier point coûte cher quand il est ignoré. Le considérant 12 du CRA sort du périmètre les services en nuage qui ne supportent pas la fonction d’un produit, et renvoie les SaaS (Software as a Service), PaaS (Platform as a Service) et IaaS (Infrastructure as a Service) vers NIS 2. Une IA vendue uniquement en SaaS perd donc le pont du CRA décrit plus bas ; elle reste sur l’article 15 de l’AI Act, et son fournisseur peut relever de NIS 2. Le même modèle, livré en version installée avec un backend indispensable, entre au contraire dans le CRA. Deux offres, deux régimes, un seul modèle : la conformité suit le canal de distribution, pas les poids du réseau de neurones.

Prérequis de cette cartographie. Avant toute mesure : un inventaire des systèmes d’IA avec leur classification de risque, la liste des produits mis sur le marché et de leurs composants distants, la qualification NIS 2 de chaque entité du groupe selon la transposition applicable, et le registre des traitements RGPD. Sans ces quatre listes rapprochées par un identifiant commun, aucune mutualisation n’est possible. En pratique, ces quatre listes existent souvent déjà, tenues par quatre équipes qui ne se parlent qu’en réunion de crise.

Calendrier. Le volet IA de l’omnibus numérique (règlement (UE) 2026/1744, en vigueur le 27 juillet 2026) reporte le haut risque de l’annexe III au 2 décembre 2027 et celui de l’annexe I au 2 août 2028, sans toucher à l’article 15. Le CRA s’applique en général le 11 décembre 2027, mais son article 14 (notifications) court depuis le 11 septembre 2026 et son chapitre IV (organismes notifiés) depuis le 11 juin 2026. Détail dans le calendrier de l’AI Act.

Ponts écrits entre textes : CRA art. 12, Cybersecurity Act, AIPD et FRIA

Les textes organisent eux-mêmes quelques passerelles. Elles ont toutes un périmètre étroit, et c’est ce périmètre qu’on oublie.

CRA art. 12. Un produit qui relève du CRA et qui est classé à haut risque par l’article 6 de l’AI Act est réputé conforme aux exigences de cybersécurité de l’article 15 s’il satisfait l’annexe I du CRA (partie I, exigences produit ; partie II, gestion des vulnérabilités) et si la déclaration UE de conformité du CRA démontre ce niveau. Le texte dit « sans préjudice des exigences en matière d’exactitude et de robustesse » : ces deux volets restent à prouver côté AI Act. La procédure d’évaluation reste celle de l’article 43 de l’AI Act, et les organismes notifiés AI Act peuvent aussi évaluer l’annexe I du CRA (s’ils ont été évalués au regard de l’article 39 du CRA). Exception (art. 12 §3) : un produit classé dans les annexes III ou IV du CRA qui, côté AI Act, relèverait du seul contrôle interne (annexe VI) suit les procédures du CRA pour les exigences essentielles de cybersécurité. Voir évaluation de la conformité.

Cybersecurity Act, art. 42 §2 de l’AI Act. Un système d’IA à haut risque certifié, ou couvert par une déclaration de conformité, dans un schéma européen de cybersécurité dont les références sont publiées au JO (Journal officiel de l’Union européenne) est présumé conforme à l’article 15, mais seulement dans la mesure où le certificat couvre ces exigences. Un certificat qui ne parle ni d’empoisonnement ni d’exemples contradictoires ne présume rien sur ces points.

AIPD et FRIA. L’article 26 §9 de l’AI Act oblige le déployeur à utiliser les informations fournies au titre de l’article 13 pour son AIPD (analyse d’impact relative à la protection des données, art. 35 RGPD). L’article 27 §4 prévoit que la FRIA (Fundamental Rights Impact Assessment, analyse d’impact sur les droits fondamentaux) complète l’AIPD lorsqu’une obligation est déjà remplie par celle-ci. Recommandation de la page : un seul document, une partie commune (description du système, données, flux, mesures), deux annexes de conclusions. Méthode AIPD dans la page dédiée.

NIS 2 art. 4. Il écarte les dispositions de NIS 2 quand un acte sectoriel impose des mesures ou des notifications d’effet au moins équivalent. L’AI Act n’en est pas un (lecture de la page) : il régit un produit, le système d’IA, et non les mesures de sécurité de l’entité qui l’exploite. Une conformité AI Act ne dispense jamais une entité NIS 2 de l’article 21.

Recouvrements non organisés : ce qu’il faut faire deux fois

Hors de ces ponts, les textes s’empilent sans se référencer. Trois zones reviennent systématiquement.

L’apport propre de l’article 15 §5. Aucun des trois autres textes ne nomme les attaques spécifiques à l’IA : empoisonnement des données, empoisonnement de modèle par des composants préentraînés, exemples contradictoires ou invasion de modèle, attaques visant la confidentialité, défauts du modèle. Une déclaration CRA démontre la gestion des vulnérabilités logicielles ; elle ne démontre pas qu’un adversaire ne peut pas faire basculer un score avec trois mots bien placés dans un CV. Contre-mesures attendues : provenance et intégrité des jeux de données (gouvernance des données, empoisonnement des données), inventaire des modèles préentraînés et de leurs dépendances (un SBOM, Software Bill of Materials, étendu aux poids et aux jeux de données), signature des artefacts de modèle, tests adversariaux à chaque réentraînement, limitation de débit et détection de motifs de requêtes contre l’extraction et l’inférence d’appartenance. Détail dans robustesse et cybersécurité.

La base légale RGPD. L’article 2 §7 de l’AI Act maintient le droit de la protection des données intact, « sans préjudice de l’article 10, paragraphe 5, et de l’article 59 ». L’article 10 §5 autorise à titre exceptionnel le traitement de catégories particulières pour détecter et corriger des biais, avec garanties ; l’article 59 couvre les bacs à sable réglementaires. En dehors de ces deux cas, l’AI Act ne fournit aucune base légale : entraînement, inférence et journalisation de données personnelles exigent chacun leur fondement au titre du RGPD. De même, l’article 2 §9 maintient le droit de la consommation et de la sécurité des produits.

Les mesures de l’article 21 de NIS 2 et de l’article 32 du RGPD. Contrôle d’accès, MFA (Multi-Factor Authentication), cryptographie, sécurité de la chaîne d’approvisionnement : NIS 2 les exige de l’entité, le RGPD les exige du traitement, l’AI Act exige la cybersécurité du système. Les mesures sont les mêmes, les périmètres d’audit non. Aucun texte ne présume l’autre : la mesure se fait une fois, la preuve se présente trois fois, sous trois angles.

Ce que l’articulation ne garantit pas. Une présomption de conformité n’est pas une preuve de sécurité : elle déplace la charge de la démonstration, elle ne supprime pas le risque. Elle tombe aussi dès que le produit sort du périmètre certifié (nouvelle version du modèle, nouveau composant distant). Et aucun pont ne couvre l’exactitude, la robustesse ni le contrôle humain, qui viennent de l’AI Act seul.

Notifications d’incident en parallèle : NIS 2, CRA, RGPD et AI Act

Un même événement peut déclencher quatre notifications, vers quatre destinataires, sur quatre définitions de l’incident. La frise se lit de haut en bas, depuis la prise de connaissance ; les crochets donnent la condition de déclenchement de chaque texte.

CSIRT désigne le Computer Security Incident Response Team, ENISA l’Agence de l’Union européenne pour la cybersécurité (fiche ENISA). Le règlement délégué (UE) 2026/881 précise quand le CSIRT destinataire peut retarder la diffusion d’une notification CRA.

Deux pièges d’interprétation. D’abord, l’article 73 §9 de l’AI Act limite la notification aux seuls incidents du point 49 c) (droits fondamentaux) pour les systèmes de l’annexe III dont le fournisseur est soumis à des obligations de signalement équivalentes ; l’article 73 §10 fait de même pour les dispositifs médicaux. Que NIS 2 ou le CRA vaillent « équivalent » au sens du §9 n’est pas tranché par le texte : prudence, la page ne le présume pas. Ensuite, la proposition « données et cybersécurité » de l’omnibus numérique (Commission, 19 novembre 2025) prévoit un point d’entrée unique opéré par l’ENISA pour NIS 2, le RGPD et DORA (Digital Operational Resilience Act) notamment ; elle est encore en négociation (à vérifier sur EUR-Lex). Même adoptée, elle mutualiserait le guichet, pas les critères : chaque texte garderait sa définition de l’incident. Comparaison des délais NIS 2, RGPD et DORA dans la page dédiée aux notifications.

Recommandation de la page : une seule procédure de qualification, déclenchée à T0, qui évalue en parallèle les quatre critères et produit quatre décisions tracées, y compris les décisions de non-notification. Le chronomètre le plus court (24 h) fixe le rythme de toute la cellule de crise.

Sanctions. AI Act art. 99 : 35 M€ ou 7 % du CA (chiffre d’affaires) mondial pour l’article 5, 15 M€ ou 3 % pour la plupart des autres obligations, 7,5 M€ ou 1 % pour informations inexactes, le plus élevé (le plus faible pour les PME, petites et moyennes entreprises). CRA art. 64 : 15 M€ ou 2,5 % (annexe I, art. 13 et 14), 10 M€ ou 2 %, 5 M€ ou 1 %, le plus élevé. NIS 2 art. 34 : maxima d’au moins 10 M€ ou 2 % (essentielles), 7 M€ ou 1,4 % (importantes). RGPD art. 83 : 10 M€ ou 2 %, 20 M€ ou 4 %, le plus élevé. Ces plafonds ne s’additionnent pas mécaniquement : le principe non bis in idem et la coordination des autorités jouent. Le cumul reste possible pour des manquements distincts, et le montant total ne se chiffre pas d’avance.

Dossier de preuve mutualisé entre AI Act, CRA, NIS 2 et RGPD

Le compromis central tient en une ligne : mutualiser fait gagner un seul jeu de preuves cohérent, et coûte une gouvernance commune avec un référentiel d’exigences croisées à maintenir. Recommandation de la page : mutualiser dès que deux textes s’appliquent au même périmètre technique, à condition qu’un propriétaire unique tienne le référentiel. Sans propriétaire, le dossier commun devient le dossier de personne.

Le schéma montre quatre artefacts produits une fois, chacun consommé par plusieurs textes.

Les conditions d’exploitation font la différence entre un dossier et une archive. Chaque artefact porte un identifiant de version du modèle et du produit : une présomption CRA ou Cybersecurity Act ne vaut que pour la version couverte. Les journaux de l’article 12 contiennent souvent des données personnelles (entrées, sorties) : leur conservation se justifie au titre du RGPD, avec durée et contrôle d’accès définis ; une rétention « au cas où » méconnaît la limitation de la conservation (article 5 §1 e) du RGPD) au moment même où elle sert l’AI Act. Les journaux doivent être protégés en intégrité (stockage en écriture unique ou chaînage cryptographique) et sauvegardés hors du périmètre d’exploitation, sinon l’attaquant qui compromet le système efface aussi la preuve. La supervision doit couvrir les signaux propres à l’IA (dérive de performance, volume anormal de requêtes sur l’API d’inférence), pas seulement les alertes système classiques. Voir journalisation et ce qu’un auditeur vérifie.

Surface d’attaque du dispositif lui-même. Le dossier mutualisé concentre l’architecture, les faiblesses connues et les procédures de crise : c’est la cible de reconnaissance idéale. Accès restreint par besoin d’en connaître, journalisation des consultations, et pas de copie intégrale dans les espaces partagés des quatre équipes. Le classeur de conformité qui traîne sur un partage ouvert reste le seul document à la fois exhaustif et consultable sans authentification.

Exemple fictif : logiciel de tri de candidatures, éditeur et aéroport

Scénario fictif, situé après le 11 décembre 2027 (haut risque de l’annexe III applicable depuis le 2 décembre 2027, CRA pleinement applicable). Un éditeur européen de taille moyenne vend un logiciel de tri de candidatures (annexe III point 4, emploi : haut risque), installé chez le client avec une composante en nuage indispensable au scoring. Il exploite aussi une offre SaaS du même modèle. Un gestionnaire d’aéroport, entité essentielle au titre de NIS 2, déploie la version installée.

Éditeur. Fournisseur AI Act pour les deux offres. Fabricant CRA pour la version installée, backend compris (solution de traitement à distance au sens de l’art. 3 point 2) ; il peut donc s’appuyer sur l’article 12 du CRA pour la cybersécurité de l’article 15, mais doit démontrer exactitude, robustesse et résistance aux attaques de l’article 15 §5 au titre de l’AI Act. Annexe III point 4 : contrôle interne (annexe VI) côté AI Act ; dans ce scénario, le logiciel n’entre pas dans les catégories des annexes III et IV du CRA, donc l’exception de l’art. 12 §3 ne joue pas. Pas de CRA pour l’offre purement SaaS ; NIS 2 possible comme fournisseur d’informatique en nuage de taille moyenne. Sous-traitant RGPD, encadré par contrat (DPA fournisseur IA).

Aéroport. Déployeur AI Act (art. 26, voir obligations du déployeur) ; entité NIS 2 (art. 21 et 23) ; responsable de traitement RGPD, avec AIPD et, s’il est un organisme de droit public ou une entité privée fournissant un service public, FRIA (art. 27 §1), rédigées en un document commun. L’article 22 du RGPD impose de vérifier qu’aucun rejet de candidature ne repose exclusivement sur le score automatique.

Incident. Une vulnérabilité activement exploitée du composant installé permet d’exfiltrer les poids du modèle et des extraits de CV. Le schéma déroule qui notifie qui.

Lecture du scénario. Les poids exfiltrés sont plus qu’un actif de propriété intellectuelle : un modèle entraîné sur des CV peut en mémoriser des fragments, ce qui en fait potentiellement un support de données personnelles et alimente la qualification RGPD. La notification AI Act n’est pas automatique : elle dépend de la qualification en violation d’obligations protégeant les droits fondamentaux (point 49 c). Si elle est retenue, l’article 73 §9 ne change rien ici, puisqu’il préserve précisément les incidents du point c). L’éditeur a deux casquettes et deux chronomètres (CRA et AI Act), l’aéroport trois (NIS 2, RGPD, information du fournisseur). Correctif CRA, retrait de l’artefact compromis, réévaluation de l’article 15 §5 (un modèle volé permet de préparer hors ligne des exemples contradictoires contre la version en production) : tout cela entre ensuite dans le registre commun.

🐝 Ce qui arrive si on s’en passe

Sans cartographie croisée, la présomption de l’article 12 du CRA est revendiquée pour l’offre SaaS qui n’y a pas droit, et l’article 15 reste sans démonstration. Sans procédure de qualification unique, chaque équipe ouvre son propre chronomètre : le délai de 24 heures du CRA ou de NIS 2 expire pendant que la qualification RGPD est encore en discussion. Sans journaux versionnés et protégés en intégrité, l’origine d’une dérive ou d’une extraction de modèle devient impossible à reconstituer, et le rapport final se rédige sans faits. Sans test adversarial, l’empoisonnement passe sous chaque déclaration de conformité, puisqu’aucune ne le couvre.

🦫 Explication de la marmotte 🍫

Quatre lois européennes peuvent viser le même logiciel d’intelligence artificielle. La première, sur l’intelligence artificielle, contrôle le programme qui prend des décisions. La deuxième, sur la cyberrésilience, contrôle les produits numériques vendus en Europe. La troisième, appelée NIS 2, contrôle les organisations qui font tourner des services essentiels, comme un aéroport. La quatrième, le règlement sur les données personnelles, contrôle tout usage d’informations sur des personnes. Chaque loi s’allume selon ce que l’on fabrique ou ce que l’on fait. Un logiciel installé chez le client entre dans la loi sur les produits ; le même logiciel loué seulement en ligne n’y entre pas. Certaines lois se reconnaissent entre elles : respecter la loi sur les produits compte comme respecter la partie sécurité informatique de la loi sur l’intelligence artificielle, mais pas la partie sur la justesse des résultats. D’autres règles ne sont écrites que dans une seule loi, par exemple la protection contre des données d’apprentissage volontairement faussées. Quand une attaque arrive, chaque loi a son propre délai pour prévenir les autorités : un jour, trois jours, quinze jours, un mois. Si personne ne vérifie les quatre en même temps, un délai passe sans déclaration. Pour éviter de tout refaire quatre fois, on garde une seule étude des risques, une seule liste des failles, un seul historique des événements et une seule procédure d’alerte, et chaque loi y puise ce qu’elle demande.

À lire aussi

• AI Act : champ d'application, qui est concerné et qui en sort (article 2)Lecture de l'article 2 du règlement (UE) 2024/1689, de la territorialité aux exclusions défense, recherche et logiciel libre, avec la condition qui fait tomber chacune.
• AI Act : sanctions, plafonds d'amende et critères de calcul (articles 99 à 101)Ce que les articles 99 à 101 de l'AI Act fixent en matière de sanctions (plafonds d'amende, critères de calcul, autorités compétentes) et ce qu'ils laissent aux États membres.
• AI Act : réclamation et droit à l'explication (articles 85 et 86)Ce que les articles 85 et 86 du règlement (UE) 2024/1689 ouvrent aux personnes face à une IA, réclamation et droit à l'explication, et ce que le déployeur doit journaliser pour y répondre.
• AI Act : documentation technique d'une IA à haut risque (article 11, annexe IV)Ce que l'article 11 et l'annexe IV du règlement (UE) 2024/1689 imposent au fournisseur d'un système d'IA à haut risque en matière de documentation technique, et comment la produire et l'exploiter sans qu'elle se périme.

Pages voisines

La citent

• AI Act : champ d'application, qui est concerné et qui en sort (article 2)
• AI Act : mandataire, importateur et distributeur d'une IA à haut risque (articles 22 à 24)

AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPD

Elle cite

• ⇄Lien dans les deux sens :AI Act : bacs à sable réglementaires et mesures PME (art. 57 à 63)
• ⇄Lien dans les deux sens :AI Act : analyse d'impact sur les droits fondamentaux (article 27)
• AI Act : calendrier d'application 2025-2030 et ce qui s'applique déjà
• AI Act : classer un système d'IA à haut risque (article 6, annexes I et III)
• AI Act : fournisseur, déployeur, importateur et requalification en fournisseur
• AI Act : contrôle humain d'une IA à haut risque (article 14)
• AI Act : évaluation de la conformité, déclaration UE et marquage CE d'une IA à haut risque (articles 17, 43 et 49)
• AI Act : exactitude, robustesse et cybersécurité d'une IA à haut risque (article 15)
• AI Act : gouvernance des données d'entraînement (article 10)
• AI Act : journalisation automatique d'une IA à haut risque (articles 12, 19 et 26)

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