L’AI Act est en réalité une loi sur la sécurité

L’AI Act est perçu par beaucoup comme un sujet d’éthique et de conformité, une question de transparence et de discrimination. Pour les équipes de sécurité, il représente autre chose : une loi avec des exigences de sécurité strictes. Quiconque exploite un système d’IA à haut risque doit le sécuriser de manière démontrable contre les manipulations. Et l’intelligence artificielle peut être attaquée par des voies que la sécurité informatique classique ne connaît pas.

Pourquoi l’AI Act est un sujet de sécurité

L’AI Act, règlement (UE) 2024/1689, classe les systèmes d’IA selon leur niveau de risque. Pour la catégorie des systèmes à haut risque, par exemple dans les infrastructures critiques, les ressources humaines ou l’octroi de crédit, des exigences strictes s’appliquent. Un élément central en est la sécurité. Le système doit atteindre un niveau adéquat de précision, de robustesse et de cybersécurité et le maintenir tout au long de son cycle de vie.

Cette exigence ne se suffit pas à elle-même. Elle est accompagnée d’une gestion des risques obligatoire, d’exigences en matière de qualité des données, d’une journalisation automatique des événements du système et d’une supervision humaine efficace. Dans l’ensemble, l’AI Act décrit ainsi un cadre de sécurité pour l’IA qui se lit comme un cahier des charges pour une équipe de sécurité, et non comme une simple directive éthique.

Pour la pratique, cela signifie : un système d’IA à haut risque qui se laisse facilement tromper ou manipuler ne remplit pas les exigences. La sécurité n’est pas un ajout volontaire, mais la condition pour pouvoir déployer le système.

Les nouvelles surfaces d’attaque

Les systèmes d’IA élargissent la surface d’attaque d’une entreprise avec des catégories d’attaques qui n’existent pas dans l’informatique classique. Dans le cas du Data Poisoning, les attaquants introduisent des données manipulées dans l’entraînement, afin que le modèle réagisse ensuite de manière incorrecte ou intentionnellement erronée. L’attaque ne se situe alors pas dans l’exploitation, mais dans la genèse du modèle.

Dans le cas des attaques adversariales, les entrées sont modifiées de telle sorte qu’un modèle les classe de manière erronée, sans qu’un humain ne remarque la manipulation. S’y ajoutent des tentatives pour extraire un modèle ou ses données d’entraînement. Pour les systèmes basés sur le langage, une manipulation ciblée via des entrées préparées menace. Tout cela vise la logique du modèle, et non une vulnérabilité logicielle classique.

C’est précisément là que réside le défi. Un pare-feu ou un correctif ne protège pas contre ces attaques. Il faut des mesures de protection adaptées au modèle et à sa chaîne de données, de la sécurisation des données d’entraînement au test contre la manipulation jusqu’à la surveillance du système en production.

Le calendrier et ses reports

L’AI Act entre en vigueur de manière échelonnée. Le 2 août 2026, la prochaine étape d’applicabilité prend effet. Le législateur européen a toutefois ajusté le calendrier à certains endroits au cours de l’année 2026, de sorte que certaines obligations pour les systèmes à haut risque s’appliquent plus tard que prévu initialement. Ceux qui se préparent devraient vérifier l’état actuel des délais au cas par cas, plutôt que de se fier à une date unique.

Sur le fond, les reports changent peu de chose. Les exigences de sécurité pour l’IA à haut risque restent en vigueur. La constitution des capacités nécessaires prend du temps. Un système d’IA robuste ne naît pas à la veille d’une échéance, mais au fil de mois de travail rigoureux sur les données, de tests et de sécurisation. Le report n’est donc pas un motif pour attendre, mais un délai supplémentaire.

Ce que les équipes de sécurité doivent faire maintenant

La première étape est la visibilité. De nombreuses organisations ne savent pas quels systèmes d’IA elles déploient, ni ceux introduits officiellement ni ceux utilisés en silence dans les départements. Sans un inventaire des applications d’IA, il n’est possible ni d’évaluer le risque ni d’effectuer le classement selon l’AI Act.

La deuxième étape est la sécurisation de la chaîne de données. Si les données d’entraînement manipulées constituent la plus grande brèche, l’origine et l’intégrité de ces données doivent être vérifiées et protégées. S’y ajoute le test ciblé des modèles contre les manipulations, un Red Teaming pour l’IA qui identifie les faiblesses avant qu’un attaquant ne le fasse.

La troisième étape concerne les fournisseurs. Celui qui acquiert des modèles d’IA ou des produits basés sur l’IA auprès de tiers doit évaluer leur sécurité et la garantir contractuellement. La responsabilité pour un système à haut risque ne s’arrête pas à la limite du fournisseur. Elle exige que le composant acheté réponde lui aussi aux exigences.

Interaction avec NIS2 et le CRA

L’AI Act ne se suffit pas à lui-même. Il complète la réglementation existante d’une perspective spécifique à l’IA. NIS2 oblige les opérateurs à sécuriser leur informatique, ce qui inclura à l’avenir également les systèmes d’IA utilisés. Le Cyber Resilience Act met les fabricants à contribution dont les produits peuvent contenir des composants d’IA.

Pour une équipe de sécurité, cela signifie penser les exigences ensemble. Un système d’IA peut être à la fois une partie de l’IT à protéger selon NIS2, un système à haut risque réglementé selon l’AI Act et un élément d’un produit selon le CRA. Celui qui sépare ces perspectives crée trois silos. Celui qui les relie sécurise le système une seule fois correctement.

Questions fréquentes

Chaque question est fermée. Un clic déverrouille la réponse.

L’AI Act exige-t-il vraiment la cybersécurité ?

Oui. Pour les systèmes d’IA à haut risque, l’AI Act prescrit explicitement un niveau adéquat de précision, de robustesse et de cybersécurité sur l’ensemble du cycle de vie. La sécurité est une condition pour le déploiement, et non un ajout facultatif.

Qu’est-ce qu’une attaque par Data Poisoning ?

Les attaquants introduisent des données manipulées dans l’entraînement d’un modèle afin qu’il réagisse ensuite de manière incorrecte ou intentionnellement erronée. L’attaque se situe dans la genèse du modèle, et non dans le fonctionnement courant. Les mesures de protection classiques ne permettent guère de la contrer.

À partir de quand l’AI Act s’applique-t-il aux systèmes à haut risque ?

L’AI Act entre en vigueur de manière échelonnée ; le 2 août 2026 marque la prochaine étape. Certaines parties du calendrier ont été ajustées en 2026, c’est pourquoi l’état actuel des délais doit être vérifié au cas par cas. Les exigences de sécurité elles-mêmes demeurent.

Un pare-feu protège-t-il contre les attaques sur l’IA ?

Seulement de manière limitée. Les attaques adversariales et le Data Poisoning visent la logique et la chaîne de données du modèle, et non une vulnérabilité logicielle classique. Il faut des mesures de protection adaptées au modèle lui-même.

Comment l’AI Act s’articule-t-il avec NIS2 et le CRA ?

L’AI Act complète les deux d’une perspective spécifique à l’IA. Un système d’IA peut être à la fois une IT à protéger selon NIS2, un système à haut risque réglementé selon l’AI Act et une partie d’un produit selon le CRA. Le mieux est de le sécuriser de manière intégrée une seule fois.

Les choix de la rédaction

À lireQuand un appel stoppe la production automobile

Plus du réseau MBF Media

MyBusinessFutureLa surveillance de l’IA en Allemagne a maintenant une adresse