BOARD BRIEFING REPORTBanques & marchés financiers européensQuestion au Management Board · Pour discussion

Nous avons une politique, une norme et un certificat — que prouvent-ils ?

TopicArchitecture de gouvernance de l'IA
AudienceManagement Board · CIO · CRO · CDO · Compliance
Read Time13 minutes
Target StatusGREEN — lorsque droit, système de management, méthode de risque et tests s'articulent dans un modèle opérationnel traçable

En un coup d'œil

Chacun de ces éléments est présenté comme le cadre de gouvernance de l'IA de l'institution.

<strong>Aucun ne répond à la même question.</strong>

Question au conseilLa direction peut-elle démontrer comment les obligations juridiques, la gouvernance organisationnelle, les décisions de risque et les tests des systèmes s'articulent dans un modèle opérationnel unique et traçable ?

Situation

La direction présente au conseil une politique d'IA alignée sur l'EU AI Act, un programme de certification ISO/IEC 42001, une méthodologie de risque fondée sur le NIST AI Risk Management Framework et un processus de tests techniques.

Chacun de ces éléments est présenté comme le cadre de gouvernance de l'IA de l'institution.

Aucun ne répond à la même question.

Les composantes prises séparément peuvent être bien conçues. La question pour le conseil est de savoir si elles constituent un système intégré. Un cadre juridique définit les obligations. Un système de management détermine la manière dont la gouvernance fonctionne. Une méthode de risque structure le jugement. Les tests et l'assurance apportent la preuve que les résultats attendus et les contrôles ont été atteints.

  • Un certificat ne remplace pas une matrice de correspondance réglementaire.
  • Une évaluation des risques ne démontre pas qu'un contrôle fonctionne.
  • Un résultat de test ne prouve pas que les bonnes obligations juridiques ont été identifiées.

Management Summary

Un cadre complet de gouvernance de l'IA comporte quatre couches reliées entre elles :

  1. Le droit détermine ce qui est interdit, obligatoire ou soumis à conditions.
  2. Le système de management attribue les responsabilités et rend la gouvernance reproductible.
  3. La méthode de risque détermine comment les risques sont classés, évalués, acceptés et traités.
  4. Les tests et les preuves démontrent comment les systèmes et les contrôles fonctionnent en pratique.

Ces couches sont complémentaires, non interchangeables.

ISO/IEC 42001 peut fournir un système de management de l'IA structuré et certifiable. Elle n'établit pas automatiquement la conformité à l'EU AI Act pour chaque système ou chaque cas d'usage. Le programme européen de normalisation a élaboré EN 18286 spécifiquement pour les exigences de management de la qualité liées à l'AI Act, car ISO/IEC 42001 n'a pas été considérée comme pleinement alignée sur les objectifs et les définitions de cette exigence réglementaire.

Le conseil doit donc attendre un Framework Stack, et non une simple étiquette de framework.

Une institution peut acheter un certificat. Elle ne peut pas acheter > la matrice de correspondance.

Management Report Panel

Question du conseil
Comment nos cadres juridiques, de management, de risque et de tests s'articulent-ils ?
Distinction centrale
Chaque couche répond à une question de gouvernance différente.
Risque principal
Le nom d'un framework ou un certificat est utilisé comme preuve pour des éléments situés hors de son périmètre.
Preuve requise
Une ligne traçable reliant l'obligation au contrôle, au test, au responsable et à la preuve conservée.
État cible
Une architecture gouvernée couvrant l'ensemble du périmètre IA et de son cycle de vie.

Calibration de la qualité de réponse

