AI Act et cybersécurité : impacts sur les systèmes de détection

Azais Khalsi

L’AI Act modifie profondément la manière d’appréhender les outils de cybersécurité fondés sur l’intelligence artificielle, mais il faut éviter un contresens fréquent : le règlement ne classe pas automatiquement tous les outils de détection cyber — EDR, SIEM enrichis par l’IA, moteurs d’analyse comportementale, systèmes de détection d’anomalies — parmi les systèmes d’IA à haut risque. Le point de départ juridique est plus fin. Le règlement (UE) 2024/1689 établit une logique de classement par catégories de risque, avec un régime renforcé pour les systèmes interdits, les systèmes à haut risque, certains systèmes soumis à des obligations de transparence, et les modèles d’IA à usage général. Son calendrier d’application est progressif : entrée en vigueur le 1er août 2024, application complète au 2 août 2026, avec des exceptions et reports pour certaines catégories. (EUR-Lex)

Pour les acteurs de la cybersécurité, la première question n’est donc pas “utilisons-nous de l’IA ?”, mais “dans quelle catégorie juridique AI Act tombent nos outils ?”. Beaucoup d’outils cyber à base d’IA ne sont pas, en l’état, classés par défaut comme systèmes à haut risque au sens de l’article 6 et de l’annexe III. L’annexe III vise des usages précis, centrés surtout sur la biométrie, les infrastructures critiques dans certains emplois déterminés, l’éducation, l’emploi, l’accès à des services essentiels, l’application de la loi, la migration et la justice. Un EDR ou un SIEM utilisé pour détecter des comportements anormaux sur un réseau d’entreprise n’entre donc pas automatiquement dans cette liste du seul fait qu’il mobilise du machine learning ou de l’analyse comportementale. (EUR-Lex)

Il faut néanmoins introduire une nuance décisive. Un outil cyber à base d’IA peut relever du haut risque dans deux hypothèses principales. La première est celle où il constitue un composant de sécurité d’un produit ou système régi par une législation sectorielle de l’annexe I et soumis à une évaluation de conformité par un tiers. La seconde est celle où son usage concret le fait entrer dans une catégorie de l’annexe III. Autrement dit, la qualification ne dépend pas seulement de la technologie, mais du couple fonction + contexte d’usage + intégration réglementaire. Un moteur de détection embarqué dans un environnement de sûreté régulé n’est pas dans la même situation qu’un outil SOC interne déployé dans une entreprise classique. (EUR-Lex)

Pour un juriste ou un responsable conformité, cela conduit à une règle simple : EDR, SIEM et NDR “classiques” ne sont pas nécessairement haut risque, mais ils ne sont pas non plus hors champ. Ils peuvent être soumis à l’AI Act à plusieurs titres : soit comme systèmes d’IA ordinaires avec des obligations limitées, soit comme systèmes intégrant ou reposant sur des modèles d’IA à usage général, soit, dans certains cas, comme systèmes à haut risque si leur destination réglementaire ou leur contexte fonctionnel l’impose. Cette distinction est essentielle, car elle conditionne tout le régime de conformité applicable. (EUR-Lex)

L’impact le plus direct pour les outils cyber qualifiés de haut risque tient aux exigences substantielles du titre III. Le règlement impose alors un ensemble structuré d’obligations : système de gestion des risques, gouvernance des données, documentation technique, journalisation, transparence et information à l’utilisateur, supervision humaine, ainsi qu’exigences d’exactitude, de robustesse et de cybersécurité. Le point est particulièrement intéressant pour les systèmes de détection, car l’article 15 relie explicitement accuracy, robustness and cybersecurity. Pour un outil de détection cyber, cela signifie qu’il ne suffit pas d’être performant en laboratoire ; il faut pouvoir démontrer une stabilité suffisante dans le cycle de vie, une résistance aux erreurs et une protection contre les manipulations ou attaques visant le système lui-même. (EUR-Lex)

