Journalisation et traçabilité de l'IA

Un régulateur des services financiers menant un examen prudentiel d’un fournisseur d’IA de notation de crédit a demandé la piste d’audit complète des décisions pour un échantillon aléatoire de cinquante demandes de crédit couvrant les dix-huit mois précédents. L’examen portait sur la gouvernance des modèles d’IA, plus précisément sur la capacité du fournisseur à démontrer que chaque décision avait été prise par une version de modèle dûment validée, que les données d’entrée utilisées pour chaque décision étaient complètes et exactes, et que la logique de décision pouvait être reconstituée pour l’examen réglementaire. L’équipe technique du fournisseur a fourni les journaux de l’API. Les journaux confirmaient que des appels à l’API de notation de crédit avaient été effectués pour chacune des cinquante demandes et qu’une note avait été renvoyée pour chacune. Les journaux enregistraient l’horodatage de l’appel à l’API, le point de terminaison de l’API sollicité, le jeton d’authentification utilisé et la note de crédit finale renvoyée. Ils n’enregistraient pas la version du modèle qui avait généré la note (le système utilisait le modèle de production, mis à jour sept fois au cours de la période de dix-huit mois), les valeurs des variables d’entrée transmises au modèle (l’API acceptait un identifiant client et le modèle récupérait les variables en interne), ni les résultats intermédiaires du modèle reliant les entrées à la note finale. Pour trois des cinquante demandes, le régulateur a constaté que le dossier de crédit du demandeur avait été mis à jour après la notation initiale, ce qui signifiait que les variables utilisées par le modèle au moment de la décision ne pouvaient pas être reconstituées a posteriori, même à partir du dossier client actuel. Le fournisseur pouvait confirmer que des décisions de crédit avaient été prises. Il ne pouvait pas les reconstituer.

Que sont la journalisation et la traçabilité de l’IA, au fond ?

La journalisation et la traçabilité de l’IA désignent l’enregistrement complet des informations nécessaires pour reconstituer la décision d’un système d’IA à tout moment après qu’elle a été prise, plus précisément la version du modèle qui a pris la décision, les données d’entrée présentées au modèle au moment de la décision, les résultats intermédiaires du modèle et le résultat final de la décision. La traçabilité des décisions d’IA diffère sensiblement de la journalisation applicative : la journalisation applicative enregistre qu’une fonction a été appelée et ce qu’elle a renvoyé ; la traçabilité des décisions d’IA enregistre suffisamment d’informations pour reconstituer la décision elle-même et valider qu’elle a été prise correctement par un modèle dûment validé, à partir de données d’entrée exactes.

Le problème de l’enregistrement de la version du modèle est la première lacune de traçabilité. Les modèles d’IA sont mis à jour (réentraînés, affinés, incrémentés de version) selon des rythmes variés. Un modèle de notation de crédit peut être mis à jour chaque mois en fonction de nouvelles données d’entraînement et du suivi des performances. Chaque version peut prendre des décisions différentes pour les mêmes données de demandeur. Si un audit, un recours ou un examen réglementaire exige de comprendre une décision prise il y a douze mois, la question pertinente est de savoir quelle version du modèle était en production à ce moment-là. Sans journalisation de la version du modèle au niveau de chaque décision, il peut être impossible de déterminer quelle version du modèle a pris une décision passée donnée.

Le problème de l’enregistrement des entrées au moment de la décision est la deuxième lacune de traçabilité. Les modèles d’IA qui récupèrent leurs variables en interne, depuis un magasin de variables, une base de données clients ou une API externe, prennent leurs décisions sur la base des valeurs qui existaient au moment de la décision. Les dossiers clients changent : les dossiers de crédit sont mis à jour, les adresses changent, l’historique de paiement évolue. Si les variables d’entrée ne sont pas enregistrées au moment de la décision, il peut être impossible de reconstituer a posteriori ce que le modèle a utilisé : le dossier client qui existe aujourd’hui peut différer de celui auquel le modèle a accédé lorsque la décision a été prise.

Le problème de l’enregistrement des résultats intermédiaires est la troisième lacune de traçabilité. Les modèles d’IA complexes (ensembles, réseaux de neurones, pipelines à plusieurs étapes) produisent des résultats intermédiaires qui relient les entrées aux décisions finales au travers de plusieurs étapes de traitement. N’enregistrer que la note de décision finale ne permet pas de reconstituer la logique qui l’a produite. À des fins réglementaires, notamment au titre de l’article 22 du GDPR et des exigences du règlement européen sur l’IA, la capacité à expliquer une décision individuelle précise peut nécessiter l’accès aux résultats intermédiaires qui montrent comment les variables d’entrée ont contribué à la note finale.

Pourquoi c’est important

La journalisation et la traçabilité de l’IA sont importantes pour la TPRM car les examens réglementaires, les litiges et les recours individuels contre des décisions exigent tous de pouvoir reconstituer des décisions d’IA précises à partir des historiques. L’entreprise qui déploie l’IA d’un fournisseur pour des décisions à fort enjeu et ne peut pas produire la piste d’audit des décisions s’expose à des risques réglementaires et juridiques, que la journalisation des API du fournisseur soit complète ou non.

Là où la plupart des équipes se trompent

L’échec le plus constant consiste à assimiler la journalisation des API à la traçabilité des décisions d’IA. La journalisation des API confirme que le service a été appelé et ce qu’il a renvoyé. La traçabilité des décisions d’IA permet de reconstituer la décision elle-même : version du modèle, variables d’entrée, logique intermédiaire.