GREENRéponse de qualité décisionnelle
AMBERRéponse partiellement étayée
REDPas de qualité décisionnelle
InventaireUn périmètre IA unique, gouverné et réconcilié
InventaireUn inventaire existe, mais certaines IA tierces ou intégrées restent hors périmètre
Inventaire« Nous savons où se trouve notre IA. »
Cartographie juridiqueMatrice de correspondance entre exigences et contrôles par cas d'usage
Cartographie juridiqueUne cartographie juridique existe mais n'est pas reliée aux contrôles
Cartographie juridique« Nous sommes alignés sur l'EU AI Act. »
Périmètre de certificationLe périmètre, les exclusions et les frontières organisationnelles sont explicites
Périmètre de certificationUn certificat existe, mais son périmètre n'est pas réconcilié avec l'inventaire IA
Périmètre de certification« Nous préparons une certification ISO. »
Méthode de risqueLa classification détermine le parcours de gouvernance
Méthode de risqueDes scores de risque existent, mais ne modifient ni les exigences ni les approbations
Méthode de risque« Nous suivons le framework NIST. »
TestsLes seuils d'acceptation sont liés à l'usage prévu
TestsDes tests sont réalisés, mais séparés du cas d'usage ou de la décision
Tests« Le fournisseur a testé le modèle. »
ResponsabilitéUn responsable nommé détient l'autorité d'approuver, d'arrêter et d'escalader
ResponsabilitéDes comités interviennent, mais l'autorité personnelle reste floue
Responsabilité« Cela passe par le comité IA. »
TiersLes preuves, les obligations de notification des changements et les droits d'audit sont définis
TiersDes clauses contractuelles existent, mais les preuves opérationnelles sont incomplètes
Tiers« C'est la responsabilité du fournisseur. »
Reporting au conseilL'efficacité, les exceptions et les décisions sont rapportées
Reporting au conseilLe statut de livraison est rapporté, mais l'efficacité des contrôles n'est pas visible
Reporting au conseil« Le programme est dans les temps. »

Le statut RAG calibre la qualité de la réponse. Il ne juge pas l'institution.

The Framework Stack

01
Cadre juridique
Que doit faire l'institution ?
02
Système de management
Qui gouverne l'IA, au moyen de quelles responsabilités et de quels processus ?
03
Méthode de risque
Comment les risques liés à l'IA sont-ils identifiés, évalués, acceptés et traités ?
04
Tests et preuves
Qu'est-ce qui démontre que le système et ses contrôles fonctionnent comme annoncé ?

Chaque couche répond à une question différente. Aucune ne répond à la suivante.

Qui doit répondre

Responsabilité métierJuridiqueConformitéRisquesRisque de modèleTechnologieDonnéesCybersécuritéProtection des donnéesRisque tiersAchatsAudit interne
Note de responsabilité:
  • L'appartenance à un comité n'est pas équivalente à une responsabilité personnelle.
  • Le responsable nommé doit détenir l'autorité nécessaire pour approuver, restreindre, suspendre ou escalader l'usage de l'IA concerné.

Preuves que le conseil devrait demander

  1. 01Inventaire IA de l'entreprise
  2. 02Carte d'architecture des frameworks
  3. 03Matrice de correspondance réglementaire
  4. 04Responsabilités et droits de décision
  5. 05Méthodologie de classification
  6. 06Carte des contrôles du cycle de vie
  7. 07Analyse d'impact et des risques
  8. 08Dossier de test et de validation
  9. 09Déclaration du périmètre de certification
  10. 10Dossier de reporting au conseil

Signaux d'alerte

  • “« Nous suivons le framework NIST. »”
  • “« Nous sommes alignés sur l'EU AI Act. »”
  • “« Nous préparons une certification ISO. »”
  • “« Le fournisseur a testé le modèle. »”
  • “« Un humain approuve le résultat. »”
  • “« C'est couvert par la politique IA. »”
  • “« Ce n'est qu'un outil interne. »”
  • “« Le framework est en cours de déploiement. »”

Aucune de ces affirmations n'est nécessairement erronée. Elles ne constituent simplement pas une preuve suffisante pour que le conseil puisse s'y fier.

Chemin vers le vert

  • Architecture nommée
  • Matrice de correspondance construite
  • La classification détermine le parcours
  • Norme de preuve définie
  • Tiers inclus
  • Efficacité surveillée

Un inventaire juridique non relié aux contrôles reste une > interprétation. Une bibliothèque de contrôles non reliée au droit > reste un choix de conception interne.

Le conseil ne doit pas demander quel framework l'institution suit. > Il doit demander si un usage de l'IA à conséquences significatives > peut être retracé de l'obligation jusqu'à la preuve opérationnelle.

Prochaine question suggérée

Prenez un système d'IA susceptible d'affecter de manière significative un client, un salarié, une transaction ou un processus critique. La direction peut-elle montrer, dans une seule chaîne de preuves, le droit applicable, le responsable redevable, la décision de risque approuvée, les contrôles opérationnels, les résultats des tests, le mécanisme d'intervention humaine, les dépendances à des tiers et l'état de production actuel ?

Commentaire d'expert — 7 min de lecture

01

Le cadre juridique définit l'obligation

La couche juridique détermine les obligations applicables à un système d'IA, le rôle réglementaire de l'institution et les preuves nécessaires pour démontrer la conformité.

