Non-conformité AI Act : risques et pont vers ISO 42001

Cartographie des risques de non-conformité

Pour un responsable conformité ou un DPO, la non-conformité au règlement européen sur l'IA ne se résume pas à une amende. Elle comporte trois strates qui doivent être traitées séparément, parce qu'elles relèvent d'autorités, de calendriers et de preuves différents.

La première strate est juridique. L'AI Act est une législation contraignante à portée extraterritoriale : il s'applique aux fournisseurs et déployeurs dont les systèmes sont mis sur le marché de l'Union ou dont les sorties sont utilisées dans l'Union, indépendamment du lieu d'établissement^[4]. Un acteur suisse qui exporte un service d'IA vers un client français est concerné, ce qui inclut la majorité des éditeurs SaaS romands.

La deuxième strate est contractuelle. Les clients, en particulier dans la finance et la santé, intègrent désormais des clauses d'alignement à l'AI Act et aux référentiels de gouvernance dans leurs appels d'offres^[3]. Un défaut documentaire devient un motif d'éviction commerciale avant d'être un motif de sanction.

La troisième strate est réputationnelle et opérationnelle : biais, défaillances, atteinte à la vie privée, perte de traçabilité. Ces risques préexistent au règlement, mais celui-ci les rend visibles et redevables. Le SMIA décrit par ISO/IEC 42001 répond précisément à cette strate, en imposant une gestion par cycle de vie^[8].

Sanctions et calendrier d'application

L'architecture de sanctions de l'AI Act est calibrée sur le niveau de risque du système concerné. Les pratiques interdites, comme la notation sociale ou certaines formes de manipulation, exposent à des amendes pouvant atteindre 35 millions d'euros ou 7 pour cent du chiffre d'affaires annuel mondial^[4]. Les autres infractions, par exemple un défaut documentaire sur un système à haut risque, plafonnent à 15 millions d'euros ou 3 pour cent du chiffre d'affaires^[4].

Les jalons de mise en application s'étalent. Selon VerifyWise, en novembre 2025, l'échéancier post-omnibus retient plusieurs dates structurantes pour la planification interne^[4]. Vérifier l'évolution depuis cette date sur le texte officiel reste indispensable, le règlement ayant fait l'objet d'un omnibus annoncé pour mai 2026.

Séquence des obligations entrant en vigueur, telle que documentée en novembre 2025.

12 février 2025 : pratiques interdites et obligation de littératie IA

22 août 2025 : obligations des fournisseurs de modèles GPAI

32 décembre 2026 : transparence des contenus synthétiques, article 50(2)

42 décembre 2027 : obligations Annexe III pour systèmes haut risque autonomes

52 août 2028 : IA haut risque intégrée aux produits régulés Annexe I

Source VerifyWise, novembre 2025, à recouper avec le texte consolidé publié sur EUR-Lex^[4].

Pour le DPO, l'échéance de février 2025 a déjà déplacé le sujet de la projection à l'exécution : la littératie IA est due pour tout collaborateur exposé à un système d'IA, qu'il en soit utilisateur ou opérateur. La preuve attendue ressemble à celle exigée pour la protection des données, plans de formation, attestations, suivi des populations cibles^[4].

Recouvrement avec ISO/IEC 42001

La question pratique posée par les comités de direction est rarement théorique : que gagne-t-on à certifier ISO/IEC 42001 quand l'AI Act est, lui, obligatoire. La réponse documentée par plusieurs analyses indépendantes converge vers un recouvrement de 40 à 50 pour cent des exigences de haut niveau^[4][7].

Ce recouvrement se concentre sur quatre familles d'exigences. La gouvernance des données, traitée à l'article 10 du règlement pour les systèmes à haut risque, trouve un répondant dans les contrôles de gestion des données du SMIA^[7]. La gestion des risques, structurée en quatre catégories par l'AI Act, s'appuie sur l'analyse d'impact et l'évaluation des risques exigées par ISO/IEC 42001^[7].

La supervision humaine, prescrite par l'article 14 du règlement, recouvre les exigences d'attribution des rôles et de documentation des processus du SMIA^[7]. Enfin, les considérations éthiques, équité, non-discrimination et dignité, sont traitées en parallèle par les deux référentiels^[4].

Comparatif de portée AI Act et ISO/IEC 42001

Critère	AI Act
Nature	Législation contraignante, sanctions financières[4]
Champ	Systèmes commercialisés ou utilisés dans l'Union[4]
Approche	Par risque produit, quatre tiers[1]
Preuve	Évaluation de conformité, registre, déclaration[1]
Critère	ISO/IEC 42001
Nature	Standard volontaire, certifiable par organisme accrédité[8]
Champ	Toute organisation, toute taille, toute industrie[8]
Approche	Système de management par cycle de vie, PDCA[1]
Preuve	Audit de certification, validité trois ans[7]

Écarts résiduels à traiter en propre

