RSSI et AI Act : cybersécurité des systèmes IA Article 15 en pratique

L'essentiel en 30 secondes

  • L'Article 15 du Règlement (UE) 2024/1689 impose des exigences de robustesse, d'exactitude et de cybersécurité aux fournisseurs de systèmes d'IA à haut risque.
  • Le RSSI pilote l'évaluation des risques, la sélection des contre-mesures et la traçabilité des incidents tout au long du cycle de vie du système.
  • Les attaques spécifiques à l'IA (data poisoning, model evasion, model inversion, prompt injection) doivent être traitées par des mesures techniques documentées.
  • Les sanctions pour manquement aux obligations applicables aux systèmes à haut risque peuvent atteindre 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial (Art. 99 §4).
  • La CNIL et l'ANSSI fournissent des référentiels opérationnels mobilisables dès aujourd'hui pour structurer la démarche.
  • Un audit interne tous les douze à vingt-quatre mois reste la fréquence recommandée par les guides Cigref et Numeum [à vérifier].

1. Pourquoi la cybersécurité des systèmes d'IA devient un sujet RSSI

L'EU AI Act entre en application progressive depuis le 1er août 2024. Les obligations pour les systèmes à haut risque s'appliqueront pleinement à compter du 2 août 2026 (Article 113 du Règlement (UE) 2024/1689). Pour les PME françaises qui déploient ou intègrent des systèmes d'IA, ce calendrier impose d'anticiper.

Le RSSI hérite d'un périmètre élargi. Les systèmes d'IA introduisent des surfaces d'attaque inédites : empoisonnement des données d'entraînement, manipulation des entrées de production, vol de modèle, contournement par adversarial inputs. Ces menaces ne sont pas couvertes par les contrôles ISO 27001 classiques.

Les PME sont particulièrement exposées. Elles intègrent souvent des modèles tiers (API LLM, vision par ordinateur, scoring) sans disposer d'équipes MLOps dédiées. La responsabilité juridique reste pourtant entière dès lors que le système est qualifié à haut risque au sens de l'Annexe III du Règlement.

La logique de l'AI Act est claire : la cybersécurité n'est pas une option, c'est une exigence essentielle (« essential requirement ») au même titre que l'exactitude et la robustesse. Le non-respect engage la responsabilité du fournisseur, du déployeur, et dans certains cas du distributeur.

Pour cadrer l'ensemble de vos obligations, consultez notre guide complet AI Act pour les PME françaises.

2. Comprendre l'Article 15 de l'AI Act

L'Article 15 du Règlement (UE) 2024/1689 s'intitule « Accuracy, robustness and cybersecurity ». Il impose trois exigences cumulatives aux systèmes d'IA à haut risque tout au long de leur cycle de vie.

L'Art. 15 §1 énonce le principe : « Les systèmes d'IA à haut risque sont conçus et développés de manière à atteindre un niveau approprié d'exactitude, de robustesse et de cybersécurité, et à fonctionner de manière cohérente à ces égards tout au long de leur cycle de vie ».

L'Art. 15 §5 cible explicitement les attaques propres à l'IA : « Les solutions techniques visant à garantir la cybersécurité des systèmes d'IA à haut risque sont adaptées aux circonstances pertinentes et aux risques ». Le texte cite expressément les mesures contre le data poisoning, le model poisoning, l'adversarial examples, le model evasion et les attaques de confidentialité.

Qu'est-ce qu'un système d'IA à haut risque ?

Un système est qualifié à haut risque dans deux cas (Article 6) :

  • Il constitue un composant de sécurité d'un produit déjà soumis à une législation harmonisée listée en Annexe I (dispositifs médicaux, machines, jouets, etc.).
  • Il relève d'un des huit domaines de l'Annexe III : biométrie, infrastructures critiques, éducation, emploi, services essentiels publics et privés, application de la loi, migration, justice et processus démocratiques.

Quelques exemples typiques pour une PME :

Cas d'usage Qualification Base légale
Logiciel RH de tri de CV Haut risque Annexe III §4(a)
Système de scoring crédit Haut risque Annexe III §5(b)
Reconnaissance faciale en entreprise Haut risque Annexe III §1(a)
Chatbot commercial sans décision automatisée Risque limité Art. 50 (transparence)
Outil d'analyse marketing interne Risque minimal Hors champ

