Quand le système d'IA change, la preuve doit garder la mémoire. Par Mohand Ouidja, Avocat.
L’évolution rapide des systèmes d’IA à haut risque impose une refonte des exigences en matière de documentation technique, où la simple mise à jour des dossiers ne suffit plus à garantir la traçabilité des décisions passées. L’article 11 de l’AI Act révèle une tension fondamentale entre l’impératif de conformité actuelle et la nécessité de préserver la mémoire historique des systèmes, un enjeu juridique et technique qui interroge la robustesse des mécanismes de preuve dans un cadre réglementaire encore en construction.
Pourquoi la documentation technique d’un système d’IA à haut risque doit-elle intégrer une dimension historique, et non se limiter à son état actuel ?
Parce qu’une décision contestée à un moment donné (par exemple en janvier) peut dépendre d’un état du système qui a depuis évolué (modèle réentraîné, seuil ajusté, API remplacée), rendant impossible sa reconstruction a posteriori si l’historique n’a pas été conservé. L’Annexe IV de l’AI Act impose déjà des exigences de versioning, mais leur application progressive (à partir de 2027-2028) laisse un vide juridique et technique jusqu’à cette date.
Quels acteurs sont concernés par la responsabilité de maintenir cette traçabilité, notamment lorsque des modifications proviennent de tiers ?
Tous les maillons de la chaîne de valeur sont impliqués : le fournisseur initial, mais aussi les distributeurs, importateurs, déployeurs ou autres tiers qui pourraient être considérés comme fournisseurs au sens de l’article 25 si une modification substantielle leur est imputable. La documentation doit alors retracer l’origine des changements (mises à jour d’API, composants externes) et leurs impacts, sans quoi la responsabilité juridique reste floue.
Comment distinguer une modification substantielle d’un simple ajustement technique dans un système d’IA ?
L’article 3, point 23, définit une modification substantielle comme un changement non prévu lors de l’évaluation initiale qui affecte la conformité du système ou sa finalité initiale. Cette qualification ne peut être automatisée : elle relève d’une appréciation humaine, même si des outils peuvent détecter les changements (version, seuil, composant). Les systèmes en apprentissage continu échappent à cette catégorie si les évolutions étaient prévues dès l’évaluation initiale.
Quels mécanismes techniques peuvent renforcer la fiabilité de l’historique documentaire, et quelles limites persistent malgré ces outils ?
Des solutions comme les empreintes cryptographiques, l’horodatage ou les signatures électroniques sécurisent l’intégrité, la chronologie et l’attribution des documents, mais elles ne valident pas le contenu lui-même. Un dossier peut être intègre tout en étant incomplet ou juridiquement discutable. L’architecture documentaire doit donc combiner automatisation (versioning, collecte de métadonnées) et contrôle humain (analyse des changements, validation juridique).
Ce que ça pourrait changer
Cette exigence de mémoire documentaire pourrait transformer les pratiques des acteurs du secteur en imposant des coûts supplémentaires pour les systèmes évolutifs, tout en renforçant la transparence face aux contentieux. À l’inverse, une application trop rigide risquerait de freiner l’innovation en complexifiant les mises à jour. Le défi réside dans l’équilibre entre traçabilité, efficacité opérationnelle et respect des principes de minimisation des données.
