Registre des décisions IA : documenter la traçabilité des risques et des contrôles pour les audits

Définition et utilité du registre des décisions IA

Un registre des décisions IA est un historique structuré des choix pertinents concernant la conception, la configuration, la validation, le déploiement et les modifications d'un système. Son utilité ne réside pas dans l'accumulation de documents, mais dans la capacité à reconstituer ce qui a été décidé, pourquoi, qui a pris la décision, quel contrôle a été mis en œuvre et quelle preuve atteste que ce contrôle a été vérifié. Il peut couvrir des décisions techniques et organisationnelles, allant du choix d'un seuil à la définition de qui examine les sorties du système.

Ce registre aide à expliquer le processus aux équipes internes, aux auditeurs ou aux autorités, mais ne constitue pas à lui seul une preuve de conformité. Il ne remplace pas la documentation technique, les journaux opérationnels, l'évaluation des risques ni les obligations légales applicables à une organisation ou à un système spécifique. Les directives institutionnelles sur la conservation des registres s'appliquent souvent à des contextes spécifiques, comme les systèmes à haut risque, et ne doivent pas être extrapolées automatiquement à tout outil d'IA.

Il est essentiel de délimiter le périmètre dès le départ. Indiquez à quel système et à quelle version le registre se réfère, quels usages prévus il couvre, qui le maintient et quels types de décisions doivent être consignés. Une modification n'altérant ni le comportement ni l'usage peut être documentée de manière synthétique ; un changement de données, de seuils, de population cible ou de supervision humaine peut nécessiter une évaluation plus complète. La décision de consigner et le niveau de détail doivent être proportionnels à l'impact et au contexte, sans être présentés comme une règle légale universelle.

Champs pratiques pour documenter chaque décision

Il n'existe pas de jeu de champs minimal et suffisant pour tous les systèmes, usages et obligations. Comme base opérationnelle, une entrée doit permettre d'identifier le système et sa version, la date, la personne responsable, la décision prise, le risque ou le besoin qui l'a motivée, le contrôle associé, la preuve disponible et le résultat de la vérification. Ajouter l'état, les limites et une date ou condition de révision facilite la maintenance ultérieure.

Une entrée claire distingue risque, contrôle et preuve. Le risque décrit un dommage possible dans un contexte spécifique ; le contrôle est une mesure concrète destinée à le prévenir, le réduire ou le détecter ; la preuve montre ce qui a été vérifié et avec quel résultat. Par exemple, « erreurs de classification » est trop vague si la population et l'usage ne sont pas identifiés. « Maintien d'une révision humaine pour les cas de faible confiance » décrit une mesure, mais il reste à préciser comment un cas de faible confiance est identifié et comment la révision est démontrée.

Enregistrez des liens stables vers les artefacts, pas seulement des noms génériques. Une référence utile peut inclure un identifiant, une version, une date, un emplacement interne autorisé et un responsable de la garde. Conservez les données personnelles ou confidentielles avec des contrôles d'accès appropriés et évitez de copier dans le registre du contenu sensible inutile. Si une preuve devient indisponible, notez l'incident et l'action pour la récupérer ou répéter la vérification.

Lier les risques, les contrôles et les preuves

Construisez une chaîne traçable : risque concret, objectif de mitigation, contrôle implémenté, méthode de vérification et résultat. Chaque maillon doit pouvoir être suivi grâce à des identifiants cohérents. Si un contrôle mitige plusieurs risques, enregistrez chaque relation ; si un risque nécessite plusieurs mesures, documentez chaque contrôle et les dépendances entre eux. Cela évite qu'une liste de risques reste dissociée des activités d'ingénierie ou des décisions opérationnelles.

La preuve doit correspondre à la configuration et à l'usage évalués. Un rapport de test sur une version antérieure peut servir d'antécédent, mais ne démontre pas automatiquement l'efficacité d'un changement ultérieur. Indiquez l'environnement, les données ou scénarios utilisés, les critères d'acceptation, le résultat et les limites. Lorsqu'un test ne couvre pas toutes les conditions réelles, notez cette lacune et la mesure de supervision ou l'action supplémentaire appliquée.

Les tests quantitatifs ne sont pas toujours suffisants. Pour une mesure organisationnelle — comme la révision humaine — il peut être pertinent de conserver les procédures en vigueur, des échantillons de cas révisés, des journaux d'escalade et des vérifications que le personnel a reçu les instructions. Le niveau de preuve dépend du risque et de l'affirmation à soutenir. L'audit algorithmique peut aider à structurer la revue des mitigations, mais une recommandation générale ne démontre pas à elle seule qu'une mesure concrète a été appliquée ou est efficace.