Cette articulation entre IA et cybersécurité est conceptuellement majeure. Les systèmes de détection fondés sur l’IA sont censés protéger l’organisation, mais l’AI Act rappelle qu’ils peuvent eux-mêmes devenir des surfaces d’attaque : empoisonnement de données, contournement adversarial, manipulation des entrées, dérive de modèle, altération des sorties, dégradation silencieuse des performances. Le règlement fait donc de la cybersécurité non seulement un objectif poursuivi par ces outils, mais aussi une exigence applicable à ces outils eux-mêmes lorsqu’ils entrent dans le régime renforcé. C’est un renversement important : l’outil de sécurité devient lui aussi objet de sécurité réglementée. (ClearAct)

En pratique, pour un EDR ou un SIEM à base d’IA, cela implique de pouvoir documenter au moins cinq dimensions. D’abord, la finalité exacte du système : détection d’anomalies, priorisation d’alertes, scoring d’incidents, corrélation, réponse assistée. Ensuite, la source et la qualité des données utilisées pour l’entraînement, le réglage ou le fonctionnement. Puis la métrologie de performance : faux positifs, faux négatifs, dérive, robustesse face aux environnements changeants. Il faut aussi définir les mécanismes de supervision humaine, c’est-à-dire la place laissée aux analystes SOC, au RSSI ou aux équipes de réponse à incident. Enfin, il faut traiter la sécurité du système d’IA lui-même, y compris sa résistance à l’évasion, à la manipulation et à l’empoisonnement. Ces exigences dérivent directement de la logique des articles applicables aux systèmes à haut risque. (EUR-Lex)

Pour les fournisseurs, le cœur de la conformité repose sur la distinction entre provider et deployer. Le fournisseur du système d’IA supporte l’essentiel des obligations de conception, de documentation et, le cas échéant, d’évaluation de conformité. L’organisation utilisatrice, elle, doit employer le système conformément à sa destination, assurer une supervision humaine appropriée et respecter les instructions fournies. Dans le champ cyber, cette distinction est capitale car beaucoup d’entreprises n’entraînent pas elles-mêmes leur moteur d’IA : elles déploient des solutions d’éditeurs, parfois enrichies de modèles tiers. Dès lors, l’analyse contractuelle devient centrale : qui est juridiquement “provider” du composant IA ? qui documente ? qui prouve la robustesse ? qui traite les incidents affectant le modèle ? (EUR-Lex)

Le sujet se complique encore lorsqu’un outil de cybersécurité incorpore un modèle d’IA à usage général. Depuis le 2 août 2025, les règles et obligations concernant les modèles GPAI sont devenues applicables, et la Commission a publié des lignes directrices à leur sujet. Cela signifie qu’un éditeur cyber qui bâtit une couche de détection, d’assistance à triage, de résumé d’alertes ou de réponse conversationnelle sur un modèle généraliste doit aussi regarder les obligations propres aux fournisseurs de GPAI, indépendamment de la qualification éventuelle du système final. L’enjeu n’est plus seulement le moteur de détection, mais la chaîne complète : modèle généraliste, adaptation, intégration produit, usage opérationnel. (Stratégie numérique européenne)

Cette hybridation est déjà visible dans les SOC modernes. Beaucoup de SIEM et de plateformes XDR n’utilisent plus seulement des modèles spécialisés de détection statistique ; ils intègrent désormais des composants génératifs pour résumer des événements, enrichir des incidents, proposer des requêtes, générer des playbooks, assister les analystes ou produire des explications. Juridiquement, cela signifie que la conformité AI Act ne doit pas être pensée seulement au niveau du “moteur principal”, mais à celui de l’architecture fonctionnelle complète. Un produit peut combiner plusieurs couches réglementaires : logique de détection classique, IA prédictive, composant GPAI, et parfois intégration dans un secteur fortement régulé. Cette lecture est une inférence juridique forte à partir de l’architecture du règlement et des lignes de la Commission sur les GPAI. (EUR-Lex)