Consultez notre glossaire AI Act pour clarifier les notions de fournisseur, déployeur et système à haut risque.

3. Les obligations concrètes posées par l'Article 15

L'Art. 15 se décompose en obligations techniques et organisationnelles que le RSSI doit traduire en mesures opérationnelles.

Obligations d'exactitude

Les niveaux d'exactitude et les métriques pertinentes doivent être déclarés dans la notice d'utilisation (Art. 15 §3). Le fournisseur choisit les indicateurs : précision, rappel, F1-score, taux de faux positifs, selon la nature du système. Ces métriques doivent être mesurables, stables et documentées.

Obligations de robustesse

Le système doit résister aux erreurs, défaillances et incohérences. L'Art. 15 §4 impose des « solutions techniques et organisationnelles » comme la redondance, les sauvegardes, les plans de continuité. Les systèmes d'apprentissage continu doivent gérer le risque de boucles de rétroaction biaisées (« feedback loops »).

Obligations de cybersécurité

L'Art. 15 §5 distingue les attaques génériques (intégrité, disponibilité, confidentialité) et les attaques spécifiques à l'IA :

Type d'attaque Description Mesure type
Data poisoning Manipulation du jeu d'entraînement Validation des sources, signature des datasets
Model poisoning Manipulation des poids du modèle Contrôle d'intégrité, signature des artefacts
Adversarial examples Entrées conçues pour tromper Adversarial training, détection d'anomalies
Model evasion Contournement des classificateurs Tests red team, monitoring runtime
Model inversion Reconstruction des données d'entraînement Differential privacy, contrôle d'accès
Confidentiality attacks Extraction du modèle ou des données Rate limiting, watermarking
Prompt injection (LLM) Manipulation des consignes Filtrage entrées/sorties, sandboxing

Audit et réévaluation

Le Règlement n'impose pas explicitement un audit biennal dans l'Art. 15. En revanche, le système de gestion des risques de l'Article 9 impose une mise à jour « systématique, planifiée et continue ». Les guides Cigref (janvier 2025) et Numeum (mars 2025) recommandent une revue annuelle a minima, et un audit externe tous les 24 mois pour les systèmes à haut risque [à vérifier].

Pack documentaire RSSI : conforme Article 15 en 14 jours

Politique de cybersécurité IA, registre des risques, modèle de plan d'audit, matrice RACI RSSI/DPO/IA Lead. Templates Word et Excel directement exploitables, alignés sur ISO/IEC 42001 et l'AI Act.

Demander le pack RSSI

4. Le rôle du RSSI dans la mise en œuvre

Le RSSI n'est pas désigné nommément dans l'AI Act. Le Règlement parle de « provider » (fournisseur) et de « deployer » (déployeur). Dans la pratique organisationnelle française, le RSSI porte l'essentiel des obligations techniques de l'Art. 15.

Périmètre de responsabilité du RSSI

Le RSSI couvre quatre missions structurantes :

  1. Évaluer les risques cyber spécifiques à l'IA au sein du système de gestion des risques de l'Art. 9.
  2. Sélectionner et mettre en œuvre les contre-mesures techniques et organisationnelles proportionnées.
  3. Superviser les tests d'intrusion, de robustesse adversariale et de continuité.
  4. Documenter et reporter les incidents au déployeur, au fournisseur et, en cas d'incident grave, à l'autorité de surveillance (Art. 73).

Matrice de responsabilités RSSI / DPO / IA Lead

Domaine RSSI DPO IA Lead
Évaluation risques cyber IA R C C
Conformité RGPD du traitement C R C
Choix du modèle et du fournisseur C C R
Tests adversariaux R I C
Documentation technique Art. 11 C I R
Notification incident grave Art. 73 R C C
Formation utilisateurs Art. 4 C C R

R = Responsable, C = Consulté, I = Informé.

Articulation avec la direction générale

