Audits Algorithmiques : Un Guide Pratique pour l’Équité, la Transparence et la Responsabilité dans l’IA

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.