Écart entre conformité et sécurité de l'IA

Le principal système d’IA de décision de crédit d’une fintech de prêt aux particuliers était un modèle d’ensemble à gradient boosting, un type de modèle très précis mais intrinsèquement opaque qui produit des décisions par des interactions complexes entre des centaines de valeurs de variables sur plusieurs étapes de boosting. Le modèle avait été choisi pour ses performances prédictives supérieures, qui se traduisaient directement par une meilleure discrimination du risque de crédit et des taux de défaut plus faibles. La documentation de conformité du fournisseur était complète : certification de conformité au GDPR, rapport SOC 2 Type II, certification ISO 27001 et revue éthique interne de l’IA. Le programme de conformité était réel : le fournisseur avait beaucoup investi dans la protection des données, les contrôles de sécurité et les processus de revue éthique. Ce que le programme de conformité n’avait pas traité spécifiquement, c’était la conformité du modèle à l’article 22 du GDPR, qui crée pour les personnes le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou des effets similaires significatifs, ainsi que le droit d’obtenir des informations utiles concernant la logique sous-jacente. Les décisions de crédit prises par le modèle étaient exactement le type de décisions automatisées auquel s’applique l’article 22. La logique interne du modèle (les poids d’importance des variables dans les multiples arbres de gradient boosting, les effets d’interaction entre variables, les valeurs de seuil à chaque division) ne pouvait pas être exprimée sous une forme qu’un profane puisse réellement comprendre comme une explication de sa propre décision de crédit. Le fournisseur était conforme au GDPR. Il n’était pas conforme à l’article 22 pour les décisions de crédit automatisées. Ce n’est pas la même chose.

Qu’est-ce que l’écart entre conformité et sécurité de l’IA, réellement ?

L’écart entre conformité et sécurité de l’IA désigne la distinction entre la conformité d’un système d’IA aux réglementations générales de protection des données et de sécurité (le GDPR pour le traitement des données, SOC 2 pour les contrôles de sécurité, ISO 27001 pour la gestion de la sécurité de l’information) et sa conformité aux exigences spécifiques applicables aux systèmes d’IA qui prennent des décisions automatisées lourdes de conséquences : obligations d’explicabilité, exigences de contrôle humain, obligations d’évaluation de l’équité et exigences réglementaires propres à l’IA. Un système d’IA peut être pleinement conforme aux exigences générales de protection des données et de sécurité tout en n’étant pas conforme aux réglementations spécifiques qui encadrent la prise de décision automatisée.

Le problème de l’explicabilité au titre de l’article 22 est l’écart de conformité propre à l’IA le plus significatif sur le plan opérationnel. L’article 22 du GDPR crée pour les personnes concernées le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou des effets similaires significatifs, ainsi que le droit d’obtenir des informations utiles concernant la logique sous-jacente à ces décisions. De nombreux modèles d’IA à haute performance (ensembles de gradient boosting, réseaux de neurones profonds, méthodes d’ensemble complexes) produisent des décisions par des interactions qui ne se prêtent pas naturellement à une explication utile qu’un profane pourrait comprendre. Déployer ces modèles pour des décisions de crédit, d’assurance, d’emploi ou d’autres décisions ayant des effets importants sur les personnes crée des obligations de conformité à l’article 22 que ces modèles peuvent être structurellement incapables de respecter.

La dimension de conformité en matière d’équité constitue un deuxième écart réglementaire propre à l’IA. Les régulateurs des services financiers (le CFPB aux États-Unis, la FCA au Royaume-Uni, les régulateurs de toute l’UE) appliquent de plus en plus les exigences de non-discrimination aux décisions de crédit et d’assurance prises par l’IA. Un modèle d’IA qui produit un impact disproportionné sur des catégories protégées, même si aucune variable relative à une catégorie protégée ne figure parmi ses entrées, peut enfreindre les exigences de prêt équitable. La conformité générale au GDPR et en matière de sécurité ne traite pas l’équité. Des modèles qui n’ont pas été spécifiquement testés pour l’impact disproportionné peuvent enfreindre les exigences de prêt équitable tout en étant pleinement conformes aux exigences de protection des données.

