Quelles infrastructures sont concernées ?
L'annexe III (point 2) vise les systèmes d'IA utilisés comme composants de sécurité dans la gestion et l'exploitation de plusieurs infrastructures critiques :
- les infrastructures numériques critiques ;
- la gestion et l'exploitation du trafic routier ;
- la fourniture d'eau, de gaz, de chauffage et d'électricité.
Qu'est-ce qu'un « composant de sécurité » ?
La notion est centrale. Un composant de sécurité est un élément qui remplit une fonction de sécurité et dont la défaillance mettrait en danger la santé ou la sécurité des personnes ou des biens (article 3, point 14). Ce n'est donc pas tout usage d'IA dans une infrastructure qui est à haut risque, mais seulement celui qui assure une fonction de sécurité critique. Un outil d'analyse purement administratif n'entre pas dans cette catégorie ; un système régulant en temps réel la stabilité d'un réseau électrique, oui.
Quelles obligations pour les opérateurs ?
Un opérateur déployant un système d'IA à haut risque dans son infrastructure doit respecter les obligations du déployeur (article 26) : usage conforme à la notice, contrôle humain, surveillance, conservation des journaux. S'il développe lui-même le système, il assume aussi les exigences des articles 8 à 15, avec une attention particulière à la robustesse et à la cybersécurité (article 15) — vitales pour une infrastructure.
Comment cela s'articule-t-il avec NIS 2 et la résilience ?
Les opérateurs d'infrastructures critiques sont déjà soumis à des cadres exigeants : la directive NIS 2 (cybersécurité des entités essentielles et importantes) et la réglementation sur la résilience des entités critiques. L'AI Act s'y ajoute : ses exigences de robustesse et de cybersécurité (article 15) se combinent avec les obligations de gestion des risques cyber de NIS 2. L'enjeu est d'intégrer la conformité AI Act aux dispositifs de résilience existants, plutôt que de la traiter isolément.
| Cadre | Objet | Articulation avec l'AI Act |
|---|---|---|
| AI Act (annexe III, pt 2) | IA composant de sécurité d'infrastructure | Haut risque, art. 8-27 |
| NIS 2 | Cybersécurité des entités essentielles | Se combine avec l'art. 15 |
| Résilience des entités critiques | Continuité et résilience physique | Complémentaire |
Comment se préparer ?
- 01
Identifier les IA « composant de sécurité »
Distinguez, parmi vos usages d'IA, ceux qui assurent une fonction de sécurité critique — les seuls à haut risque.
- 02
Documenter la qualification
Justifiez, pour chaque système, son classement à haut risque ou son exclusion. La frontière est délicate et doit être tracée.
- 03
Renforcer robustesse et cybersécurité
Traitez l'article 15 en lien avec vos obligations NIS 2 : gestion des risques cyber, tests, résilience.
- 04
Intégrer aux dispositifs de résilience
Adossez la conformité AI Act à vos cadres existants (NIS 2, résilience) pour éviter les redondances.
Questions fréquentes
Tout usage d'IA dans une infrastructure critique est-il à haut risque ?
Non. Seuls les systèmes d'IA utilisés comme composants de sécurité — dont la défaillance mettrait en danger la sécurité — relèvent du haut risque (annexe III, pt 2). Les usages de gestion courante ou d'optimisation sans fonction de sécurité n'y sont pas soumis.
L'AI Act remplace-t-il NIS 2 ?
Non. Les deux cadres se cumulent. NIS 2 encadre la cybersécurité des entités essentielles et importantes ; l'AI Act ajoute ses exigences propres (robustesse, cybersécurité de l'IA à l'article 15). L'enjeu est de les articuler.
Qui est responsable : l'opérateur ou l'éditeur du système ?
L'éditeur (fournisseur) porte les exigences techniques des articles 8 à 15 ; l'opérateur (déployeur) répond des obligations de l'article 26. Un opérateur qui développe lui-même son système cumule les deux rôles.
La qualification « composant de sécurité » est-elle facile à établir ?
Pas toujours. Elle suppose d'apprécier si la défaillance du système met en danger la sécurité. Cette analyse, technique et contextuelle, doit être documentée avec soin, car elle détermine l'applicabilité du régime haut risque.