À jour au 18 octobre 2026. Cet article intègre le règlement « Omnibus numérique » sur l’IA publié le 24 juillet 2026. Il sera mis à jour au fil des lignes directrices de la Commission.
L’Union européenne a desserré le calendrier de l’AI Act pour les systèmes d’IA à haut risque. Une bonne nouvelle pour les organisations qui n’étaient pas prêtes, à condition de ne pas confondre report et pause : une partie du règlement s’applique déjà, et les exigences de sécurité des systèmes d’IA demandent du temps à mettre en place.
Un règlement déjà en vigueur, appliqué par étapes
Le règlement (UE) 2024/1689, dit AI Act, est entré en vigueur le 1er août 2024. Ses obligations s’appliquent progressivement :
- depuis le 2 février 2025 : interdiction des pratiques d’IA jugées inacceptables (notation sociale, manipulation, certaines formes d’identification biométrique…) et premières règles sur la maîtrise de l’IA par les équipes ;
- depuis le 2 août 2025 : obligations des fournisseurs de modèles d’IA à usage général, comme les grands modèles de langage ;
- depuis le 2 août 2026 : obligations de transparence de l’article 50, par exemple informer une personne qu’elle échange avec une IA, ou signaler les contenus générés ou manipulés par une IA.
Ce que change l’Omnibus numérique
Le règlement (UE) 2026/1744 du 8 juillet 2026, dit « Omnibus numérique sur l’IA », a été publié au Journal officiel de l’Union européenne le 24 juillet 2026. Il modifie l’AI Act sur plusieurs points :
- systèmes à haut risque de l’annexe III (recrutement, notation de crédit, éducation, accès à certains services essentiels…) : leurs obligations s’appliqueront à partir du 2 décembre 2027, au lieu du 2 août 2026 ;
- systèmes à haut risque intégrés à des produits réglementés (annexe I : dispositifs médicaux, machines…) : à partir du 2 août 2028, au lieu du 2 août 2027 ;
- marquage des contenus générés : les systèmes d’IA générative mis sur le marché avant le 2 août 2026 ont jusqu’au 2 décembre 2026 pour se conformer à l’obligation de marquage ;
- maîtrise de l’IA (article 4) : l’obligation est reformulée. Fournisseurs et déployeurs doivent prendre des mesures pour développer les compétences de leurs équipes, sans devoir garantir un niveau donné pour chaque personne ;
- allègements pour les PME et les petites entreprises de taille intermédiaire, notamment en matière de documentation technique.
Les obligations de transparence de l’article 50, elles, n’ont pas été repoussées.
Report ne veut pas dire pause : l’exigence de cybersécurité
L’article 15 de l’AI Act impose aux systèmes d’IA à haut risque d’atteindre un niveau approprié d’exactitude, de robustesse et de cybersécurité tout au long de leur cycle de vie. Ils doivent résister aux tentatives de tiers non autorisés d’exploiter leurs vulnérabilités pour en modifier l’usage, les résultats ou les performances.
Le texte cite explicitement des menaces propres à l’IA :
- l’empoisonnement des données d’entraînement ou de composants pré-entraînés ;
- les exemples contradictoires, conçus pour tromper le modèle ;
- les attaques contre la confidentialité des données et du modèle ;
- l’exploitation des défauts du modèle.
Ces protections ne s’improvisent pas en quelques semaines. Elles reposent sur des fondations que les équipes sécurité connaissent bien : inventaire des actifs, analyse de risques, contrôle des accès aux données et aux modèles, journalisation, supervision et réponse à incident. Les organisations soumises à NIS2 ont tout intérêt à traiter les deux sujets ensemble : un système d’IA utilisé dans un service essentiel fait aussi partie du système d’information à protéger.
Et l’IA dans le SOC ?
Les équipes sécurité utilisent de plus en plus l’IA : résumé et contextualisation des alertes, aide à la qualification, assistance à la réponse. Ces usages ne figurent pas, en tant que tels, parmi les domaines à haut risque de l’annexe III : le règlement précise même que les composants destinés uniquement à la cybersécurité ne sont pas des composants de sécurité des infrastructures critiques (considérant 55). Ils doivent pourtant être gouvernés :
- la confidentialité : les journaux de sécurité contiennent des données personnelles et sensibles. Où sont-elles envoyées, et qui y a accès ? Un modèle hébergé dans un environnement maîtrisé peut être préférable ;
- l’injection de requêtes : un modèle qui lit des journaux, des courriels ou des pages web peut recevoir des instructions malveillantes cachées dans ces contenus. Il faut les traiter comme des données non fiables ;
- le contrôle humain : l’IA propose, l’analyste décide. Les actions automatisées doivent rester encadrées par des playbooks validés ;
- la traçabilité : conserver les requêtes, les réponses et les décisions prises permet d’auditer l’outil et d’en mesurer la fiabilité.
Par où commencer
- Inventorier vos systèmes et usages d’IA, y compris ceux intégrés à vos outils SaaS et ceux adoptés sans validation par les équipes.
- Classer chaque usage (pratique interdite, haut risque, obligation de transparence, risque minimal) et identifier votre rôle : fournisseur ou déployeur.
- Vérifier les obligations déjà applicables : pratiques interdites, transparence de l’article 50, compétences des équipes.
- Lancer dès maintenant les chantiers longs pour les systèmes potentiellement à haut risque : gestion des risques, qualité des données, journalisation, contrôle humain et cybersécurité.
- Intégrer les menaces propres à l’IA dans votre analyse de risques et vos tests d’intrusion.
- Encadrer vos fournisseurs de modèles et de services d’IA : localisation des données, usage pour l’entraînement, notification des incidents.
- Formaliser une gouvernance : charte d’usage, référent IA, revue régulière des usages.