Processus de création et de maintenance

Commencez par un inventaire des systèmes et des versions, et définissez qui a l'autorité d'approuver les décisions et qui maintient les preuves. Convenez de conventions communes pour identifier les risques, les contrôles et les artefacts. Chaque entrée doit avoir un responsable ; une équipe générique ou une boîte mail sans fonction assignée complique le suivi. Établissez également qui peut accéder au registre et comment les modifications et corrections sont gérées.

Notez les décisions au moment où elles sont prises ou lorsque la preuve est validée, et non des mois après un audit. Liez chaque changement pertinent à la version affectée et conservez un historique permettant de comprendre quand le registre a été mis à jour. Lors de la revue d'une entrée, vérifiez si le risque est toujours d'actualité, si le contrôle est toujours appliqué, si la preuve correspond à la version actuelle et si les limites ou actions en suspens restent ouvertes.

Il n'existe pas de fréquence de révision unique à recommander comme obligation générale pour tout système. Définissez une révision périodique proportionnelle au contexte et ajoutez des révisions déclenchées par des événements : nouvelle version, changement de données ou de fournisseur, modification de l'usage prévu, incidents, résultats de suivi s'écartant de l'attendu ou changements normatifs applicables. S'il n'y a pas eu de changement, enregistrez la révision et sa conclusion, au lieu de laisser l'absence d'annotation ressembler à une omission.

Critères d'auditabilité et erreurs fréquentes

Un registre auditable se comprend sans dépendre de la mémoire de son créateur. Chaque entrée doit être lisible, datée, attribuable et liée à des artefacts accessibles pour ceux qui en ont l'autorisation. La complétude ne signifie pas tout inclure : cela signifie que les informations nécessaires pour reconstituer la décision sont présentes, que les lacunes sont signalées et que les affirmations n'excèdent pas ce que la preuve permet de conclure.

Évitez les contrôles décrits par des verbes imprécis, comme « surveiller » ou « améliorer », si l'on n'explique pas qui les exécute, quand et comment leur conformité est vérifiée. Évitez également de présenter une politique, une évaluation d'impact ou une case d'approbation comme preuve d'efficacité. Ces documents peuvent être pertinents, mais ils prouvent des choses différentes. Les directives institutionnelles sur l'audit des traitements incluant l'IA apportent un contexte pour la revue, mais ne transforment pas un modèle de registre en garantie automatique de conformité.

Avant un audit, sélectionnez quelques décisions et parcourez-les dans les deux sens : de chaque risque vers le contrôle et la preuve, et d'une preuve vers la décision qui l'utilise. Vérifiez que les liens sont toujours disponibles, que les versions correspondent, que les responsables sont identifiés et que les exceptions sont expliquées. Si une lacune est détectée, enregistrez-la comme un constat avec responsable et suivi ; ne la masquez pas en remplaçant rétroactivement une preuve incomplète.

Critères pratiques pour commencer

Commencez par un modèle court et testez son utilisation sur une décision réelle avant d'en faire un formulaire extensif. Si un champ n'aide pas à identifier, expliquer, vérifier ou maintenir une décision, considérez s'il doit être dans le registre ou dans un autre artefact lié. La structure doit permettre de parcourir la chaîne entre risque, mesure et preuve sans dupliquer inutilement la documentation technique ou les journaux d'opération.

Ajustez la conservation, les permissions d'accès et le niveau de détail aux obligations applicables, au type de données et aux besoins d'audit. Consultez la documentation normative et les instructions institutionnelles en vigueur pour le cas concret : les obligations peuvent dépendre de la fonction de l'organisation, du type de système et de son usage. Le registre aide à organiser et expliquer les preuves ; il ne remplace pas l'analyse juridique ni ne démontre à lui seul que le système est conforme.

En guise de critère final, considérez une entrée prête lorsqu'une autre personne autorisée peut reconstituer ce qui a été décidé, quel risque a été abordé, quel contrôle a été appliqué, quelle preuve a été examinée, quelles sont ses limites et quand elle doit être revue. Si l'un de ces éléments manque, signalez l'incertitude et assignez une action. La transparence sur une lacune documentée est plus utile qu'une affirmation d'efficacité sans preuve vérifiable.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.