Système de gestion des risques AI Act : appliquer l’article 9.
Le système de gestion des risques de l’AI Act est un processus continu, pas une analyse ponctuelle jointe au dossier de conformité. Il commence avec la finalité et les personnes exposées, guide la conception et les tests, puis se nourrit des incidents et de la surveillance après commercialisation.
L’article 9 impose aux fournisseurs de systèmes d’IA à haut risque un processus continu qui identifie les risques connus et prévisibles, les évalue, adopte des mesures ciblées, teste le système avec des métriques définies et juge le risque résiduel. Le dispositif est revu pendant tout le cycle de vie.
Cluster éditorial : Conformité opérationnelle AI Act · Intention : Mettre en œuvre le système de gestion des risques prévu par l’article 9
En bref
L’essentiel à retenir
01
Processus continu et versionné
02
Risques en usage prévu et mauvais usage
03
Mesures hiérarchisées et testées
04
Surveillance qui alimente les revues
01
Définir le système et son contexte
Fixez la finalité prévue, la version, les utilisateurs, les personnes affectées, les entrées, les sorties et l’environnement. Décrivez les décisions influencées et les interactions avec d’autres systèmes. Sans ce périmètre, le registre de risques mélange des scénarios qui ne concernent pas le produit ou oublie ceux liés à son intégration.
Associez les fonctions métier, techniques, juridiques, sécurité et qualité. Les personnes affectées ou leurs représentants apportent une compréhension des conséquences que l’équipe produit peut sous-estimer. Définissez les critères de gravité et de vraisemblance avant de classer les scénarios. Conservez les désaccords et hypothèses.
Examinez l’usage conforme à la finalité et les mauvaises utilisations raisonnablement prévisibles. Couvrez la santé, la sécurité et les droits fondamentaux. Décrivez des scénarios : qui est exposé, quel événement se produit, quelle conséquence apparaît et quels facteurs l’aggravent. Une liste générique comme « biais » ou « erreur » est trop vague pour concevoir un contrôle.
Utilisez les incidents internes, les retours de déployeurs, les tests, la littérature et la surveillance du marché. Portez une attention particulière aux mineurs et groupes vulnérables lorsque la finalité peut les affecter. Mettez à jour le registre lorsque la population, les données, le modèle ou l’environnement changent.
Estimez la gravité, la vraisemblance, l’exposition et la capacité de détection avec des échelles définies. Distinguez les faits mesurés, les estimations et les inconnues. Un score unique ne doit pas effacer un dommage rare mais irréversible. Ajoutez des seuils d’escalade pour les scénarios nécessitant une expertise ou une décision de direction.
Évaluez aussi l’interaction des exigences. Une mesure de sécurité peut réduire l’explicabilité, une optimisation de performance peut accroître un biais et une alerte trop fréquente peut affaiblir la supervision. Documentez les arbitrages et les personnes qui acceptent le risque résiduel. La décision doit être compréhensible sans reconstruire tous les échanges.
Cherchez d’abord à éliminer ou réduire le risque par la conception. Ajoutez ensuite des mesures de contrôle pour ce qui ne peut pas être supprimé, puis fournissez les informations et formations nécessaires au déployeur. Cette hiérarchie évite de transférer un défaut de conception vers l’utilisateur sous la forme d’une consigne impossible.
Chaque mesure reçoit un propriétaire, un critère de réussite, une date et une preuve. Pour une erreur critique, prévoyez un mode dégradé ou une interruption sûre. Pour un biais, examinez les données, le modèle, le seuil et le processus humain. Pour une mauvaise utilisation, combinez restriction technique, consigne, surveillance et contrat.
Tester avec des métriques définies avant le résultat
Définissez les métriques et seuils avant le test afin d’éviter d’adapter le critère au résultat obtenu. Couvrez les situations normales, limites, groupes pertinents, erreurs, attaques et scénarios de supervision. Vérifiez que la version testée correspond au système destiné au marché ou au service.
Documentez les données, l’environnement, les outils, les écarts et la décision. Un test réussi dans un laboratoire ne garantit pas la performance dans le contexte réel. Prévoyez une recette du déployeur et un suivi après mise en service. Les écarts critiques bloquent la décision ou conduisent à une limitation explicite.
Les données de surveillance après commercialisation, les plaintes, les incidents, les overrides humains et les changements de performance alimentent le registre. Définissez la fréquence de revue et les signaux qui imposent une analyse immédiate. Un nouvel usage peut rendre pertinent un risque auparavant hors périmètre.
Conservez l’historique des risques, mesures, tests et décisions. Reliez-le à la documentation technique et au système de gestion de la qualité. Une revue de direction examine les risques résiduels, les mesures en retard et les décisions de correction, limitation ou retrait. Le dispositif devient ainsi une capacité de pilotage plutôt qu’un fichier figé.
