Ce qu'est un cadre de contrôles IA et pourquoi il est important

Les politiques de gouvernance de l'IA ne sont efficaces qu'à la mesure des contrôles qui les opérationnalisent. Une politique qui indique que « les systèmes d'IA doivent faire l'objet d'une surveillance des biais » ne signifie rien sans contrôles précisant : qui surveille, quoi surveiller, comment tester les biais, ce qui constitue un niveau de biais inacceptable, et ce qui se passe lorsqu'un biais est détecté. Un cadre de contrôles IA est le document qui répond à ces questions pour chaque risque IA significatif au sein de votre organisation.

La nécessité d'un cadre de contrôles documenté est désormais explicite dans les attentes réglementaires. Les exigences de documentation technique de l'AI Act de l'UE pour l'IA à haut risque imposent de fait une approche de documentation des contrôles. La CPS 230 de l'APRA (Australian Prudential Regulation Authority, l'autorité australienne de régulation prudentielle) exige des cadres de gestion du risque opérationnel incluant des contrôles pour les risques opérationnels significatifs, l'IA relève désormais clairement de ce périmètre. Le Consumer Duty de la FCA (Financial Conduct Authority, l'autorité britannique de conduite financière) exige des entreprises qu'elles démontrent, et non se contentent d'affirmer, que leur IA produit de bons résultats. Le NAIC Model Bulletin exige un programme de gouvernance de l'IA comportant des éléments de contrôles documentés. Les auditeurs internes et externes demandent de plus en plus des preuves de contrôles IA dans le cadre des évaluations de risques standard.

Les trois types de contrôles IA

Les contrôles préventifs empêchent la survenue des risques liés à l'IA. Ils comprennent : les processus de revue préalable au déploiement (exigeant une évaluation des risques, des tests de biais et une approbation avant la mise en production d'un système d'IA) ; la gouvernance des données d'entraînement (exigences d'approbation des jeux de données d'entraînement, normes de qualité des données, documentation du consentement) ; les contrôles d'accès (limitant qui peut modifier les paramètres du modèle d'IA ou réentraîner les modèles) ; et les contrôles de gestion du changement (exigeant une validation lors des mises à jour des modèles d'IA).

Les contrôles détectifs identifient les risques liés à l'IA qui se sont matérialisés. Ils comprennent : la surveillance des performances (suivi de l'exactitude, de la précision, du rappel et d'autres indicateurs du modèle par rapport à des seuils définis) ; les tests de disparité démographique (test régulier visant à déterminer si les résultats de l'IA diffèrent de manière significative selon les groupes démographiques) ; la revue de la qualité des résultats (revue humaine des résultats de l'IA pour les décisions à fort enjeu, ou échantillonnage statistique des décisions de l'IA à des fins de contrôle qualité) ; la détection d'anomalies (identification de schémas inhabituels dans les entrées ou sorties de l'IA pouvant indiquer une défaillance du système ou une attaque) ; et la surveillance des réclamations (suivi des réclamations clients pouvant signaler des problèmes de qualité des décisions de l'IA).

Les contrôles correctifs remédient aux risques IA identifiés. Ils comprennent : les procédures de réponse aux incidents (processus définis pour répondre aux défaillances de l'IA, y compris l'autorité de suspendre les systèmes d'IA) ; la capacité de retour à une version antérieure du modèle (capacité technique à revenir à des versions précédentes du modèle) ; la réparation des parties concernées (processus d'identification et d'indemnisation des personnes lésées par des décisions de l'IA) ; l'analyse des causes profondes (enquête structurée sur les incidents liés à l'IA visant à identifier et traiter les causes sous-jacentes) ; et la notification réglementaire (processus de notification aux régulateurs des incidents IA significatifs, comme requis).

Associer les contrôles aux risques

