AI ACT : Tout se joue dans le SOC, pas dans le dossier de conformité

L'essentiel de votre hack'tu AI ACT

- Le 2 août 2026 était gravé dans le marbre : l’AI Act n’est plus un sujet théorique, il devient désormais pratique.

- Le Digital Omnibus a transféré la responsabilité de l’AI Act du service de conformité à l’équipe de sécurité.

- Décryptage du nouveau paradigme avec David Racowski, consultant principal chez Orange Cyberdefense

Précédemment, dans Digital Omnibus

Digital Omnibus, ce projet de la Commission européenne, présenté le 19 novembre 2025, vise à simplifier et à fusionner le millefeuille réglementaire du droit numérique : guichet unique cyber, ajustement du RGPD, et AI Act.

Pour ce dernier, une date butoir pour toutes les organisations : le 2 août 2026.
Les obligations « haut risque » de l’Annexe III (recrutement, scoring, biométrie, services essentiels) s’appliqueront le 2 décembre 2027, celles de l’annexe I le 2 août 2028.

Concrètement :

• Depuis le 2 août 2026 : transparence de l’article 50 (chatbots, contenus générés), pouvoirs de contrôle et de sanction de l’AI Office sur les fournisseurs de modèles à usage général ;
• Au 2 décembre 2026 : fin du sursis sur le marquage technique des contenus de synthèse pour les systèmes déjà commercialisés ;
• Au 2 décembre 2027 : le corps des exigences haut risque, dont l’article 15 (robustesse, cybersécurité) et l’article 14 (supervision humaine) ;
• Au 11 décembre 2027 : application intégrale du Cyber Resilience Act, dont le signalement des vulnérabilités exploitées est effectif depuis le 11 septembre 2026.

Seize mois de sursis, c’est à peu près la durée d’un programme de mise sous supervision d’un parc d’IA. Or ce report a produit un effet pervers que l’on peut déjà observer : des projets repartent en production sans pilotage, ni outillage, au motif que « l’échéance a bougé ». Et pour un RSSI, l’échéance qui importe n’est pas celle du régulateur, mais celle du premier incident. Un modèle compromis dans un processus critique déclenche une notification NIS2 ou DORA immédiate, indépendamment du calendrier AI Act.

Avant d’envisager le « plan d’action » du RSSI, faisons un focus sur l’Article 15 et 14 de l’AI Act.

La robustesse : prouve-le si tu peux

L’article 15 de l’AI Act est le point crucial cyber du règlement : la robustesse doit se démontrer en production.

Dès lors, il impose aux systèmes à haut risque un niveau approprié d’exactitude, de robustesse et de cybersécurité, tout au long du cycle de vie. Il nomme par ailleurs, les vecteurs d’attaque propres à l’IA : manipulation du jeu de données d’entraînement (data poisoning), altération des composants pré-entraînés (model poisoning), entrées conçues pour induire le modèle en erreur (adversarial examples, model evasion), attaques en confidentialité, défauts intrinsèques du modèle.

« Prévenir, détecter, répondre, résoudre et contrôler »,un véritable lexique propre au SOC, non de gouvernance. C’est là que se situe le point de friction le plus coûteux du marché. La robustesse n’est pas un attribut qu’on décrit dans une documentation à l’instant T, c’est une caractéristique qui évolue dans le temps : un système déclaré robuste en janvier peut ne plus l’être en mars sans qu’une ligne de code ait été modifiée, parce que les données d’entrée et les composants tiers de la chaîne d’approvisionnement IA, eux, ont changé. 

L’article 15 impose donc de traiter le modèle comme un actif du SI :

• Les systèmes d’IA entrent dans le périmètre de détection du SOC, avec des règles dédiées ;
• Le modèle et ses dépendances entrent dans la cartographie et le SBOM (Software Bills of Materials)
• Les prompts, sorties et dérives de performance deviennent des sources de logs à collecter et à corréler ;
• Le REDTEAM s’étend au modèle : injection de prompt, extraction de données d’entraînement, contournement des garde-fous.

Vous ne passerez pas !

L’article 14 de l’AI Act impose que les systèmes à haut risque soient conçus pour être effectivement supervisés par des personnes physiques.

L’article 26 transfère la charge au déployeur (la majorité des entreprises françaises) : confier la supervision à des personnes compétentes, formées et dotées de l’autorité nécessaire, conserver les journaux, suspendre l’usage en cas d’anomalie. Le responsable n’est plus un acteur de gouvernance, mais celui qui tient les logs.

L’obligation de l’article 4 renforce la responsabilité du superviseur et induit « un niveau suffisant de connaissance en matière d’IA à leur personnel… »