Le risque de gouvernance, pour un responsable conformité, n'est pas le recouvrement, c'est l'écart résiduel. Une organisation certifiée ISO/IEC 42001 reste exposée à des manquements à l'AI Act si elle ne traite pas ce qui sort du SMIA.

Premier écart : les interdictions absolues. L'AI Act prohibe certaines pratiques, notation sociale, manipulation, identification biométrique à distance en temps réel dans l'espace public sauf exceptions^[4]. ISO/IEC 42001 ne prohibe rien et renvoie à l'organisation le soin de déterminer ce qui est légalement interdit^[4]. La cartographie des cas d'usage doit donc inclure un filtre légal explicite, antérieur à l'évaluation des risques.

Deuxième écart : les obligations prescriptives. L'AI Act exige des contenus documentaires précis, des journaux conservés au moins six mois pour les systèmes haut risque, des procédures d'évaluation de conformité spécifiques^[4]. ISO/IEC 42001 est principe-orienté et laisse l'organisation calibrer ses contrôles^[4]. Il faut donc traduire les exigences principielles du SMIA en livrables conformes au format attendu par le règlement.

Troisième écart : la sécurité produit. L'AI Act traite l'IA comme un produit qui doit satisfaire des exigences avant mise sur le marché, avec marquage CE pour les systèmes haut risque^[4]. ISO/IEC 42001 raisonne en système de management couvrant développement, déploiement et exploitation^[4]. Les deux logiques cohabitent mais ne se substituent pas.

Quatrième écart : le régime de preuve. L'AI Act prévoit l'auto-attestation par défaut et l'intervention d'un organisme notifié pour les systèmes haut risque^[7]. ISO/IEC 42001 prévoit une certification par organisme accrédité, valable trois ans^[7]. Les deux dossiers de preuve coexistent et alimentent des autorités différentes.

Feuille de route pour un acteur suisse

Pour un éditeur ou un déployeur établi en Suisse romande, l'exposition à l'AI Act dépend du périmètre commercial. Un cabinet de prévoyance qui sert exclusivement une clientèle suisse n'entre pas dans le champ. Un éditeur fintech qui commercialise un outil de scoring à des banques européennes y entre intégralement, même sans entité juridique dans l'Union^[4].

La séquence observée dans les démarches les plus rationnelles tient en quatre temps. D'abord une cartographie des cas d'usage, avec qualification par niveau de risque AI Act et identification des interdictions. Ensuite une évaluation d'écart conjointe AI Act et ISO/IEC 42001, qui révèle généralement que la moitié des exigences est couverte par les démarches qualité ou sécurité préexistantes^[7].

Vient ensuite la construction d'un SMIA qui sert de socle. Selon plusieurs cabinets spécialisés, dont GRC Solutions et A-LIGN, ce socle est généralement intégré à un système ISO/IEC 27001 préexistant pour mutualiser politiques, rôles et revues de direction^[3][6]. À recouper avec votre référentiel de certification, ce point relève d'un choix d'architecture documentaire propre à chaque organisation.

Enfin, la production des livrables spécifiques à l'AI Act, registre des systèmes, documentation technique, déclaration UE de conformité pour les systèmes haut risque, plan de surveillance post-commercialisation. Ces livrables ne sont pas exigés par ISO/IEC 42001 mais peuvent être dérivés des éléments du SMIA^[1].

Pièges fréquents en pratique

Les démarches observées révèlent quelques pièges récurrents que le responsable conformité a intérêt à anticiper. Le premier consiste à confondre certification ISO/IEC 42001 et conformité AI Act. Une certification ne constitue pas une présomption de conformité au règlement, et les organismes officiels n'ont publié, à la date de juin 2026, aucune équivalence formelle.

Le deuxième piège porte sur la littératie IA. Plusieurs équipes la traitent comme une formation générique alors que l'article 4 du règlement exige une littératie proportionnée au rôle et au système concerné^[4]. La preuve attendue est nominative, comme pour la protection des données.

Le troisième piège concerne le statut de fournisseur. Une organisation qui adapte significativement un système d'IA tiers, par fine-tuning ou par changement d'usage, peut être requalifiée en fournisseur au sens du règlement, avec les obligations afférentes^[1]. Le DPO doit donc cartographier non seulement les usages mais aussi les modifications opérées sur les modèles externes.

Le quatrième piège est documentaire. La traçabilité exigée par l'AI Act repose sur des journaux techniques conservés au moins six mois pour les systèmes haut risque^[4]. Beaucoup d'infrastructures cloud existantes ne capturent pas le bon niveau de granularité par défaut. C'est un sujet d'architecture, pas un sujet de politique, et il vaut mieux le traiter en amont de la certification.

Dernier piège, plus discret, la chaîne fournisseurs. Les déployeurs s'appuient sur des modèles fondation, des API et des services managés dont la documentation conditionne leur propre dossier de conformité^[1]. Sans clauses contractuelles précises sur la mise à disposition de la documentation technique, la déclaration de conformité du déployeur reste fragile.

Questions fréquentes

À lire ensuite