Les exigences du règlement européen sur l’IA relatives aux systèmes à haut risque créent la troisième dimension de conformité. La catégorie à haut risque du règlement européen sur l’IA comprend les systèmes d’IA utilisés pour la notation de crédit, ainsi que les systèmes utilisés dans les décisions d’emploi, l’éducation, la santé et les activités répressives. Les systèmes d’IA à haut risque sont soumis à des exigences obligatoires (analyses d’impact sur les droits fondamentaux, documentation technique, journalisation du fonctionnement, transparence envers les personnes concernées, contrôle humain) qui vont bien au-delà des exigences des réglementations générales sur la protection des données. Un système d’IA conforme au GDPR peut en même temps ne pas être conforme aux exigences du règlement européen sur l’IA relatives aux systèmes à haut risque.

Pourquoi c’est important

L’écart entre conformité et sécurité de l’IA est important pour le TPRM, car l’entreprise qui déploie le système d’IA d’un fournisseur dans un cas d’usage réglementé hérite des obligations de conformité de ce cas d’usage, que la documentation de conformité du fournisseur couvre ou non ces obligations. L’entreprise dont les décisions de crédit sont prises par le système d’IA d’un fournisseur incapable de fournir les explications requises par l’article 22 engage sa responsabilité au titre de l’article 22, quelle que soit la certification GDPR du fournisseur.

Là où la plupart des équipes se trompent

La défaillance la plus constante consiste à accepter des certifications générales de conformité (GDPR, SOC 2, ISO 27001) comme preuve de conformité réglementaire propre à l’IA. Les certifications générales couvrent des exigences générales. Les réglementations propres à l’IA imposent des obligations spécifiques que les certifications générales ne traitent pas.

• Conformité générale acceptée comme conformité propre à l’IA
• Explicabilité au titre de l’article 22 non évaluée pour les modèles de prise de décision automatisée
• Tests d’équité non évalués pour les modèles de crédit, d’assurance et d’emploi
• Exigences du règlement européen sur l’IA relatives au haut risque non évaluées pour les systèmes concernés
• Capacité d’explicabilité du modèle non adaptée à l’obligation réglementaire

À quoi ressemblent les bonnes pratiques

Les programmes matures de conformité de l’IA évaluent chaque système d’IA au regard des réglementations précises qui s’appliquent à son cas d’usage, et pas seulement des normes générales de protection des données et de sécurité, et vérifient que la capacité d’explicabilité du modèle répond aux obligations légales d’explication que crée ce cas d’usage.

• Évaluation de la conformité propre au cas d’usage : article 22, prêt équitable, règlement européen sur l’IA selon le cas d’usage
• Capacité d’explicabilité adaptée à l’obligation : type de modèle évalué au regard des exigences d’explication
• Tests d’équité pour l’impact disproportionné sur les catégories protégées
• Évaluation au titre du régime à haut risque du règlement européen sur l’IA pour les cas d’usage concernés
• Documentation des écarts de conformité : obligations de conformité actuellement non respectées

Outils

Explicabilité : SHAP, LIME, IBM Watson OpenScale pour des explications conformes au GDPR

Les outils d’explicabilité des modèles, SHAP (SHapley Additive exPlanations) et LIME (Local Interpretable Model-Agnostic Explanations), génèrent pour les décisions individuelles des explications fondées sur la contribution des variables, qui peuvent servir de base aux explications requises par l’article 22. Pour les professionnels du TPRM, demander si le modèle de prise de décision automatisée du fournisseur utilise des outils d’explicabilité capables de générer des explications individuelles juridiquement suffisantes constitue une question précise sur la conformité à l’article 22.

Tests d’équité : AI Fairness 360 (IBM), Fairlearn (Microsoft) pour l’évaluation de l’impact disproportionné

Les cadres de test d’équité évaluent les modèles pour détecter un impact disproportionné sur les catégories protégées, une exigence pour les systèmes d’IA utilisés dans le crédit, l’assurance, l’emploi et d’autres décisions réglementées. Pour les professionnels du TPRM, demander si le modèle du fournisseur a été évalué pour l’impact disproportionné à l’aide d’un cadre de test d’équité constitue une question précise sur la conformité en matière de prêt équitable.

Enjeux de gouvernance