Dans l'Union européenne, l'AI Act s'articule avec le RGPD, DORA et les exigences sectorielles existantes. Les obligations pertinentes dépendent notamment de la finalité prévue, de la classification du système, des personnes concernées, du rôle de l'organisation et de l'utilisation dans un processus réglementé.

Pour les systèmes d'IA à haut risque, l'AI Act traite notamment de la gestion des risques, de la gouvernance des données, de la documentation technique, de la tenue des registres, de la surveillance humaine, de l'exactitude, de la robustesse, de la cybersécurité et du management de la qualité. L'article 17 impose aux fournisseurs de maintenir un système de management de la qualité documenté garantissant la conformité au règlement.

Cela ne signifie pas qu'une banque doit construire une structure de contrôle isolée dédiée à l'AI Act. Les exigences de gouvernance existantes restent pertinentes. DORA régit les TIC et la résilience opérationnelle. Le RGPD impose une obligation de responsabilité pour le traitement des données personnelles et encadre certaines décisions automatisées. Les exigences du secteur financier en matière de gouvernance, d'externalisation, de conduite et de risque de modèle peuvent continuer de s'appliquer au même système.

La couche juridique doit donc répondre à trois questions :

  • Quelles obligations s'appliquent ?
  • À quelle entité, à quel rôle et à quel cas d'usage
  • s'appliquent-elles ?
  • Par quels contrôles et quelles preuves seront-elles démontrées ?

Un inventaire juridique non relié aux contrôles reste une interprétation. Une bibliothèque de contrôles non reliée au droit reste un choix de conception interne.

02

Le système de management rend la gouvernance reproductible

ISO/IEC 42001 définit les exigences d'un système de management de l'IA. Elle couvre les processus organisationnels permettant d'établir, de mettre en œuvre, de maintenir et d'améliorer en continu la gouvernance de l'IA.

Sa valeur réside dans la reproductibilité. Elle peut fournir une structure pour le périmètre, la politique, les objectifs, les responsabilités, les processus de risque, les compétences, la communication, le suivi, l'audit interne et l'amélioration continue.

Une certification ISO/IEC 42001 constitue donc une preuve significative concernant un périmètre défini de système de management. Elle n'établit pas automatiquement que chaque cas d'usage de l'IA appartient à ce périmètre ni que chaque système est conforme à l'EU AI Act.

Cette distinction est renforcée par EN 18286:2026, la première norme européenne publiée pour soutenir la mise en œuvre de l'AI Act. Elle porte sur le système de management de la qualité requis à des fins réglementaires, en particulier au titre de l'article 17.

Le JTC 21 du CEN-CENELEC a examiné si ISO/IEC 42001 pouvait être reprise pour satisfaire à l'exigence de management de la qualité prévue à l'article 17 de l'AI Act. Les objectifs et définitions n'ayant pas été considérés comme pleinement alignés sur cette exigence réglementaire, une norme européenne distincte a été élaborée : EN 18286, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes*.

Il ne s'agit pas de dire qu'ISO/IEC 42001 est insuffisante. Il s'agit de reconnaître qu'une norme de système de management organisationnel et une exigence réglementaire de management de la qualité ne démontrent pas la même chose.

EN 18286 définit la qualité par rapport à la conformité aux exigences applicables de l'AI Act, et non comme une qualité de produit au sens traditionnel d'ISO 9001. Sa structure permet également d'intégrer les exigences spécifiques à l'IA dans un système sectoriel existant de management de la qualité, plutôt que d'imposer la création d'un second système parallèle.

Pour les banques, le principe pratique est l'intégration. La gouvernance de l'IA doit étendre les cadres existants d'entreprise, de technologie, de données, de risque et de résilience opérationnelle lorsque ces structures restent appropriées.

L'article 40 de l'AI Act n'accorde une présomption de conformité que lorsque la référence à une norme harmonisée a été publiée au Journal officiel de l'Union européenne, et uniquement pour les exigences couvertes par cette norme. À la fin de juillet 2026, la référence à EN 18286 n'avait pas encore été publiée au Journal officiel.

Une institution peut acheter un certificat. Elle ne peut pas acheter la matrice de correspondance.

Le conseil doit donc demander le périmètre précis de la certification, les exclusions, les activités couvertes et le lien avec l'inventaire IA et les obligations réglementaires.

03

La méthode de risque structure le jugement

Le NIST AI Risk Management Framework organise l'activité de gestion des risques liés à l'IA autour de quatre fonctions :

  • Govern
  • Map
  • Measure
  • Manage