Le RSSI doit obtenir un mandat explicite. Le système de gestion des risques de l'Art. 9 et le système de gestion de la qualité de l'Art. 17 impliquent une décision au niveau de la direction. Sans sponsor exécutif, l'application opérationnelle de l'Art. 15 reste partielle.

5. Étapes pratiques pour sécuriser un système d'IA à haut risque

Voici une démarche en sept étapes, applicable à une PME qui déploie ou fournit un système d'IA à haut risque.

Étape 1 — Inventaire et qualification

Lister tous les systèmes d'IA en production et en projet. Pour chacun, déterminer la qualification AI Act : interdit (Art. 5), haut risque (Art. 6), risque limité (Art. 50), risque minimal. La qualification détermine le périmètre exact des obligations Art. 15.

Étape 2 — Analyse de risques cyber

Conduire une analyse de risques selon ISO/IEC 23894:2023 ou EBIOS RM adaptée à l'IA. Identifier les actifs (modèle, dataset, pipeline d'inférence, API), les menaces spécifiques (cf. table § 3), les vulnérabilités et les impacts.

Étape 3 — Définition des mesures

Élaborer un plan de traitement des risques. Pour chaque risque jugé inacceptable, choisir une mesure technique ou organisationnelle. Documenter le résiduel et la justification du choix.

Étape 4 — Implémentation des contrôles techniques

Mettre en œuvre :

  • Chiffrement au repos et en transit des datasets et modèles.
  • Contrôle d'accès basé sur les rôles (RBAC) pour les pipelines MLOps.
  • Signature numérique des artefacts (modèles, datasets, configurations).
  • Monitoring runtime des prédictions (drift, anomalies, taux de rejet).
  • Journalisation horodatée conforme à l'Art. 12 (« automatic logging »).

Étape 5 — Tests de sécurité IA

Programmer des tests adversariaux :

  • Tests de robustesse aux perturbations (FGSM, PGD).
  • Tests de poisoning sur un environnement de pré-production.
  • Red teaming spécifique aux LLM si applicable (jailbreak, prompt injection).
  • Tests de fuite de données d'entraînement (membership inference).

Étape 6 — Formation et sensibilisation

L'Article 4 du Règlement impose la « AI literacy » aux personnels concernés depuis le 2 février 2025. Le RSSI organise des formations spécifiques sur les menaces IA pour les équipes Data, Dev, Produit et Support.

Étape 7 — Plan de réponse aux incidents

Définir le processus de notification d'incident grave. L'Art. 73 §2 impose une notification à l'autorité de surveillance « immédiatement après que le fournisseur a établi un lien de causalité, et au plus tard 15 jours après en avoir eu connaissance ». Le RSSI doit pouvoir déclencher cette chaîne sans délai.

6. Exemples concrets de mesures pour PME

Les PME disposent rarement des moyens d'une grande entreprise. Voici une sélection de mesures pragmatiques, ordonnées par rapport coût/efficacité.

Mesures à coût maîtrisé

Mesure Effort Bénéfice cybersécurité
Chiffrement TLS 1.3 des appels API Faible Confidentialité en transit
Rotation des clés API tous les 90 jours Faible Limite l'impact d'un vol
Rate limiting sur les endpoints d'inférence Faible Frein aux attaques d'extraction
Validation stricte des entrées utilisateur Moyen Réduit le prompt injection
Journalisation centralisée (SIEM) des appels modèle Moyen Détection et traçabilité Art. 12
Signature SHA-256 des modèles déployés Faible Intégrité du modèle en production
MFA sur tous les comptes MLOps Faible Réduit le risque de compromission
Sauvegardes datasets versionnées (DVC, LakeFS) Moyen Restauration après poisoning

Mesures spécifiques aux LLM

Pour les PME qui intègrent un LLM commercial via API :

  • Filtrer les entrées avec une liste de patterns sensibles avant envoi.
  • Filtrer les sorties pour détecter les fuites PII et les injections.
  • Imposer un schéma de réponse strict (JSON Schema, function calling).
  • Limiter le contexte transmis au strict nécessaire (data minimization).
  • Désactiver l'historique de conversation côté fournisseur si possible contractuellement.

Choix des fournisseurs cloud

