Introduction
La plupart des organisations qui déploient l'IA dans une décision réglementée - notation de crédit, présélection de candidats à l'embauche, souscription d'assurance, signalement de fraudes - journalisent déjà quelque chose. Un horodatage, une entrée, une sortie, peut-être un numéro de version du modèle. Lorsque, des mois plus tard, un régulateur ou une personne concernée par la décision la conteste, ce journal suffit rarement. La question réellement posée n'est pas « qu'a produit le modèle ? », mais « pouvez-vous prouver que le modèle qui a produit cette décision opérait sur les données sur lesquelles il était censé opérer, sans altération, au moment où il l'a prise ? ». La plupart des infrastructures de journalisation existantes n'ont jamais été conçues pour y répondre.
Ce qu'exige réellement une piste d'audit à la hauteur d'un régulateur
La décision, la version du modèle et les données doivent être liées - de façon permanente
Une piste d'audit défendable relie trois éléments au moment de la décision : l'entrée et la sortie précises, la version exacte du modèle qui l'a produite (et non une étiquette mouvante comme « production », qui pointe discrètement vers des poids différents au fil du temps) et l'état précis de toutes les données de référence ou d'entraînement sur lesquelles le modèle s'est appuyé. Si l'un de ces trois éléments peut évoluer indépendamment des autres dans l'historique, la chaîne se rompt et une décision contestée ne peut plus être reconstituée de manière fiable.
L'historique doit rendre toute falsification détectable, et pas seulement fonctionner en ajout seul
La journalisation en ajout seul (append-only) est une bonne base, mais elle ne prouve pas, à elle seule, que rien n'a été modifié - elle rend seulement plus difficile une modification faite à la légère. Une piste d'audit à la hauteur d'un régulateur exige que toute modification de l'historique, quelle qu'en soit l'origine, soit détectable par des moyens cryptographiques. C'est toute la différence entre un journal auquel un ingénieur se fie parce qu'il l'a construit et un journal qu'un auditeur externe peut vérifier de manière indépendante, sans avoir à croire l'organisation sur parole.
La conservation doit survivre au délai de contestation, pas au cycle de vie du modèle
Les versions de modèles sont rendues obsolètes puis retirées selon un calendrier d'ingénierie. Les délais de contestation réglementaires et juridiques ne suivent pas ce calendrier - une décision d'embauche ou un refus de crédit peuvent être contestés bien après le remplacement du modèle qui les a prises. Une architecture de piste d'audit qui aligne la durée de conservation des enregistrements sur le cycle de vie du modèle plutôt que sur le délai de contestation légal applicable présentera des lacunes précisément là où elles comptent le plus.
Le lien avec la provenance des données, et pas seulement avec la journalisation
Une piste d'audit qui enregistre fidèlement une décision mais ne peut pas vérifier de manière indépendante l'intégrité des données qui la sous-tendent n'a résolu que la moitié du problème. Si les données d'entraînement ou de référence elles-mêmes ont pu être modifiées sans que cela soit détecté, alors même une piste de décisions parfaitement journalisée repose sur des fondations invérifiables. Les deux problèmes - la journalisation des décisions et l'intégrité des données - doivent être résolus ensemble, ancrés à la même racine cryptographique, faute de quoi l'argument le plus solide de la piste d'audit se réduit à « nous n'avons rien remarqué d'anormal », ce qui n'équivaut pas à une preuve.
- Lier chaque enregistrement de décision à une version de modèle précise et immuable - jamais à une étiquette mouvante
- Ancrer l'état des données de référence et d'entraînement avec la décision, et non dans un système séparé et déconnecté
- Rendre toute altération de l'historique détectable par des moyens cryptographiques, et ne pas se contenter d'un journal en ajout seul
- Fixer la durée de conservation selon le délai de contestation légal applicable, et non selon le cycle de vie de déploiement du modèle
Un journal de décisions qui ne peut pas prouver de manière indépendante l'intégrité des données qui le sous-tendent n'est pas une piste d'audit - c'est une affirmation. Découvrez comment ROOTKey ancre les décisions, les versions de modèles et l'état des données dans un enregistrement unique et vérifiable.