Govern est transversal. Map établit le contexte et identifie les parties concernées et les risques. Measure évalue et surveille le comportement du système et le risque. Manage priorise et traite les risques selon les objectifs et les tolérances de l'organisation.

Ce dispositif crée un langage commun pour le risque lié à l'IA sans imposer un résultat réglementaire ou un ensemble de contrôles unique.

Le framework peut soutenir :

  • une taxonomie des risques,
  • la classification des cas d'usage,
  • l'évaluation d'impact et de matérialité,
  • la mesure du risque,
  • les critères d'acceptation,
  • les seuils d'escalade,
  • et les décisions de traitement.

Mais le framework ne détermine pas quelles obligations juridiques s'appliquent. De même, l'achèvement d'une évaluation des risques ne démontre pas que la mesure d'atténuation fonctionne efficacement.

La classification doit déterminer le parcours de gouvernance. Elle ne doit pas seulement remplir un champ de reporting.

Une décision client à fort impact, un outil interne de productivité à faible risque et un agent autonome disposant d'un accès à la production ne devraient pas suivre le même parcours d'approbation, de test et de surveillance. Chacun doit toutefois suivre un parcours défini, explicable et démontrable.

Le conseil doit s'attendre à ce que chaque décision de risque significative soit reliée à :

  • un responsable redevable,
  • une tolérance approuvée,
  • un objectif de contrôle,
  • un contrôle mis en œuvre,
  • un test,
  • et un statut opérationnel actuel.
04

Les tests et l'assurance produisent des preuves

Les tests transforment les affirmations de gouvernance en preuves examinables.

AI Verify illustre cette couche à travers onze principes de gouvernance. Chaque principe est relié à des résultats attendus, des processus et des preuves documentaires. Le framework combine des évaluations techniques et non techniques, au lieu de réduire l'IA digne de confiance à une question de performance du modèle.

Les tests et l'assurance peuvent comprendre :

  • l'évaluation de l'exactitude et des performances,
  • les tests de robustesse et de cybersécurité,
  • l'évaluation des biais et de l'équité,
  • l'évaluation de l'explicabilité,
  • les preuves de traçabilité et de qualité des données,
  • l'analyse d'impact,
  • les exercices de surveillance humaine,
  • les tests de red teaming et d'usage abusif,
  • les contrôles de reproductibilité,
  • les tests des contrôles,
  • et l'assurance indépendante.

Le test pertinent dépend de l'usage prévu. Un modèle peut obtenir de bons résultats sur un benchmark général tout en restant inadapté à une décision, une population de clients, un environnement opérationnel ou une tolérance au risque particuliers.

Affirmer qu'un humain reste « dans la boucle » ne constitue pas une description de contrôle. Le dossier de gouvernance doit préciser ce que la personne décide, quelles informations lui sont accessibles, de combien de temps elle dispose pour intervenir et si elle détient le pouvoir de modifier le résultat.

La même discipline s'applique à la certification externe. ISO/IEC 42006 définit les exigences applicables aux organismes qui auditent et certifient les systèmes de management de l'IA. Elle renforce la confiance dans le processus de certification ; elle n'élargit pas le périmètre de ce qu'ISO/IEC 42001 certifie.

Le conseil n'a pas besoin d'approuver chaque script de test. Il doit demander à la direction d'expliquer :

1. le résultat testé, 2. pourquoi la méthode est appropriée, 3. le seuil d'acceptation applicable, 4. qui peut approuver une exception, 5. combien de temps la preuve reste valable, 6. et quels changements imposent une nouvelle évaluation.

L'objectif du reporting au conseil n'est pas de reproduire l'inventaire IA. Il est de montrer si le système de gouvernance reste efficace et où une décision est requise.

Base de sources sélectionnée

  1. Règlement (UE) 2024/1689 — Artificial Intelligence Act
  2. Règlement (UE) 2026/1744 — Digital Omnibus on AI
  3. CEN-CENELEC — Artificial Intelligence and JTC 21
  4. CEN-CENELEC — EN 18286 in the Spotlight: Supporting Compliance with the AI Act
  5. ISO/IEC 42001:2023 — AI Management Systems
  6. ISO/IEC 42006:2025 — Certification of AI Management Systems
  7. NIST AI Risk Management Framework
  8. NIST Generative AI Profile — AI 600-1
  9. AI Verify Foundation — Testing Framework
  10. European Banking Authority — AI Act Implications for Banking and Payments
  11. IOSCO — Supervisory Toolkit for AI Use in Capital Markets
  12. Principes de l'OCDE sur l'IA

← Tous les briefings