Privilégier les fournisseurs qui s'engagent contractuellement sur :

  • La non-utilisation des données client pour le réentraînement.
  • La localisation européenne des données et du traitement.
  • Les certifications ISO 27001, SOC 2 Type II, SecNumCloud le cas échéant.
  • La traçabilité des incidents et des changements de modèle.

7. Conséquences d'une non-conformité à l'Article 15

Le régime de sanctions est fixé à l'Article 99 du Règlement, et non à l'Article 83 comme parfois indiqué dans les supports antérieurs au texte final.

Barème des sanctions Art. 99

Manquement Plafond entreprise Plafond PME et start-up
Pratiques interdites (Art. 5) 35 M€ ou 7 % du CA mondial Le plus élevé des deux
Manquements aux obligations Art. 8 à 25 (incluant Art. 15) 15 M€ ou 3 % du CA mondial Le plus bas des deux
Information inexacte aux autorités 7,5 M€ ou 1 % du CA mondial Le plus bas des deux

L'Art. 99 §6 prévoit que pour les PME et start-up, l'amende correspond au plus bas des deux plafonds, et non au plus élevé. Cette spécificité est essentielle pour calibrer le risque financier d'une PME.

Pour une analyse détaillée du régime de sanctions, voyez notre article dédié aux sanctions AI Act pour PME avec calculateur.

Risques opérationnels et réputationnels

Au-delà de l'amende, un manquement à l'Art. 15 expose à :

  • L'obligation de retirer le système du marché (Art. 79).
  • L'interdiction temporaire ou définitive de mise à disposition.
  • Des actions en responsabilité civile sur le fondement du droit commun et, à terme, de la directive sur la responsabilité IA [à vérifier].
  • Une perte de confiance auprès des clients, partenaires et investisseurs.
  • L'exclusion possible de marchés publics et de référentiels sectoriels.

Exemple chiffré pour une PME

Une PME de 80 salariés et 18 M€ de chiffre d'affaires qui déploie un système RH à haut risque non conforme à l'Art. 15 s'expose à une sanction maximale de 3 % × 18 M€ = 540 000 €. La sanction réelle reste à la discrétion de l'autorité, qui apprécie la gravité, la durée et la coopération (Art. 99 §7).

Évaluez votre exposition Article 15 en 20 minutes

Notre questionnaire de diagnostic vous oriente vers les actions prioritaires : qualification du système, écarts vis-à-vis des exigences cyber, plan d'action chiffré. Réponse personnalisée sous 48 h.

Lancer le diagnostic

8. Outils et ressources pour structurer la démarche

Plusieurs ressources publiques et normatives permettent aux PME de bâtir un programme Art. 15 sans repartir d'une feuille blanche.

Référentiels normatifs

Norme Apport pour l'Art. 15
ISO/IEC 42001:2023 Système de management de l'IA (AIMS) — cadre global
ISO/IEC 23894:2023 Gestion des risques liés à l'IA
ISO/IEC 27001:2022 Sécurité de l'information — socle SMSI
ISO/IEC 27701 Extension vie privée — articulation RGPD
ETSI TR 104 032 Sécurité de l'IA — guide technique [à vérifier]
NIST AI RMF 1.0 Référentiel américain complémentaire

Ressources françaises

  • Les 13 fiches pratiques de la CNIL sur l'IA, dont celles consacrées à la sécurité des systèmes et à l'évaluation des risques.
  • Les recommandations de l'ANSSI sur la sécurité de l'IA générative (publications 2024).
  • Le guide Cigref « AI Act, ce qu'il faut savoir » de janvier 2025.
  • Le guide Numeum « Mettre en œuvre l'AI Act » de mars 2025.
  • L'AI Act Service Desk de la Commission européenne pour les questions d'interprétation.

Outils open source utiles

Outil Usage
Adversarial Robustness Toolbox (IBM) Tests adversariaux Python
Foolbox Génération d'adversarial examples
ModelScan (Protect AI) Scan de modèles pour code malicieux
Garak Red teaming LLM
Giskard Tests de robustesse et de biais
MLflow Traçabilité expérimentations et modèles

Notre page sources officielles recense l'ensemble des textes et guides référencés.

