Selon Gartner, 78 % des organisations européennes ont déployé au moins un outil d'IA générative en production en 2025. Moins d'un tiers ont mis à jour leurs politiques de sécurité de l'information en conséquence. L'écart n'est pas anodin : NIS2 impose une gestion documentée des risques sur l'ensemble des systèmes d'information — et les outils IA y entrent de plein droit. Voici les trois vecteurs que les équipes GRC omettent systématiquement, et comment les adresser concrètement.
Le contexte réglementaire : NIS2 et l'IA, une intersection non encore cartographiée
La directive NIS2, transposée dans les droits nationaux européens depuis fin 2024, impose aux entités dans son périmètre une gestion documentée des risques liés aux systèmes d'information et aux réseaux. L'article 21 liste explicitement parmi les mesures requises la sécurité de la chaîne d'approvisionnement, la gestion des accès, et le contrôle des actifs logiciels utilisés dans les processus critiques.
L'IA générative entre dans ce périmètre à trois titres : comme outil utilisé par les collaborateurs (risque d'usage), comme composant de systèmes automatisés (risque d'intégration), et comme cible potentielle d'attaques adversariales (risque d'exploitation). Ces trois dimensions constituent autant de vecteurs de risque que les politiques de sécurité rédigées avant 2024 n'ont, structurellement, pas anticipés.
L'EU AI Act, entré en vigueur progressivement depuis 2025, crée une couche réglementaire complémentaire sur les systèmes à haut risque — mais ne remplace pas NIS2. Les deux textes se superposent : un système IA utilisé dans un processus de conformité ou de gestion des risques peut être soumis aux deux cadres simultanément. Cette intersection est encore rarement adressée dans les programmes GRC des organisations mid-market.
Vecteur 1 : la fuite de données via les prompts — le shadow AI sous NIS2
Le premier vecteur est le plus répandu et le moins documenté dans les registres de risques. Les collaborateurs utilisent des outils IA grand public — interfaces web de modèles de langage, assistants de rédaction, outils d'analyse de données — en y injectant des données internes : contrats clients, données RH, rapports d'audit, plans stratégiques.
Ces usages constituent des transferts de données hors du périmètre de sécurité de l'organisation. Sous NIS2, si ces données incluent des informations relatives à des systèmes critiques ou à des personnes physiques, leur exfiltration — intentionnelle ou non — peut constituer un incident de sécurité à notifier à l'autorité compétente dans les 24 heures pour l'alerte préliminaire, 72 heures pour le rapport intermédiaire.
L'erreur courante : considérer que le risque est nul si l'organisation n'a pas déployé de LLM en interne. Le shadow AI — l'usage non supervisé d'outils IA par les collaborateurs en dehors des politiques IT — est présent dans 61 % des organisations qui n'ont pas de politique IA formalisée, selon une étude IBM Security de 2025. La majorité de ces usages n'apparaissent dans aucun registre de risques.
L'action à mener : un inventaire des outils IA utilisés, supervisé ou non, suivi d'une politique d'usage acceptable qui distingue les données pouvant être soumises à des outils externes des données strictement confinées. Cette politique doit être opposable — documentée, communiquée et auditée — pour être valable dans le cadre d'un audit NIS2.
Vecteur 2 : les hallucinations dans les processus décisionnels réglementés
Le deuxième vecteur est plus subtil et potentiellement plus coûteux en termes de responsabilité. Les modèles de langage produisent des sorties incorrectes avec confiance — le phénomène d'hallucination est documenté et inhérent à l'architecture actuelle des LLMs. Ce n'est pas un bug corrigeable à court terme ; c'est une propriété statistique de ces systèmes.
Le risque devient critique quand des sorties IA sont intégrées sans validation humaine dans des processus décisionnels réglementés : rapports de conformité soumis au régulateur, analyses de risques utilisées pour prendre des décisions de couverture, évaluations de prestataires critiques sous l'article 21 NIS2, ou encore qualification d'incidents de sécurité.
Un exemple concret observé en 2025 : une équipe GRC d'un établissement financier mid-market utilise un assistant IA pour produire le rapport de gestion des risques ICT requis par DORA. Le rapport contient des références à des articles réglementaires incorrects et des métriques inventées. Le document est validé sans relecture approfondie et transmis à l'autorité compétente. Le risque réglementaire résultant est direct.
La réponse n'est pas d'interdire l'usage de l'IA dans ces processus — c'est de définir explicitement quels processus requièrent une validation humaine systématique avant toute sortie externe, et de documenter ce contrôle. NIS2 exige que les mesures de sécurité soient proportionnées au risque : l'absence de contrôle humain sur des sorties IA dans des processus réglementés constitue une mesure insuffisante.
Vecteur 3 : la surface d'attaque élargie par les agents IA et les intégrations API
Le troisième vecteur émerge avec les déploiements plus avancés : les agents IA dotés d'accès à des systèmes internes via des APIs, des connecteurs ou des outils d'automatisation. Ces agents peuvent lire des données, déclencher des actions, modifier des configurations — avec des niveaux d'accès souvent surdimensionnés par rapport à ce qu'ils utilisent effectivement.
Sous NIS2, la gestion des accès (article 21, alinéa i) impose de limiter les droits aux strictes nécessités opérationnelles. Un agent IA disposant d'un accès en lecture-écriture sur l'ensemble d'un système de gestion documentaire, alors qu'il n'a besoin que de lire des documents spécifiques, constitue une violation de ce principe — indépendamment du fait que l'agent soit un humain ou un système automatisé.
Par ailleurs, les agents IA peuvent être ciblés par des attaques par injection de prompt : un document malveillant injecté dans le contexte d'un agent peut modifier son comportement et l'amener à exfiltrer des données, contourner des contrôles, ou déclencher des actions non autorisées. Ces vecteurs d'attaque sont documentés par l'OWASP depuis 2024 dans le Top 10 LLM Security Risks, et leur exploitation en conditions réelles est en augmentation en 2025-2026.
L'action à mener est une revue des droits d'accès de tous les agents IA déployés, suivie d'une intégration de ces agents dans la cartographie des actifs critiques et dans les politiques de gestion des accès existantes. Cette revue n'est pas une tâche ponctuelle — elle doit être répétée à chaque évolution du système d'agent.
Évaluer votre exposition — trois questions opérationnelles
Avant d'engager un programme formel, trois questions permettent de situer votre exposition sans audit approfondi.
Disposez-vous d'un inventaire des outils IA utilisés dans votre organisation, incluant les usages non sanctionnés par la DSI ? Si cet inventaire n'existe pas, votre registre de risques NIS2 est structurellement incomplet.
Vos processus de conformité incluent-ils une validation humaine explicite sur toute sortie IA destinée à un usage externe ou réglementaire ? Si ce contrôle n'est pas documenté, il n'est pas auditablement présent.
Les agents IA déployés figurent-ils dans votre cartographie des actifs ICT et font-ils l'objet d'une revue des accès ? Si ces agents ne sont pas dans le périmètre de votre gestion des accès, votre surface d'attaque effective dépasse votre périmètre de contrôle déclaré.
Presidio intègre la cartographie des actifs ICT, la gestion des accès et la traçabilité des décisions dans un registre unique conforme NIS2 et DORA : contactez notre équipe pour un diagnostic de 30 minutes. Lire aussi : NIS2 — préparer votre audit de maturité en 90 jours.
Conclusion
L'IA générative crée trois vecteurs de risque nouveaux que NIS2 encadre explicitement mais que la plupart des programmes GRC n'ont pas encore intégrés : la fuite de données via les usages non supervisés, l'introduction d'erreurs non détectées dans des processus décisionnels réglementés, et l'élargissement de la surface d'attaque via des agents disposant d'accès surdimensionnés.
Les organisations qui progressent efficacement sur ces vecteurs traitent l'IA comme un actif ICT à part entière, soumis aux mêmes exigences de cartographie, de gestion des accès et de contrôle que tout autre composant critique. Ce n'est pas une contrainte supplémentaire — c'est la condition pour que les bénéfices opérationnels de l'IA ne se transforment pas en passif réglementaire.