La supervision humaine a donc transféré la responsabilité de l’acteur de gouvernance à celle du SOC (à défaut, CSIRT/ CERT interne).

Le mapping du RSSI, joker de la gouvernance.

L’AI Act arrive au moment où les chantiers réglementaires se mettent en place dans les organisations ; il serait tentant d’ouvrir un chantier AI Act indépendamment d’une mise en conformité NIS2, DORA ou CRA. Les exigences se recouvrent et les preuves sont mutualisables.

• L’Article 15 / NIS2 : gestion des risques, sécurité de la chaîne d’approvisionnement et traitement des incidents couvrent déjà l’essentiel du socle ; le delta porte sur les menaces propres au modèle IA implémenté par l’organisation.
• AI Act / DORA : dans la finance, les registres de prestataires TIC critiques et les tests de résilience sont le véhicule naturel pour intégrer les fournisseurs d’IA ;
• AI Act / CRA : l’IA embarquée dans un produit connecté relève des deux régimes, avec deux échéances à neuf jours d’intervalle en décembre 2027 !
• Socle commun : cartographie, journalisation, gestion des vulnérabilités, notification d’incident, exercices de crise.

La check-list du RSSI : 10 actions avant décembre 2027

• Recenser tous les systèmes d’IA en production et en projet, y compris l’IA fantôme (shadow AI) et les fonctions activées par défaut dans les outils SaaS ;
• Qualifier chaque système : rôle (fournisseur ou déployeur), niveau de risque, annexe applicable ;
• Nommer un responsable opérationnel par système, distinct du sponsor métier ;
• Intégrer modèles, jeux de données et dépendances IA à la CMDB (Configuration Management Data Base) et au SBOM
• Activer la journalisation des prompts, sorties et décisions, avec une durée de conservation conforme ;
• Créer des cas d’usage de détection dédiés : dérive de modèle, exfiltration par prompt, comportement anormal d’agent ;
• Étendre le programme de tests d’intrusion et de red teaming aux modèles et aux agents ;
• Contractualiser avec les fournisseurs d’IA les engagements de sécurité, de notification et d’auditabilité ;
• Former et sensibiliser les opérateurs de supervision aux modes de défaillance de l’IA, et documenter cette formation ;
• Rejouer un exercice de crise sur un scénario IA : empoisonnement de données, agent compromis, sortie manipulée.

Questions / Réponses

Mon entreprise n’est pas fournisseur d’IA. Suis-je concerné ? Oui, en tant que déployeur. L’article 26 de l’AI Act impose la supervision par des personnes compétentes et habilitées, la conservation des journaux et la suspension du système en cas d’anomalie : des obligations de sécurité opérationnelle.

Robustesse ou cybersécurité : quelle différence au sens de l’article 15 ? La robustesse vise la résilience face aux erreurs, défaillances et incohérences. La cybersécurité vise la résistance aux tentatives de tiers non autorisés d’altérer l’usage, les sorties ou le comportement du système ainsi que les menaces internes.

Un incident sur un système d’IA doit-il être notifié aujourd’hui ? Si le système soutient un service essentiel ou une fonction critique, les obligations NIS2 ou DORA s’appliquent déjà, sans attendre décembre 2027. Le signalement des incidents graves prévu par l’AI Act viendra s’y ajouter.

Faut-il un outil dédié à la conformité AI Act ? Rarement. L’essentiel des exigences cyber de l’article 15 se satisfait en étendant les dispositifs existants : cartographie, journalisation, détection, gestion des vulnérabilités, réponse à incident.

Par où commencer si rien n’a été fait ? Par l’inventaire. Aucune exigence n’est démontrable sur un parc d’IA que l’on ne connaît pas — et il ne dépend d’aucune norme harmonisée à venir.

Quid de la donnée propriétaire ?

La donnée propriétaire est le nouvel actif de crédibilité. Les moteurs de réponse génératifs, tels que Google AI Overview, redistribuent la visibilité au profit des sources qui apportent une donnée de première main, vérifiable et attribuable. Les analyses génériques s’effacent, les données propriétaires sont citées.

La logique est celle de l’AI Act : une affirmation sans preuve ne vaut rien, ni devant un régulateur, ni devant un moteur. C’est pourquoi le Security Navigator 2026 développé par Orange Cyberdéfense — plus de 139 000 incidents analysés entre octobre 2024 et septembre 2025 dans 160 pays, dont 19 053 confirmés — peut fournir de base factuelle sur laquelle calibrer un modèle de risque IA.

Et pour évaluer la maturité de votre organisation face aux exigences cyber de l’AI Act, venez échanger avec nos experts Orange Cyberdefense !