FAQ

Quels systèmes d'IA à haut risque sont concernés par l'Article 15 ?

Tous les systèmes qualifiés à haut risque au sens de l'Article 6 du Règlement (UE) 2024/1689. Cela inclut les composants de sécurité couverts par l'Annexe I et les huit catégories de l'Annexe III : biométrie, infrastructures critiques, éducation, emploi, services publics et privés essentiels, application de la loi, migration et asile, justice et processus démocratiques. Une PME qui utilise un logiciel de tri de CV, un système de scoring crédit ou de la reconnaissance biométrique relève de ce périmètre.

Quelle est la fréquence d'audit requise par l'Article 15 ?

L'Art. 15 lui-même n'impose pas de fréquence d'audit chiffrée. L'obligation découle de l'Article 9 (gestion des risques continue) et de l'Article 17 (système de gestion de la qualité). En pratique, les guides Cigref et Numeum recommandent une revue interne annuelle des mesures de cybersécurité et un audit indépendant tous les 24 mois pour les systèmes à haut risque [à vérifier]. Les certifications ISO/IEC 42001 et 27001 retiennent un cycle de surveillance annuel.

Quelles sont les sanctions exactes prévues en cas de manquement ?

Le manquement à l'Art. 15 relève de l'Art. 99 §4 du Règlement. Le plafond est de 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial. Pour les PME et start-up, l'Art. 99 §6 retient le plus bas des deux montants. Le manquement concerne les obligations applicables aux fournisseurs (Art. 16) et aux déployeurs (Art. 26) de systèmes à haut risque, qui renvoient toutes deux aux exigences de l'Art. 15.

Le RSSI peut-il déléguer ses obligations à un prestataire externe ?

Le RSSI peut s'appuyer sur des prestataires pour l'exécution opérationnelle (audits, tests d'intrusion, MCO). La responsabilité organisationnelle reste interne à l'entreprise : c'est le fournisseur ou le déployeur, en tant que personne morale, qui répond du respect de l'Art. 15. La sous-traitance doit faire l'objet d'un contrat précisant les exigences, les livrables, les niveaux de service et la traçabilité, conformément aux principes du système de gestion de la qualité de l'Art. 17.

Que faire si le système d'IA repose sur un modèle tiers (LLM commercial) ?

L'intégration d'un modèle tiers ne décharge pas le déployeur de ses obligations. Le RSSI doit cartographier la chaîne de responsabilité, exiger du fournisseur les éléments de conformité Art. 15 (documentation technique, métriques de robustesse, mesures cyber) et ajouter ses propres contrôles au niveau de l'intégration : filtrage des entrées et sorties, surveillance, limitation de contexte. Les modèles d'IA à usage général sont par ailleurs soumis au régime spécifique des Articles 51 à 56.

Sources officielles

  • Règlement (UE) 2024/1689 du Parlement européen et du Conseil du 13 juin 2024eur-lex.europa.eu/eli/reg/2024/1689
  • Texte consolidé et navigable de l'AI Actartificialintelligenceact.eu
  • AI Act Service Desk de la Commission européenneai-act-service-desk.ec.europa.eu
  • Fiches pratiques IA de la CNILcnil.fr
  • ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system — iso.org
  • ISO/IEC 23894:2023 — Artificial intelligence — Guidance on risk management — iso.org
  • ISO/IEC 27001:2022 — Information security management systems — iso.org
  • Guide Cigref « AI Act, ce qu'il faut savoir » — janvier 2025
  • Guide Numeum « Mettre en œuvre l'AI Act » — mars 2025

Cet article fournit des informations générales sur l'EU AI Act applicables aux PME françaises. Il ne constitue pas un conseil juridique. Pour toute décision opérationnelle, faites valider votre démarche par votre DPO ou conseil juridique. regulia décline toute responsabilité quant à l'usage qui peut être fait de ces informations.

Outil gratuit · 2 minutes · sans inscription

Êtes-vous concerné ? Faites le diagnostic AI Act.

Sachez en 2 minutes si vos systèmes sont à haut risque, vos obligations et les documents à produire.

Démarrer le diagnostic → Ou voir un échantillon de document →