Quelle est la portée appropriée pour l’audit algorithmique ?
Un audit algorithmique socio-technique de bout en bout (E2EST/AA) offre l’approche la plus complète. Il inspecte un système d’IA dans son contexte opérationnel réel, en examinant les données spécifiques utilisées et les sujets de données affectés.
Cette approche est essentielle, car les systèmes d’IA fonctionnent dans des cadres sociaux et organisationnels complexes, en utilisant des données générées par des individus et des sociétés. Négliger ces aspects socio-techniques en se concentrant uniquement sur les problèmes techniques conduirait à des évaluations incomplètes et potentiellement nuisibles.
Quels systèmes devraient être audités ?
Le processus E2EST/AA est conçu pour les systèmes algorithmiques utilisés dans :
- Le classement
- La reconnaissance d’image
- Le traitement du langage naturel
Il est applicable aux systèmes qui prennent des décisions concernant des individus ou des groupes en utilisant des sources de données connues, qu’ils reposent sur l’apprentissage automatique ou sur des méthodes informatiques plus traditionnelles. Cela englobe la majorité des systèmes utilisés dans les secteurs public et privé pour :
- L’allocation des ressources
- La catégorisation
- L’identification/vérification
…dans des domaines tels que la santé, l’éducation, la sécurité et la finance. Les applications spécifiques comprennent la détection des fraudes, les processus d’embauche, la gestion des opérations et les outils de prédiction/évaluation des risques.
Au-delà de l’évaluation des biais
Bien que l’évaluation des biais soit centrale, E2EST/AA étend sa portée. Il enquête sur :
- L’impact social plus large
- L’opportunité
- L’inclusion des utilisateurs finaux dans la phase de conception
- La disponibilité de mécanismes de recours pour les personnes concernées
Pour « réussir » un audit algorithmique, un système doit aborder les questions concernant la proportionnalité de l’impact, la participation des parties prenantes et l’allocation des ressources.
Limitations
Une limitation fondamentale de l’audit algorithmique est qu’il évalue les implémentations de système existantes. Il n’aborde pas la question fondamentale de savoir si un système devrait exister en premier lieu.
Comment mener le processus d’un audit algorithmique socio-technique de bout en bout ?
Un audit algorithmique socio-technique de bout en bout (E2EST/AA) est un processus itératif impliquant une collaboration étroite entre les auditeurs et l’équipe de développement de l’IA. Il est conçu pour inspecter les systèmes d’IA dans leur mise en œuvre réelle, leurs activités de traitement et leur contexte opérationnel, en mettant l’accent sur les données spécifiques utilisées et les personnes concernées.
Étapes clés du processus E2EST/AA
Voici une ventilation des composantes essentielles impliquées dans la réalisation d’un audit complet :
- Création de la fiche de modèle : les auditeurs commencent par collecter et examiner des informations détaillées via une « fiche de modèle ». Ce document compile des détails cruciaux concernant l’entraînement, les tests, les fonctionnalités du modèle d’IA et les motivations derrière l’ensemble de données choisi. Il sert également de référentiel centralisé pour la documentation essentielle, y compris les DPIA (analyses d’impact sur la protection des données), les approbations éthiques et les accords de partage de données.
- Développement de la carte du système : ensuite, une carte du système contextualise l’algorithme, illustrant les relations et les interactions entre le modèle algorithmique, le système technique et le processus décisionnel global. L’auditeur conçoit une version initiale de celui-ci, et l’équipe de développement la valide et la complète. Dans le cadre d’une enquête menée par une autorité de surveillance, il convient de consigner l’existence de :
- Inventaire du composant audité basé sur l’IA [Article 5.2]
- Identification des responsabilités [Chapitre IV]
- Transparence [Article 5.1.a et Chapitre III – Section 1, Articles 13.2.f et 14.2.g du Chapitre III – Section 2]
- Identification des objectifs et utilisations prévus [Article 5.1.b]
- Définition du contexte prévu du composant basé sur l’IA [Article 24.1]
- Analyse de proportionnalité et de nécessité [Article 35.7.b]
- Définition des destinataires potentiels des données [Chapitre III ; en particulier les articles 13.1.e et 14.1.e]
- Limitation du stockage des données [Article 5.1.e, exceptions Article 89.1]
- Analyse des catégories de personnes concernées [Article 35.9]
- Identification de la politique de développement des composants basés sur l’IA [Article 24.1]
- Implication du délégué à la protection des données (DPO) [Section 4 du Chapitre IV]
- Ajustement des modèles théoriques de base [Article 5.1.a]
- Pertinence du cadre méthodologique [Article 5.1.a]
- Identification de l’architecture de base du composant basé sur l’IA [Article 5.2]
- Identification des biais : Une étape essentielle consiste à identifier les moments et les sources potentiels de biais tout au long du cycle de vie du système d’IA, du prétraitement au traitement (inférence) en passant par le post-traitement (déploiement). Les auditeurs doivent documenter ce qui suit :
- Assurance qualité des données [Article 5.1]
- Définition de l’origine des sources de données [Articles 5 et 9]
- Prétraitement des données personnelles [Article 5]
- Contrôle des biais [Article 5.1.d]
- Tests de biais : Sur la base de la documentation rassemblée et de l’accès à l’équipe de développement et aux données pertinentes, l’auditeur conçoit et met en œuvre divers tests pour détecter les biais qui pourraient avoir un impact négatif sur les individus, les groupes ou la fonctionnalité globale du système. Ces tests impliquent souvent une analyse statistique, la sélection de mesures d’équité appropriées et, potentiellement, une communication avec les utilisateurs finaux ou les communautés concernées.
- Adaptation du processus de vérification et de validation du composant basé sur l’IA [Articles 5.1.b et 5.2]
- Vérification et validation du composant basé sur l’IA [Articles 5.1.a et 5.1.b]
- Performance [Article 5.1.d]
- Cohérence [Article 5.1.d]
- Stabilité et robustesse [Article 5.2]
- Traçabilité [Articles 5 et 22]
- Sécurité [Articles 5.1.f, 25 et 32]
- Audit contradictoire (facultatif) : Pour les systèmes à haut risque, et en particulier ceux qui utilisent l’apprentissage automatique non supervisé, un audit contradictoire est fortement recommandé. Cela implique de simuler les conditions réelles et les attaques potentielles pour découvrir les vulnérabilités et les biais cachés qui peuvent ne pas être apparents lors des tests standard.
Le rapport d’audit : garantir la transparence et la responsabilité
Le point culminant du processus d’audit est la génération de rapports complets. Trois principaux types de rapports d’audit doivent être générés :
- Rapport interne E2EST/AA : les auditeurs rédigent ce rapport pour saisir le processus suivi, les problèmes identifiés et les mesures d’atténuation qui ont été appliquées ou peuvent être appliquées.
- Rapport public E2EST/AA : version finale du processus d’audit, dans laquelle les auditeurs décrivent le système, la méthodologie d’audit, les mesures d’atténuation et d’amélioration mises en œuvre, ainsi que les recommandations supplémentaires, le cas échéant.
- Rapports périodiques E2EST/AA : ces rapports d’audit de suivi doivent fournir des garanties que les développeurs du système ont continué à tester les biais, à mettre en œuvre des mesures d’atténuation et à contrôler l’impact.
Quels enseignements peut-on tirer de l’examen des moments et des sources de biais dans un système d’IA ?
L’analyse des biais dans les systèmes d’IA va au-delà de la simple identification des groupes protégés et du calcul du traitement disparate. Une approche globale, telle que l’audit algorithmique socio-technique de bout en bout (E2EST/AA), nécessite l’examen des moments et des sources de biais tout au long du cycle de vie de l’IA afin de prévenir les résultats injustes et les infractions réglementaires.
Comprendre les moments de biais
L’E2EST/AA identifie les moments clés du cycle de vie de l’IA où les biais peuvent s’insinuer :
- Prétraitement : De la collecte initiale des données (« Monde → Données ») à leur transformation en variables utilisables (« Échantillon → Variables + Valeurs »), les biais peuvent provenir de la manière dont les données sont collectées, de qui est représenté et de la manière dont les informations sont structurées.
- Traitement interne (Inférence du modèle) : Ici, les biais préexistants peuvent être amplifiés à mesure que l’IA apprend des schémas à partir des données (« Variables + Valeurs → Schémas ») et fait des prédictions (« Schémas → Prédictions »).
- Post-traitement (Déploiement du modèle) : Les impacts des biais se manifestent lorsque les prédictions se transforment en décisions (« Prédictions → Décisions »), et que ces décisions ont un impact sur le monde réel (« Décisions → Monde »).
Identifier les sources de biais
Identifier l’origine des biais est essentiel pour une atténuation efficace. L’E2EST/AA met en évidence plusieurs sources :
- Biais technologique : Cela inclut le « biais techno-solutionniste » (dépendance excessive à la technologie), la « simplification excessive », la « vectorisation partielle ou biaisée » et le biais de « variable omise ».
- Biais liés aux données : Le « biais de sélection », le « biais historique », le « biais d’étiquetage », le « biais de généralisation », le « biais statistique », le « biais de mesure », le « biais de confidentialité » et le « biais d’agrégation » entrent dans cette catégorie.
- Biais cognitif : Le « sur-apprentissage et le sous-apprentissage », la « persuasion de la main chaude » et le « biais d’automatisation » représentent des erreurs cognitives dans le développement du modèle.
- Biais de déploiement : Considérations sur le « biais des tests de référence » et la « visualisation des données ».
Implications pratiques et préoccupations réglementaires
Le fait de ne pas identifier et traiter ces biais peut entraîner :
- Violation des droits individuels
- Renforcement des stéréotypes
- Décisions inefficaces ou nuisibles
- Discrimination à l’encontre des personnes et des groupes
- Reproduction des inégalités sociétales
L’auditeur doit enregistrer l’existence de procédures documentées pour gérer et assurer une bonne gouvernance des données, ce qui permet de vérifier et de fournir des garanties quant à l’exactitude, l’intégrité, la véracité, la mise à jour et l’adéquation des ensembles de données utilisés pour l’entraînement, les tests et le fonctionnement.
Dans quelles circonstances un audit contradictoire est-il un ajout bénéfique au processus ?
Le document suggère que les audits contradictoires, bien qu’optionnels, offrent une valeur significative dans certains scénarios. Ces audits servent de filet de sécurité essentiel, révélant des problèmes que même les méthodologies d’audit standard les plus méticuleuses pourraient manquer.
Systèmes à haut risque
Pour les systèmes d’IA à haut risque, et en particulier ceux utilisant des modèles d’apprentissage automatique (ML) non supervisés, les audits contradictoires sont « fortement recommandés ». La complexité et l’opacité de ces systèmes peuvent rendre difficile le traçage des attributs du modèle par des moyens conventionnels. La rétro-ingénierie, facilitée par les techniques contradictoires, devient une approche précieuse.
Vérification des informations d’audit
Les audits contradictoires sont également bénéfiques pour vérifier l’exhaustivité et l’exactitude des informations fournies lors du processus d’audit initial. Ils fournissent une couche de contrôle supplémentaire, garantissant que les biais et les risques potentiels ne sont pas négligés.
Détection des biais dans le monde réel
Ces audits sont particulièrement efficaces pour détecter :
- Les variables omises qui ne font surface que lorsque le système d’IA fonctionne dans des environnements de production réels.
- Les proxys qui conduisent à un traitement injuste et à d’autres impacts néfastes.
- Les biais d’apprentissage : un phénomène par lequel les systèmes de ML non supervisés incorporent des variables et des étiquettes provenant de données d’entraînement qui n’étaient pas initialement anticipées, ce qui entraîne des résultats négatifs imprévus. Ceux-ci ne sont détectables que par une analyse à grande échelle des données d’impact.
Limitations d’accès
Lorsque les communautés concernées ou les organismes de réglementation n’ont pas d’accès direct à un système algorithmique, des audits contradictoires peuvent être menés en tant qu’évaluations autonomes. Cela permet une vérification indépendante du comportement et de l’impact du système.
Techniques de collecte de données
La réalisation d’un audit contradictoire implique la collecte de données d’impact à grande échelle, en utilisant des techniques telles que :
- L’extraction de sources Web.
- Les entretiens avec les utilisateurs finaux.
- L’externalisation des données des utilisateurs finaux.
- L’utilisation de « sockpuppeting » – la création de faux profils avec des caractéristiques spécifiques pour déclencher et analyser les résultats du modèle.
Essentiellement, les audits contradictoires sont plus utiles lorsqu’il s’agit de systèmes d’IA complexes et à enjeux élevés, lors de la vérification des conclusions d’audit et lorsque des évaluations indépendantes sont nécessaires en raison de limitations d’accès.
french
Quels sont les éléments essentiels d’un rapport d’audit efficace ?
Du point de vue d’un journaliste technologique spécialisé dans la gouvernance de l’IA et la conformité, le rapport d’audit est le moment de vérité. Il ne s’agit pas seulement de cocher des cases ; il s’agit de bâtir la confiance et de garantir que les systèmes d’IA sont conformes aux valeurs sociétales et aux cadres juridiques. Voici ce qu’un rapport d’audit de l’IA efficace doit inclure :
Rapports d’audit de base
-
Rapport E2EST/AA interne avec mesures d’atténuation et annexes : Ce rapport documente le processus d’audit, identifie les problèmes et détaille les stratégies d’atténuation appliquées ou applicables. Les auditeurs d’algorithmes *devraient* être proactifs, suggérer des solutions, surveiller la mise en œuvre et rendre compte des résultats finaux.
-
Rapport E2EST/AA public : Il s’agit du document à destination externe qui décrit le système, la méthodologie d’audit, les efforts d’atténuation, les améliorations et les recommandations futures. Il doit surtout proposer la fréquence et la méthodologie (y compris les indicateurs spécifiques) des audits ultérieurs.
-
Rapports E2EST/AA périodiques : Il s’agit de suivis récurrents. Ils doivent faire référence au rapport d’audit initial, confirmant que les développeurs ont continué à tester les biais, à déployer des stratégies d’atténuation et à suivre leur impact.
Dans le cadre d’une enquête menée par une Autorité de Contrôle, les rapports d’audit efficaces doivent contenir des éléments qui permettent de suivre :
- Identification et transparence du composant basé sur l’IA, l’historique des versions de l’évolution du composant d’IA.
- Identification des responsabilités associées à chaque étape du traitement.
- Transparence des sources de données.
- Identification de la définition des objectifs visés, du contexte des destinataires potentiels des données, des limitations du stockage des données et de l’analyse des catégories de personnes concernées.
- Identification de la politique de développement du composant basé sur l’IA.
- Documenter les modèles théoriques de base.
- Documenter le cadre méthodologique.
- Documenter l’architecture de base du composant basé sur l’IA.
Éléments clés pour tous les rapports :
Documentation : Toutes les interactions et les documents échangés doivent être compilés et conservés dans les dossiers par les propriétaires et les auditeurs du système.
Gestion des risques :
- Analyse des risques développée en relation avec les exigences de sécurité et de confidentialité.
- Normes et meilleures pratiques prises en considération pour la configuration et le développement sécurisés du composant d’IA.
Profils d’explicabilité Les rapports d’audit doivent inclure le profilage de l’explicabilité afin d’expliquer les conséquences, de garantir la lisibilité du code, la compression logique et la cohérence interne.
Audits périodiques : Selon la complexité du système, des versions internes et publiques des audits périodiques peuvent être nécessaires.