• Journalisation des API assimilée à la traçabilité des décisions
• Version du modèle non enregistrée au niveau de chaque décision
• Variables d’entrée non enregistrées au moment de la décision
• Résultats intermédiaires non journalisés pour les architectures de modèles complexes
• Exigences réglementaires de traçabilité non prises en compte dans la conception de la journalisation

À quoi ressemblent les bonnes pratiques

Les programmes matures de journalisation de l’IA enregistrent l’intégralité de la décision à chaque inférence : identifiant de version du modèle, valeurs des variables d’entrée au moment de la décision, principaux résultats intermédiaires et décision finale, conservés pendant la durée exigée par la réglementation applicable et les obligations de conservation à des fins de contentieux.

• Version du modèle enregistrée à chaque décision
• Variables d’entrée journalisées au moment de la décision, et non reconstituées à partir du dossier actuel
• Résultats intermédiaires enregistrés pour une reconstitution de niveau audit
• Durée de conservation alignée sur les exigences réglementaires
• Piste d’audit des décisions démontrable sur demande : la tester avant qu’un audit ne l’exige

Outils

Observabilité ML : Arize AI, Whylogs, MLflow avec journalisation des décisions

Les plateformes d’observabilité ML enregistrent la version du modèle, les variables d’entrée et les prédictions au moment de l’inférence, créant ainsi le journal des décisions d’IA que la journalisation des API ne fournit pas. Pour les praticiens de la TPRM, demander si le journal des décisions d’IA du fournisseur enregistre la version du modèle et les variables d’entrée à chaque inférence, indépendamment de la journalisation des accès aux API, constitue une question précise sur la traçabilité des décisions.

Enjeux de gouvernance

Le défi de gouvernance posé par la journalisation des décisions d’IA est le volume et le coût de l’enregistrement des variables d’entrée à chaque inférence. Les systèmes d’IA à fort volume peuvent noter des millions de demandes par jour, et l’enregistrement du vecteur complet de variables à chaque inférence entraîne d’importants besoins de stockage. La solution de gouvernance est une journalisation modulée selon le risque : traçabilité complète des décisions pour les décisions à fortes conséquences (crédit, assurance, emploi) et journalisation plus légère pour les applications à moindres conséquences.

• Exiger une journalisation au niveau de chaque décision : version du modèle et variables d’entrée à chaque inférence
• Tester la piste d’audit des décisions avant qu’un audit réglementaire ne l’exige
• Aligner la durée de conservation sur les exigences réglementaires et contentieuses
• Demander une démonstration de la piste d’audit des décisions sur un échantillon de décisions passées
• Exiger l’appui aux audits réglementaires comme obligation contractuelle

Si vous êtes une petite équipe

Posez la question de la simulation d’audit : si un régulateur demandait la piste d’audit complète d’une demande de crédit notée il y a dix-huit mois (la version du modèle, les variables d’entrée au moment de la décision et la logique qui a produit la note), pourriez-vous fournir ces informations ? Et pouvez-vous le démontrer dès maintenant en reconstituant une décision passée à partir de vos journaux ? La demande de démonstration révèle la capacité réelle qui se cache derrière la documentation.

• Demander une démonstration de la piste d’audit d’une décision passée
• Demander si la version du modèle est enregistrée à chaque décision
• Demander si les variables d’entrée sont enregistrées telles qu’elles étaient au moment de la décision
• Interroger sur la durée de conservation des journaux d’audit des décisions

Ce qu’il faut exiger

Demandez directement :

« Pouvez-vous démontrer la piste d’audit complète d’une décision de crédit prise il y a dix-huit mois, plus précisément la version du modèle qui a pris la décision, les variables d’entrée au moment de la décision et la logique qui a produit la note finale ? »

Preuves attendues

• Démonstration de la piste d’audit d’une décision passée
• Confirmation de l’enregistrement de la version du modèle
• Confirmation de la journalisation des variables d’entrée au moment de la décision
• Durée de conservation des journaux de décisions

Un fournisseur qui confirme une journalisation complète doit être invité à démontrer la reconstitution d’une décision passée. La démonstration révèle ce que la journalisation enregistre réellement, et si une journalisation complète des API et une traçabilité complète des décisions d’IA sont bien la même chose.

Comment le prouver

• Dossiers de démonstration de la piste d’audit des décisions
• Confirmation de la journalisation de la version du modèle
• Confirmation de la journalisation des variables d’entrée
• Documentation de la durée de conservation

À retenir

L’auditeur a demandé la piste d’audit. Les journaux montraient que l’API avait été appelée. La décision avait été renvoyée. La version du modèle : non enregistrée. Les variables d’entrée : non enregistrées au moment de la décision. Trois demandes dont le dossier client avait changé depuis la notation : variables d’entrée irrécupérables. La journalisation des API était complète. La traçabilité des décisions était absente. La journalisation des API et la traçabilité des décisions d’IA sont des capacités différentes. L’une confirme que le service a été utilisé. L’autre permet de reconstituer la décision elle-même. La version du modèle au moment de la décision, les variables d’entrée à cet instant et les résultats intermédiaires pour la reconstitution : voilà les exigences de journalisation des décisions d’IA que la journalisation des API ne couvre pas. Testez la piste d’audit avant que l’auditeur ne le fasse.