Il faut aussi prêter attention au calendrier. Les interdictions et obligations de littératie IA s’appliquent depuis le 2 février 2025. Les règles de gouvernance et les obligations pour les GPAI sont applicables depuis le 2 août 2025. La Commission indique que l’application générale intervient au 2 août 2026, tandis que certaines catégories de systèmes à haut risque intégrés dans des produits réglementés bénéficient d’un délai plus long. Les outils de normalisation et de mise en œuvre continuent d’évoluer, et la Commission travaille encore à la standardisation, ce qui signifie que la conformité, surtout pour les cas frontières, devra être construite dans un environnement encore partiellement mouvant. (Stratégie numérique européenne)

Pour les responsables cyber, la conséquence immédiate n’est donc pas une panique réglementaire, mais un travail de cartographie. Il faut identifier quels outils utilisent véritablement de l’IA au sens du règlement, quels outils reposent sur un modèle GPAI, quels usages pourraient relever d’une catégorie à haut risque, et quelles preuves de conformité existent déjà. Beaucoup d’éditeurs sécurité disposent déjà d’éléments utiles — gouvernance produit, métriques de performance, journaux techniques, contrôle humain, sécurité logicielle — mais pas toujours sous la forme documentaire exigée par le règlement. Le défi est donc souvent moins l’invention de nouvelles mesures que la juridicisation et la traçabilité de pratiques techniques déjà existantes. Cette conclusion relève d’une inférence, mais elle est directement soutenue par la structure de conformité du règlement. (EUR-Lex)

Sur le plan opérationnel, un éditeur ou intégrateur cyber devrait au minimum mettre en place les chantiers suivants. D’abord, une qualification juridique du portefeuille : IA ou non, GPAI ou non, haut risque ou non. Ensuite, une documentation de l’usage prévu et des limites du système. Puis un dispositif de mesure continue de performance et de dérive. Il faut également prévoir une supervision humaine explicite, notamment pour les actions sensibles comme le blocage automatique, la priorisation d’incidents critiques ou la réponse orchestrée. Enfin, un chantier de sécurité spécifique du système d’IA lui-même doit être ouvert : intégrité des données, maîtrise du pipeline, résilience aux manipulations adversariales, journalisation des comportements anormaux du modèle. Ces axes découlent directement des exigences centrales du régime des systèmes à haut risque et de la logique GPAI. (EUR-Lex)

Il ne faut pas non plus isoler l’AI Act du reste du droit cyber européen. Même si ta demande vise ce règlement en particulier, son application pratique croisera souvent d’autres textes, notamment le cadre NIS2 pour la gouvernance du risque et, selon les produits, le Cyber Resilience Act pour la cybersécurité des produits comportant des éléments numériques. Sans confondre ces régimes, il faut voir qu’ils convergent vers une même exigence : démontrer qu’un système numérique critique est non seulement innovant, mais sûr, gouverné, traçable et résilient. Cette remarque est un prolongement analytique cohérent avec l’évolution récente du droit numérique européen. (Stratégie numérique européenne)

En définitive, l’impact de l’AI Act sur les systèmes de détection cyber peut se résumer ainsi. Premièrement, tous les EDR, SIEM et systèmes de détection fondés sur l’IA ne sont pas automatiquement “haut risque”. Deuxièmement, certains peuvent néanmoins le devenir selon leur intégration sectorielle ou leur usage. Troisièmement, même hors haut risque, l’intégration de modèles d’IA à usage général déclenche déjà des obligations spécifiques. Quatrièmement, la conformité ne se limite pas à la qualité algorithmique : elle impose une doctrine de gouvernance, de documentation, de supervision humaine et de cybersécurité du système d’IA lui-même. Le véritable effet du règlement est donc moins d’interdire les outils de détection fondés sur l’IA que de les faire entrer dans une ère de compliance technique démontrable. (EUR-Lex)