La difficulté de gouvernance liée aux écarts de conformité de l’IA tient à la complexité réglementaire d’une juridiction à l’autre. L’article 22 s’applique dans l’UE. Les exigences de prêt équitable s’appliquent aux États-Unis. Le règlement européen sur l’IA s’applique dans tous les États membres de l’UE selon des calendriers de mise en œuvre différents. Un produit d’IA déployé dans plusieurs juridictions peut être soumis à des obligations de conformité différentes dans chacune d’elles. La solution de gouvernance est une évaluation de la conformité par cas d’usage, qui évalue chaque cas d’usage précis de l’IA au regard de toutes les réglementations applicables dans toutes les juridictions concernées.

• Réaliser une évaluation de la conformité propre au cas d’usage pour chaque déploiement d’IA
• Évaluer l’explicabilité au titre de l’article 22 pour la prise de décision automatisée
• Réaliser des tests d’équité pour les modèles de crédit, d’assurance et d’emploi
• Évaluer les exigences du règlement européen sur l’IA relatives au haut risque pour les systèmes concernés
• Cartographier les obligations de conformité par juridiction pour les déploiements transfrontaliers

Si vous êtes une petite équipe

Pour chaque système d’IA d’un fournisseur qui prend ou influence de manière significative des décisions ayant des effets importants sur des personnes (crédit, assurance, emploi, santé, éducation), posez deux questions propres à la conformité. Premièrement : ce système génère-t-il pour chaque décision des explications individuelles conformes à l’article 22, et pouvez-vous fournir un exemple d’explication dans le format que vous fourniriez à une personne concernée ? Deuxièmement : ce système a-t-il été testé pour détecter un impact disproportionné sur des catégories protégées, et pouvez-vous fournir les résultats de l’évaluation de l’impact disproportionné ? Ces deux questions révèlent les écarts de conformité propres à l’IA que les certifications générales ne traitent pas.

• Demander un exemple d’explication individuelle au titre de l’article 22
• Demander les résultats de l’évaluation de l’impact disproportionné
• Évaluer la classification à haut risque au titre du règlement européen sur l’IA
• Cartographier les obligations de conformité propres au cas d’usage

Ce qu’il faut exiger

Demandez directement :

« Pour votre IA de décision de crédit, pouvez-vous fournir un exemple de l’explication individuelle conforme à l’article 22 que vous fourniriez à un demandeur, et pouvez-vous fournir vos derniers résultats d’évaluation de l’impact disproportionné sur les catégories protégées ? »

Preuves attendues

• Exemple d’explication individuelle au titre de l’article 22
• Résultats de l’évaluation de l’impact disproportionné
• Évaluation du haut risque au titre du règlement européen sur l’IA
• Documentation de la méthodologie d’explicabilité

Il faut demander l’exemple d’explication au titre de l’article 22 à un fournisseur qui confirme sa conformité au GDPR. La conformité au GDPR couvre le traitement des données. La conformité à l’article 22 couvre la prise de décision automatisée. Même règlement, obligations différentes.

Comment le prouver

• Registres d’évaluation de la conformité à l’article 22
• Registres des tests d’impact disproportionné
• Évaluation de la conformité au règlement européen sur l’IA
• Documentation de la conformité propre au cas d’usage

À retenir

Conformité au GDPR : confirmée. SOC 2 : confirmé. Droit à l’explication de l’article 22 pour les décisions de crédit automatisées : l’ensemble de gradient boosting ne peut pas le satisfaire. La conformité au GDPR et la conformité à l’article 22 sont toutes deux des obligations du GDPR. Elles portent sur des choses différentes. La conformité en matière de traitement des données et la conformité en matière de prise de décision automatisée sont toutes deux requises. Certifier l’une ne certifie pas l’autre. L’évaluation de la conformité propre au cas d’usage (article 22 pour la prise de décision automatisée, prêt équitable pour le crédit et l’assurance, exigences du règlement européen sur l’IA relatives au haut risque pour les systèmes concernés) est la couche supplémentaire que les certifications générales de conformité n’apportent pas. Demandez l’exemple d’explication au titre de l’article 22. Demandez les résultats sur l’impact disproportionné. Les certifications générales sont le plancher. La conformité propre au cas d’usage est l’obligation.