Chaque contrôle doit être associé au risque IA spécifique qu'il traite. Un simple tableau de correspondance risques-contrôles constitue la base : recenser chaque risque IA significatif, identifier les contrôles traitant ce risque (préventifs, détectifs, correctifs), préciser le responsable du contrôle, et définir la méthodologie et la fréquence de test.

Catégories de risques IA courantes et leurs contrôles principaux : la dégradation de la précision du modèle, détectée par la surveillance des performances par rapport à des indicateurs de référence, corrigée par des protocoles de réentraînement. Le biais des données d'entraînement, prévenu par une revue de gouvernance des données incluant une évaluation de la représentativité démographique, détecté par des tests de disparité démographique des résultats du modèle. La défaillance de l'IA tierce, prévenue par une diligence raisonnable des fournisseurs, détectée par la surveillance des SLA fournisseurs et des contrôles de qualité des résultats, corrigée par des recours contractuels et une planification de continuité. Les hallucinations dans l'IA générative, prévenues en limitant les applications à fort enjeu, détectées par un échantillonnage de revue humaine, corrigées par des processus de correction des résultats. L'injection de prompts, prévenue par la validation des entrées et une liste blanche autorisée, détectée par la surveillance des résultats pour repérer un contenu anormal.

Tests de contrôle et éléments probants

Chaque contrôle IA doit être testé régulièrement pour confirmer qu'il fonctionne efficacement. Le test de contrôle doit préciser : ce qui est testé (le contrôle spécifique), comment il est testé (la méthodologie de test), à quelle fréquence il est testé, qui le teste (le responsable), et quels éléments probants sont produits (la documentation démontrant que le test a été réalisé et son résultat). Ce sont ces éléments probants que l'audit interne examinera et que les régulateurs demanderont lorsqu'ils examineront la gouvernance de l'IA.

Pour les contrôles préventifs : le test consiste généralement à examiner un échantillon de cas où le contrôle aurait dû s'appliquer (par exemple, examiner un échantillon de revues préalables au déploiement pour confirmer qu'elles ont été réalisées, documentées et qu'elles comprenaient les éléments requis). Pour les contrôles détectifs : le test consiste à exécuter le contrôle sur un scénario connu (par exemple, tester si le système de surveillance des biais identifie correctement un jeu de données synthétique présentant une disparité démographique connue). Pour les contrôles correctifs : le test consiste à examiner un échantillon d'incidents pour confirmer que le processus correctif a été suivi (par exemple, examiner les dossiers d'incidents pour confirmer que l'analyse des causes profondes a été réalisée dans le délai requis).

Les trois lignes de défense pour l'IA

Le modèle des trois lignes de défense s'applique directement à la gouvernance de l'IA. Première ligne (équipes métiers et technologie) : elle exploite les systèmes d'IA, est propriétaire des contrôles de première ligne, assure une surveillance quotidienne et est responsable des risques IA dans son périmètre. Deuxième ligne (risque et conformité) : elle conçoit le cadre de contrôles IA, définit l'appétence au risque et les seuils, assure la supervision de l'efficacité des contrôles de première ligne, et rend compte à la direction générale et au conseil d'administration. Troisième ligne (audit interne) : elle évalue de manière indépendante si le cadre de contrôles IA est conçu de manière appropriée et si les contrôles fonctionnent efficacement.

Il est essentiel de clarifier quelle ligne est responsable de quoi. Les modes de défaillance courants sont les suivants : la première ligne traite l'IA comme une simple question technologique et ne s'approprie pas le risque métier ; la deuxième ligne cherche à exploiter les contrôles plutôt qu'à les superviser (brouillant ainsi la frontière avec la première ligne) ; l'audit interne ne dispose pas de l'expertise IA nécessaire pour tester efficacement les contrôles IA. Chacune de ces situations crée des lacunes que les régulateurs et les événements finiront par mettre en évidence.

Pour aller plus loin : ISO/IEC 42001

Lectures complémentaires

Pour aller plus loin : ISO 42001