Choisir un cadre de sécurité de l’IA avant un audit AI Act ou ISO n’a rien d’évident : le marché aligne plus de quinze référentiels, signés par des législateurs, des normalisateurs, des communautés techniques et des fournisseurs de cloud. Nous les classons en quatre familles qui répondent à quatre questions distinctes, puis nous proposons une règle de sélection par rôle d’opérateur et la liste des preuves qu’un auditeur accepte.
L’essentiel
- « Quel référentiel ? » est la mauvaise première question : la loi dit quoi prouver, les catalogues de menaces quoi tester, les jeux de contrôles quoi montrer, les guides d’architecture qui porte quoi.
- Octobre 2026 a rebattu les cartes : ISO/IEC 27090 publiée, EN 18286 première norme harmonisée citée au Journal officiel, enquête publique de prEN 18282 close.
- Depuis l’Omnibus numérique, la déclaration CRA peut couvrir la cybersécurité de l’article 15, pas l’exactitude ni la robustesse.
- Seuls CSA AICM et DASF offrent une correspondance contrôle par contrôle avec l’AI Act et ISO/IEC 42001.
- Un cadre de sécurité de l’IA utile tient en un jeu de contrôles, un catalogue de menaces et un modèle de responsabilité.
Cadre de sécurité de l’IA : ce qu’il est, ce qu’il n’est pas
Nous appelons cadre de sécurité de l’IA un ensemble nommé et versionné de menaces, de contrôles ou de responsabilités pour sécuriser un système d’IA (données, modèle, chaîne de production, application, agents), au regard duquel un tiers peut vérifier votre travail. Sans version, rien ne s’audite.
Quatre familles répondent à quatre questions. La loi dit ce qu’il faut prouver : article 15 de l’AI Act, article 55, paragraphe 1, point d), Cyber Resilience Act. Les catalogues de menaces disent ce qu’il faut tester : MITRE ATLAS, OWASP, NIST AI 100-2. Les jeux de contrôles disent ce qu’il faut montrer : CSA AICM, DASF, annexe A d’ISO/IEC 42001, ISO/IEC 27090, surcouches du NIST, ETSI EN 304 223, ENISA. Les guides d’architecture disent qui détient quoi : SAIF, CoSAI, AWS, Microsoft, Cisco. Retenez un référentiel par famille.
Un cadre de sécurité de l’IA n’est pas un outil de gestion de la posture de sécurité : l’outil applique un cadre, il n’en tient pas lieu. Ce n’est pas un cadre de sûreté : Cisco soutient, le 16 décembre 2025, que sécurité et sûreté sont indissociables, mais l’AI Act les traite dans des articles distincts. Ce n’est pas non plus le cadre de gouvernance de l’IA, dont le volet sécurité n’est qu’une partie. Vue d’ensemble : notre page sur la sécurité de l’IA.
La carte 2026 : les référentiels en un tableau
| Référentiel | Éditeur | Famille | Dernière version (date) | Taille | Lien avec une loi ou une norme |
|---|---|---|---|---|---|
| Article 15 de l’AI Act | Union européenne | Loi | Règlement (UE) 2024/1689 ; annexe III au 2 décembre 2027, annexe I au 2 août 2028 | un article, six classes d’attaques nommées | c’est la loi |
| Cyber Resilience Act | Union européenne | Loi | Règlement (UE) 2024/2847 ; signalement dès le 11 septembre 2026, application le 11 décembre 2027 | exigences essentielles de l’annexe I | l’article 12(1) répute satisfaite la cybersécurité de l’article 15 |
| prEN 18282 | CEN-CENELEC JTC 21 | Norme harmonisée (projet) | enquête publique du 15 mai au 14 juillet 2026 | non public | rédigée pour l’article 15 |
| ISO/IEC 27090:2026 | ISO/IEC JTC 1/SC 27 | Lignes directrices | octobre 2026, 56 pages | non certifiable | preuve en audit ISO/IEC 27001 et 42001 |
| ISO/IEC 42001:2023, annexe A | ISO/IEC JTC 1/SC 42 | Système de management certifiable | décembre 2023 | mesures A.6.2, A.7, A.8.4, A.10.3 | certificat |
| NIST AI RMF 1.0 et NIST AI 600-1 | NIST | Gestion des risques | janvier 2023, juillet 2024 | quatre fonctions, caractéristique « secure and resilient » | volontaire ; repris par AICM et DASF |
| NIST Cyber AI Profile (NIST IR 8596) | NIST et MITRE | Profil communautaire CSF 2.0 | avant-projet du 16 décembre 2025 ; pas de projet public | trois axes (Secure, Defend, Thwart) | CSF 2.0 et AI RMF |
| NIST SP 800-53 Control Overlays for Securing AI Systems | NIST | Surcouche de contrôles | note de cadrage du 14 août 2025 ; aucune surcouche en projet | cinq surcouches | SP 800-53 Rev. 5 |
| NIST AI 100-2 E2025 | NIST | Taxonomie des menaces | 24 mars 2025, 127 pages | deux taxonomies (IA prédictive, IA générative) | aucun |
| Guidelines for Secure AI System Development | NCSC et CISA, 23 organisations cosignataires | Guide du cycle de vie | 27 novembre 2023 | quatre phases | aucun |
| ETSI EN 304 223 | ETSI (issu du code britannique) | Exigences de base | TS avril 2025, EN décembre 2025 | 13 principes, 72 dispositions, cinq phases | aucun |
| ENISA FAICP | ENISA | Bonnes pratiques | 7 juin 2023 | trois couches | coopération du considérant 78 |
| MITRE ATLAS | MITRE | Base de menaces | 2026.10 (28 octobre 2026) | 16 tactiques, 129 techniques, 92 sous-techniques, 44 atténuations | ATT&CK |
| OWASP Top 10 for LLM 2026, Agentic Top 10, AI Exchange | OWASP GenAI Security Project | Listes de menaces et guide de contrôles | août 2026, décembre 2025, projet phare depuis mars 2025 | 10 + 10 entrées, plus de 50 contrôles | NIST, ATLAS, CWE ; l’AI Exchange a nourri ISO/IEC 27090 et prEN 18282 |
| CSA AI Controls Matrix | Cloud Security Alliance | Jeu de contrôles | v1.1, 22 juin 2026 | 247 contrôles, 18 domaines, AI-CAIQ de 320 questions | ISO/IEC 42001, ISO 27001, NIST AI RMF, AI 600-1, BSI AIC4, AI Act |
| Databricks DASF | Databricks | Jeu de contrôles | v3.0, 20 mars 2026 | 13 composants, 97 risques, 73 contrôles | ATLAS, OWASP, SP 800-53, CSF, ENISA, ISO/IEC 42001, 27001, AI Act |
| Google SAIF | Google (données cédées à CoSAI) | Architecture et carte des risques | SAIF 2.0, 6 octobre 2025 | 15 risques, 24 contrôles, trois principes pour les agents | aucun |
| CoSAI, AWS, Microsoft | OASIS, AWS, Microsoft | Responsabilité partagée et périmètre | CoSAI Shared Responsibility Framework v1.0, mai 2026 ; AWS AI Security Framework, mai 2026 ; modèle Microsoft pour les agents, août 2026 | couches, périmètres, principes | aucun (renvois OWASP et ATLAS) |
Ce tableau dit ce qu’est chaque référentiel, pas quel cadre de sécurité de l’IA adopter : c’est la famille qui tranche. Le cadre intégré de sécurité et de sûreté de Cisco (16 décembre 2025, 19 objectifs d’attaquant, plus de 150 techniques) se range avec les catalogues de menaces. Voir aussi nos guides NIST AI RMF et ISO/IEC 42001.
Catalogues de menaces : ce que l’article 15, paragraphe 5, impose de tester
L’article 15, paragraphe 5, du règlement (UE) 2024/1689 exige qu’un système à haut risque résiste aux tiers non autorisés tentant de modifier son utilisation, ses sorties ou sa performance en exploitant ses vulnérabilités. Il nomme les attaques à prévenir, détecter, contrer, résoudre et maîtriser : empoisonnement des données, empoisonnement de modèle, exemples contradictoires ou contournement de modèle, attaques visant la confidentialité, défauts du modèle.
MITRE ATLAS 2026.10 recense 16 tactiques, 129 techniques, 92 sous-techniques, 44 mesures d’atténuation et 77 études de cas ; ses premières techniques agentiques datent de la version 5.0.0 (30 septembre 2025), et sa cadence est mensuelle depuis la mi-2026 (notre fiche MITRE ATLAS). L’OWASP Top 10 for LLM 2026 (3 août 2026) va de LLM01 Prompt Injection à LLM10 Improper Output Handling ; l’Agentic Top 10 (9 décembre 2025), d’ASI01 Agent Goal Hijack à ASI10 Rogue Agents (notre guide OWASP Top 10 LLM et la sécurité de l’IA agentique). La taxonomie NIST AI 100-2 E2025 (24 mars 2025) sépare l’IA prédictive (évasion, empoisonnement, vie privée) et l’IA générative (chaîne d’approvisionnement, injection de prompt directe et indirecte, agents), détaillée dans notre lecture.
| Classe d’attaque (article 15, paragraphe 5) | MITRE ATLAS | OWASP | NIST AI 100-2 |
|---|---|---|---|
| Empoisonnement des données | techniques d’empoisonnement | LLM05 | empoisonnement |
| Empoisonnement de modèle | techniques de chaîne d’approvisionnement et d’empoisonnement | LLM04 et LLM05 | empoisonnement, chaîne d’approvisionnement |
| Exemples contradictoires ou contournement de modèle | techniques d’évasion | LLM01 pour le contournement par le prompt | évasion |
| Attaques visant la confidentialité | techniques d’exfiltration et d’inférence | LLM02 | vie privée |
| Défauts du modèle | pas une classe d’attaque | LLM07, LLM10 | sans équivalent |
| Modification non autorisée de l’utilisation ou des sorties | configuration d’agent et empoisonnement de contexte (AML.T0080, AML.T0081) | ASI03, ASI06 | section consacrée aux agents |
Les défauts du modèle relèvent des tests d’exactitude ; pour la mécanique des attaques, voir l’intelligence artificielle antagoniste. Un cadre de sécurité de l’IA qui ignore l’une de ces six lignes laisse un trou que l’auditeur trouvera.
Jeux de contrôles : là où le cadre de sécurité de l’IA devient une preuve
La CSA AI Controls Matrix v1.1 (22 juin 2026) compte 247 objectifs de contrôle en 18 domaines et cinq piliers, avec analyses d’écarts vers ISO/IEC 42001, ISO 27001, le NIST AI RMF, AI 600-1, BSI AIC4 et l’AI Act. S’y ajoutent le questionnaire AI-CAIQ (320 questions) et STAR for AI : niveau 1 en auto-évaluation, niveau 2 en certification adossée à ISO 42001 ou 27001. Choix naturel si vous exploitez déjà la Cloud Controls Matrix ou ISO 27001.
Le DASF 3.0 de Databricks (20 mars 2026) décrit 13 composants, 97 risques et 73 contrôles, avec un compendium d’applicabilité et des correspondances vers ATLAS, OWASP, SP 800-53, le CSF, l’ENISA, ISO/IEC 42001, 27001 et l’AI Act ; taillé pour une plateforme, il sert d’abord un socle lakehouse.
Dans l’annexe A d’ISO/IEC 42001, la sécurité passe par A.6.2.2 (spécification), A.6.2.4 (vérification et validation), A.6.2.5 (déploiement), A.6.2.6 (exploitation et surveillance), A.6.2.7 (documentation technique), A.6.2.8 (journaux), A.7.2 à A.7.6 (données), A.8.4 (communication des incidents) et A.10.3 (fournisseurs) ; notre boîte à outils ISO 42001 pour l’AI Act en tire les preuves. ISO/IEC 27090:2026, publiée ce mois-ci par le SC 27 (56 pages, non certifiable), dit à un auditeur ISO 27001 ou 42001 ce que recouvre la sécurité d’un système d’IA ; ISO/IEC 27091 (vie privée) est au stade FDIS depuis juillet 2026.
Le NIST reste en chantier : surcouches SP 800-53 (note de cadrage du 14 août 2025, plan annoté en janvier 2026, aucune surcouche en projet) et Cyber AI Profile (avant-projet du 16 décembre 2025, commentaires clos le 30 janvier 2026, pas de projet public) sont prometteurs, pas encore citables. L’AI RMF n’a pas de contrôles ; le profil s’adosse au NIST CSF 2.0.
ETSI EN 304 223 (13 principes, 72 dispositions, cinq phases, issu du code britannique du 31 janvier 2025) est le seul socle à dispositions numérotées. Les lignes directrices NCSC et CISA (quatre phases) et le guide CISA sur l’IA agentique (1er mai 2026) relèvent du déploiement ; les trois couches du FAICP de l’ENISA rappellent que la cybersécurité générale passe d’abord.
Notre règle : un seul jeu de contrôles, une analyse d’écarts face à la loi, tenue comme un document vivant. Un cadre de sécurité de l’IA non maintenu se périme à la version suivante.
Architecture et responsabilité partagée : SAIF, CoSAI, AWS, Microsoft
Le SAIF de Google, version 2.0 du 6 octobre 2025, couvre quatre domaines de composants, 15 risques, 24 contrôles et trois principes pour les agents : contrôleurs humains bien identifiés, pouvoirs limités, actions et planification observables. Son auto-évaluation produit un rapport de risques. En septembre 2025, ses données sont passées à CoSAI (la CoSAI Risk Map).
CoSAI (OASIS, juillet 2024) a publié ses principes pour des systèmes agentiques sécurisés dès la conception (16 juillet 2025 : gouvernés par l’humain et responsables, bornés et résilients, transparents et vérifiables), un cadre de réponse aux incidents (octobre 2025, playbooks rattachés à ATLAS), un cadre de responsabilité partagée v1.0 (mai 2026, cinq couches, un responsable par composant), MCP Security v2.0 (septembre 2026) et Zero Trust for AI Systems (16 septembre 2026).
AWS propose la Generative AI Security Scoping Matrix (cinq périmètres, octobre 2023), sa déclinaison agentique (quatre périmètres, novembre 2025) et l’AWS AI Security Framework de mai 2026 (trois couches, trois phases, contrôles cumulatifs). Microsoft publie un modèle de responsabilité partagée pour l’IA et, depuis août 2026, un modèle pour les agents dont les risques renvoient à OWASP et ATLAS.
Notre verdict : ces documents répondent à « qui possède quel contrôle ? » et à « où se situe-t-il ? », sans lien avec l’article 15. Servez-vous-en pour répartir les contrôles, jamais pour revendiquer une conformité. Le cadre de sécurité de l’IA d’un fournisseur est un guide de mise en œuvre : seuls AICM et DASF offrent une correspondance contrôle par contrôle avec l’AI Act et ISO/IEC 42001 ; SAIF, CoSAI, AWS, Microsoft et Cisco n’en portent aucune, et OWASP comme ATLAS cataloguent des menaces, pas des contrôles. Une nomenclature de l’IA (AI-BOM) montre ce que chaque modèle couvre.
Le droit derrière le cadre de sécurité de l’IA : article 15, article 42 et Cyber Resilience Act
L’article 15, « Exactitude, robustesse et cybersécurité », exige un niveau approprié d’exactitude, de robustesse et de cybersécurité, constant sur tout le cycle de vie (paragraphe 1), la résilience aux erreurs, la redondance technique et la maîtrise des boucles de rétroaction (paragraphe 4), et la résistance aux attaques (paragraphe 5). L’article 13, paragraphe 3, point b) ii), veut que la notice d’utilisation indique le niveau au regard duquel le système a été testé. Pour les modèles d’IA à usage général à risque systémique, l’article 55, paragraphe 1, points a) et d), impose depuis le 2 août 2025 des essais contradictoires documentés et une cybersécurité adéquate du modèle et de son infrastructure physique.
Deux présomptions allègent la charge. L’article 42, paragraphe 2, présume conforme à la cybersécurité de l’article 15 le système certifié selon un schéma du Cybersecurity Act (règlement (UE) 2019/881), à partir du 2 août 2026. Le nouvel article 42, paragraphe 3, issu de l’Omnibus numérique sur l’IA (règlement (UE) 2026/1744, en vigueur le 27 juillet 2026), et l’article 12, paragraphe 1, du CRA réputent conforme le système à haut risque qui est aussi un produit comportant des éléments numériques, s’il respecte les exigences essentielles du Cyber Resilience Act et si sa déclaration de conformité CRA démontre le niveau de l’article 15. Les organismes notifiés de l’AI Act peuvent aussi vérifier le CRA (article 12, paragraphe 2). Le considérant 77 borne l’effet : la cybersécurité seule, ni la robustesse ni l’exactitude.
Calendrier : annexe III au 2 décembre 2027, annexe I au 2 août 2028 (voir les systèmes d’IA à haut risque) ; signalement CRA dès le 11 septembre 2026, application complète le 11 décembre 2027. EN 18286 (management de la qualité), citée au Journal officiel en octobre 2026 par la décision d’exécution (UE) 2026/2274, est la première norme harmonisée de l’AI Act. Le projet prEN 18282 (JTC 21 WG 5, spécifications de cybersécurité des systèmes d’IA) a été soumis à enquête publique du 15 mai au 14 juillet 2026 ; la demande de normalisation court jusqu’au 28 février 2027.
L’ENISA complète : FAICP (7 juin 2023), avis du 7 juillet 2026 sur la cybersécurité à l’ère de l’IA de pointe (NIS2, CRA et AI Act à lire ensemble pour les modèles à risque systémique), plan d’action de l’UE sur la cybersécurité et l’IA du même jour, ENISA Threat Landscape 2026 (22 septembre 2026), où les attaques assistées par l’IA figurent parmi les principales menaces. Selon l’article 73, une faille de sécurité n’est notifiable que si elle constitue un incident grave (article 3, point 49) ; le déployeur surveille et suspend au titre de l’article 26, paragraphe 5 (signalement des incidents). Tout cadre de sécurité de l’IA se lit à travers ces articles.
Comment choisir : une règle de sélection par rôle d’opérateur
| Votre rôle | Ancrage juridique | Catalogue de menaces | Jeu de contrôles | Preuve acceptée par un auditeur |
|---|---|---|---|---|
| Fournisseur d’un système d’IA à haut risque | articles 9, 11, 13, 15 et 43 | ATLAS, OWASP, NIST AI 100-2 | annexe A d’ISO/IEC 42001 ou CSA AICM ; prEN 18282 une fois harmonisée | section cybersécurité de l’annexe IV, rapports de tests et de red teaming, métriques de la notice d’utilisation, déclaration UE de conformité |
| Fournisseur d’un produit comportant des éléments numériques | article 12 du CRA, article 42(3) de l’AI Act | les mêmes | exigences essentielles de l’annexe I du CRA | déclaration de conformité CRA indiquant le niveau de l’article 15 |
| Déployeur | articles 26 et 73 | OWASP Agentic Top 10 pour les agents | AI-CAIQ adressé au fournisseur, matrice de responsabilité partagée (CoSAI, AWS ou Microsoft), surveillance | questionnaire fournisseur, trace de la notice d’utilisation, journal de surveillance, décision de suspension |
| Fournisseur de modèle à usage général à risque systémique | article 55(1), points a) et d) | ATLAS, évaluations de modèles de pointe | CoSAI, avis de l’ENISA, code de bonnes pratiques | essais contradictoires documentés, mesures de cybersécurité du modèle et de l’infrastructure |
| Entreprise qui construit sur une plateforme cloud | article 15 ou 26 selon le rôle | OWASP Top 10 for LLM | cadre de la plateforme (SAIF, DASF, AWS, Microsoft) pour la mise en œuvre, AICM pour la revendication de conformité | cartographie des contrôles avec analyse d’écarts |
Trois règles en découlent. Un seul jeu de contrôles, un seul catalogue de menaces, un seul modèle de responsabilité : empiler les matrices multiplie les correspondances sans ajouter de preuve. Chacun cartographié une fois sur les six classes de l’article 15, paragraphe 5 : cette table est la colonne vertébrale du dossier. Une cartographie sous gestion des changements : nouvelle version du référentiel, nouveau modèle ou nouvel agent la rouvrent. Le rôle se détermine système par système dans un registre des systèmes d’IA ; un cadre de sécurité de l’IA choisi pour le mauvais rôle produit des preuves que personne ne demande.
En France, l’ANSSI fait référence : ses recommandations de sécurité pour un système d’IA générative (2024) et la déclaration conjointe de février 2025 sur la confiance dans l’IA par une approche par les risques cyber forment l’ancrage national (cyber.gouv.fr). La CNIL reste compétente pour les données personnelles d’entraînement et d’inférence. La surveillance du marché au titre de l’AI Act est annoncée, pas encore inscrite dans la loi : documentez vos choix sans présumer de l’autorité qui les lira.
Du cadre de sécurité de l’IA à la preuve d’audit
Sept pièces transforment un référentiel en dossier défendable.
- La cartographie des contrôles avec analyse d’écarts face à l’article 15. AICM et DASF en livrent chacun une ; elle montre ce qui couvre chaque exigence et ce qui manque.
- Le modèle de menaces par système, sur les six classes de l’article 15, paragraphe 5. Il dit quelles attaques sont plausibles, lesquelles sont écartées, et pourquoi.
- Les rapports de tests contradictoires et de red teaming, datés et rejoués après chaque modification substantielle. Un rapport non daté ne prouve rien.
- La section cybersécurité de l’annexe IV et les métriques de la notice d’utilisation. Ce sont les chiffres que l’évaluation de la conformité confronte aux tests.
- Le questionnaire fournisseur (AI-CAIQ) et la répartition des responsabilités. Sans elle, personne ne sait qui corrige le modèle hébergé.
- Les playbooks d’incident et le journal des décisions au titre de l’article 73. Chaque faille examinée y figure, notifiée ou non, avec sa raison.
- Le rapport de risques SAIF ou DASF, comme document de travail. Il nourrit l’analyse, jamais la revendication de conformité.
Ces pièces vivent mieux dans une plateforme de gouvernance : l’inventaire des systèmes d’IA d’abord, un jeu de contrôles par système ensuite, puis des preuves datées rattachées à chaque contrôle. La surveillance de la conformité signale les preuves périmées ; l’auditabilité tient à cette traçabilité. Un cadre de sécurité de l’IA ne vaut que par les preuves qu’il produit.
Questions fréquentes
<b>Qu’est-ce qu’un cadre de sécurité de l’IA ?</b>
Un ensemble nommé et versionné de menaces, de contrôles ou de responsabilités pour sécuriser un système d’IA, au regard duquel un tiers peut vous évaluer. Il relève de l’une de quatre familles : la loi (article 15 de l’AI Act, CRA), les catalogues de menaces (ATLAS, OWASP, NIST AI 100-2), les jeux de contrôles (AICM, DASF, ISO/IEC 42001) ou les guides de responsabilité (SAIF, CoSAI, AWS, Microsoft). Un programme sérieux en retient un par famille.
<b>Quel cadre de sécurité de l’IA l’AI Act impose-t-il ?</b>
Aucun référentiel nommé. L’AI Act impose un résultat : une cybersécurité appropriée (article 15), la résistance aux attaques du paragraphe 5 et, pour les modèles à risque systémique, l’article 55. La présomption de conformité passera par les normes harmonisées citées au Journal officiel ; prEN 18282, rédigée pour l’article 15, ne l’est pas encore. D’ici là, un jeu de contrôles cartographié sur l’article 15 et des tests datés font la preuve.
<b>ISO/IEC 27090 est-elle une norme certifiable ?</b>
Non. ISO/IEC 27090:2026, publiée en octobre 2026 par l’ISO/IEC JTC 1/SC 27, est un document de lignes directrices de 56 pages sur les menaces et compromissions visant les systèmes d’IA. Personne ne se fait certifier ISO/IEC 27090. Elle sert de référence dans un audit ISO/IEC 27001 ou 42001, en disant à l’auditeur ce que recouvre la sécurité d’un système d’IA. Le certificat reste celui du système de management.
<b>NIST AI RMF ou NIST Cyber AI Profile : lequel est le cadre de sécurité ?</b>
Aucun des deux n’est, à ce jour, un jeu de contrôles. L’AI RMF 1.0 (janvier 2023) est un cadre de gestion des risques à quatre fonctions, où « secure and resilient » n’est qu’une caractéristique ; il ne contient pas de contrôles. Le Cyber AI Profile (NIST IR 8596) applique le CSF 2.0 à l’IA selon trois axes, Secure, Defend et Thwart, mais n’existe qu’en avant-projet du 16 décembre 2025. Structurez la gouvernance avec l’AI RMF ; suivez le profil sans le citer.
<b>Faut-il un cadre si votre fournisseur exploite le modèle ?</b>
Oui. Le déployeur garde ses obligations : utiliser le système selon la notice, le surveiller, informer le fournisseur et suspendre l’utilisation en cas de risque (article 26), signaler les incidents graves (article 73). Votre cadre de sécurité de l’IA se réduit alors à trois pièces : le questionnaire AI-CAIQ adressé au fournisseur, une matrice de responsabilité partagée (CoSAI, AWS ou Microsoft) et un journal de surveillance. Pour des agents, ajoutez l’OWASP Agentic Top 10 à vos tests.
<b>Quelle différence entre un cadre de sécurité de l’IA et la gestion de la posture de sécurité de l’IA ?</b>
Un cadre est un référentiel : des menaces, des contrôles ou des responsabilités au regard desquels on vous évalue. La gestion de la posture de sécurité de l’IA (AI-SPM) est une catégorie d’outils : elle découvre modèles et données, détecte les mauvaises configurations, émet des alertes. L’outil mesure l’application d’un cadre sans le remplacer. L’auditeur demandera un référentiel et des preuves, pas une capture de console.
Conclusion
La question utile n’est pas « quel référentiel adopter ? », mais « quelle famille répond à quelle question ? ». La loi décide de ce qu’il faut prouver, le catalogue de menaces de ce qu’il faut tester, le jeu de contrôles de ce qu’il faut montrer, le modèle de responsabilité de qui en répond. Octobre 2026 a posé les repères : ISO/IEC 27090 publiée, une première norme harmonisée au Journal officiel, la voie CRA de l’article 42, paragraphe 3. Un cadre de sécurité de l’IA bien choisi tient en trois références et une cartographie. Inventoriez vos systèmes, attribuez à chacun un jeu de contrôles, rattachez des preuves datées à chaque contrôle : le cadre de sécurité de l’IA se juge à ce dossier.