Article 12 de l'AI Act Tenue de registres

Analyse juridique de l'article 12

Obligation de conception avec capacités de consignation automatique

L'article 12, paragraphe 1, impose que les systèmes d'IA à haut risque soient « conçus et développés » avec des capacités de consignation automatique. Cette formulation souligne qu'il s'agit d'une exigence de conception (design requirement), qui doit être prise en compte dès les premières phases de développement du système. L'ajout ultérieur de capacités de logging à un système déjà développé serait généralement plus coûteux et moins efficace qu'une intégration native de ces fonctionnalités.

L'automaticité de la consignation constitue une caractéristique essentielle : les événements doivent être enregistrés automatiquement, sans nécessiter d'intervention manuelle de l'opérateur du système. Cette exigence garantit l'exhaustivité et la fiabilité des registres, évitant les oublis ou les manipulations potentielles. Elle impose également que le système soit conçu de manière à identifier et capturer automatiquement les événements pertinents.

La mention « pendant leur durée de vie » signifie que les capacités de consignation doivent être opérationnelles tout au long de l'existence du système, de sa mise en service initiale jusqu'à son retrait définitif. Cette continuité est essentielle pour permettre une surveillance effective et pour disposer d'un historique complet en cas d'investigation.

Niveau de traçabilité approprié et événements pertinents

L'article 12, paragraphe 2, introduit un principe de proportionnalité : le niveau de traçabilité doit être « approprié à la finalité prévue du système ». Cette formulation reconnaît que tous les systèmes d'IA à haut risque n'ont pas les mêmes besoins en matière de traçabilité, et que les événements à enregistrer peuvent varier selon le type de système, son domaine d'application et les risques qu'il présente.

Le paragraphe 2 énumère quatre catégories d'événements qui doivent « notamment » être enregistrés. L'utilisation du terme « notamment » indique que cette liste n'est pas exhaustive : d'autres événements peuvent devoir être consignés en fonction de la nature spécifique du système et de sa finalité. Le fournisseur doit déterminer, dans le cadre de son système de gestion des risques (article 9), quels événements supplémentaires doivent être enregistrés pour garantir une traçabilité appropriée.

Le point a) exige l'enregistrement de la période d'utilisation de chaque système. Cette exigence permet de tracer l'activité temporelle du système : quand il a été activé, pendant combien de temps il a fonctionné, quand il a été désactivé. Pour les systèmes traitant de multiples requêtes ou transactions, cela implique probablement l'enregistrement de l'horodatage de chaque requête ou session d'utilisation.

Le point b) impose l'enregistrement de la base de données de référence utilisée par le système. Cette exigence est particulièrement pertinente pour les systèmes d'identification biométrique, qui comparent des données biométriques à une base de référence, mais elle s'applique aussi plus généralement à tout système utilisant des bases de données de référence pour produire ses résultats. L'enregistrement doit permettre d'identifier quelle version ou quel sous-ensemble de la base de référence a été utilisé, facilitant ainsi la reproductibilité et la vérification des résultats.

Le point c) vise l'enregistrement des données d'entrée ayant conduit à une correspondance (match). Cette exigence s'applique notamment aux systèmes biométriques qui identifient une correspondance entre des données biométriques fournies en entrée et des données présentes dans une base de référence, mais peut également concerner d'autres types de systèmes produisant des correspondances ou des classifications. L'enregistrement de ces données d'entrée permet de reconstituer les circonstances exactes ayant conduit à un résultat donné.

Le point d) impose l'identification des personnes physiques impliquées dans la vérification des résultats, conformément à l'article 14, paragraphe 5. Cette exigence crée un lien direct avec l'obligation de surveillance humaine et garantit la traçabilité de cette surveillance : il doit être possible de déterminer qui a vérifié ou validé les résultats produits par le système d'IA. Cette traçabilité est essentielle pour l'accountability et peut permettre d'identifier des problèmes de formation ou de compétence des opérateurs humains.

Durée de conservation des logs

L'article 12, paragraphe 3, fixe une durée minimale de conservation des logs de six mois. Cette durée constitue un plancher, que des dispositions du droit de l'Union ou du droit national peuvent étendre. Par exemple, dans certains secteurs régulés (santé, finance, sécurité), des obligations de conservation plus longues peuvent s'appliquer en vertu de législations sectorielles spécifiques.

Le paragraphe 3 précise que cette obligation de conservation s'applique « sans préjudice » du RGPD, du règlement (UE) 2018/1725 (protection des données dans les institutions européennes) et de la directive (UE) 2016/680 (protection des données dans le domaine pénal). Cette réserve signifie que lorsque les logs contiennent des données à caractère personnel, les principes et obligations de ces textes s'appliquent cumulativement avec l'AI Act.

En particulier, le principe de limitation de la conservation du RGPD (article 5, paragraphe 1, point e) s'applique : les données ne doivent pas être conservées plus longtemps que nécessaire au regard des finalités pour lesquelles elles sont traitées. Si la finalité de traçabilité et de surveillance ne nécessite plus la conservation de logs anciens au-delà de six mois, ils doivent être supprimés, sauf si une autre finalité légitime justifie leur conservation (par exemple, l'obligation légale de conservation à des fins d'investigation en cas de contentieux en cours).

Articulation avec la protection des données personnelles

Les logs enregistrés en application de l'article 12 contiennent fréquemment des données à caractère personnel : identifiants des utilisateurs, données d'entrée contenant des informations personnelles (notamment dans le cas des systèmes biométriques), identification des personnes ayant vérifié les résultats. Le traitement de ces données doit respecter l'ensemble des principes et obligations du RGPD.

La base légale du traitement des logs sera généralement l'obligation légale (article 6, paragraphe 1, point c, du RGPD), l'AI Act constituant l'obligation légale en question. Pour certains traitements complémentaires (par exemple, l'utilisation des logs à des fins d'amélioration du système), d'autres bases légales peuvent devoir être mobilisées (intérêt légitime, consentement selon les cas).

Les droits des personnes concernées (accès, rectification, effacement, limitation, opposition) s'appliquent aux données contenues dans les logs, sous réserve des limitations prévues à l'article 23 du RGPD. L'exercice de certains de ces droits peut toutefois être restreint lorsqu'il risquerait de compromettre la finalité de traçabilité et de surveillance. Par exemple, un droit à l'effacement ne pourrait généralement pas être exercé pendant la période de conservation minimale de six mois imposée par l'AI Act, sauf circonstances exceptionnelles.

Les mesures de sécurité prévues à l'article 32 du RGPD s'appliquent pleinement aux logs, qui peuvent contenir des données sensibles. Ces mesures doivent inclure notamment la protection contre les accès non autorisés, la garantie de l'intégrité des logs (prévention des modifications ou suppressions non autorisées) et des mécanismes de sauvegarde garantissant la disponibilité des logs.

Exigences techniques de mise en œuvre

Bien que l'article 12 ne prescrive pas de modalités techniques précises de mise en œuvre, certaines exigences techniques peuvent être inférées de ses objectifs et de son articulation avec les autres dispositions du règlement.

Les logs doivent être horodatés avec précision, permettant de reconstituer la chronologie exacte des événements. L'utilisation de timestamps synchronisés (par exemple, via NTP - Network Time Protocol) est généralement nécessaire pour garantir la fiabilité de cette chronologie, particulièrement pour les systèmes distribués.

L'intégrité des logs doit être garantie par des mécanismes techniques appropriés, empêchant leur modification ou leur suppression non autorisée. Des techniques telles que les signatures cryptographiques, les journaux en mode append-only, ou l'utilisation de systèmes de gestion de logs centralisés et sécurisés peuvent être mises en œuvre.

La disponibilité des logs doit être assurée pendant toute la durée de conservation requise, ce qui implique des mécanismes de sauvegarde et de réplication appropriés. Les logs doivent pouvoir être produits rapidement en cas de demande d'une autorité compétente ou dans le cadre d'une investigation interne.

La structure et le format des logs doivent permettre leur exploitation effective. Des logs trop verbeux ou mal structurés peuvent être difficiles à analyser ; à l'inverse, des logs trop sommaires peuvent ne pas fournir les informations nécessaires pour reconstituer les événements. L'utilisation de formats structurés et standardisés facilite l'analyse et l'interopérabilité.

Exemples concrets d'application

Articulation avec les autres dispositions de l'AI Act

L'article 12 s'articule étroitement avec l'article 9 sur le système de gestion des risques : les logs constituent l'un des principaux outils permettant d'identifier les risques émergents et de vérifier l'efficacité des mesures de gestion des risques mises en place. L'analyse des logs peut révéler des patterns problématiques (biais, dysfonctionnements, utilisations inappropriées) qui doivent alimenter le processus itératif de gestion des risques.

L'article 12 est directement lié à l'article 14 sur la surveillance humaine, puisque le paragraphe 2, point d, impose spécifiquement l'enregistrement de l'identification des personnes ayant vérifié les résultats du système. Cette exigence garantit la traçabilité de la surveillance humaine et permet de vérifier son effectivité.

L'article 12 constitue également un instrument essentiel de mise en œuvre de l'article 72 sur la surveillance après commercialisation. Les logs fournissent les données nécessaires pour analyser le fonctionnement du système en conditions réelles, identifier les incidents et dysfonctionnements, et adapter le système en conséquence. Sans capacités de logging appropriées, la surveillance après commercialisation serait considérablement entravée.

L'article 12 s'inscrit dans le prolongement de l'article 11 sur la documentation technique, qui doit décrire les capacités de logging du système, les événements enregistrés, les modalités de conservation et les mesures de sécurité des logs. Les logs eux-mêmes constituent par ailleurs une forme de documentation dynamique du fonctionnement effectif du système.

Enfin, l'article 12 doit être lu conjointement avec l'article 16 sur les obligations des fournisseurs, qui prévoit que les fournisseurs doivent tenir les logs à la disposition des autorités compétentes. Les logs constituent ainsi l'un des principaux instruments de contrôle de la conformité par les autorités.

Implications pratiques pour les organisations

Pour les fournisseurs de systèmes d'IA à haut risque, l'article 12 impose d'intégrer dès la conception des capacités de logging robustes et adaptées à la finalité du système. Cette intégration dès la conception (security by design, transposé ici en logging by design) est généralement plus efficace et moins coûteuse qu'un ajout ultérieur de fonctionnalités de logging.

Le dimensionnement du système de logging nécessite de trouver un équilibre entre plusieurs contraintes. D'une part, les logs doivent être suffisamment détaillés pour permettre une traçabilité effective et répondre aux objectifs de l'article 12. D'autre part, des logs trop volumineux peuvent poser des problèmes de performance, de stockage et d'exploitabilité. Une analyse des risques spécifiques au système permet de déterminer le niveau de détail approprié.

Les organisations doivent mettre en place une infrastructure technique appropriée pour la gestion des logs : systèmes de stockage suffisants, mécanismes de sauvegarde, outils d'analyse et de recherche dans les logs, procédures de conservation et de purge automatiques. Pour les systèmes traitant de gros volumes, l'utilisation de plateformes de gestion de logs spécialisées (SIEM - Security Information and Event Management, ou solutions équivalentes) peut être nécessaire.

La protection des logs contenant des données personnelles requiert une attention particulière. Les organisations doivent appliquer les principes de protection des données dès la conception (privacy by design) au système de logging lui-même : minimisation des données enregistrées, pseudonymisation ou anonymisation lorsque possible, chiffrement, contrôles d'accès stricts, journalisation des consultations de logs.

Les organisations doivent également mettre en place des procédures permettant l'exploitation effective des logs pour la surveillance du système, la détection d'incidents et la réponse aux demandes des autorités. Des tableaux de bord et des alertes automatiques peuvent faciliter le suivi continu du fonctionnement du système et la détection rapide d'anomalies.

Pour les déployeurs de systèmes d'IA à haut risque, l'article 12 implique de s'assurer que les systèmes acquis disposent bien des capacités de logging requises et de mettre en œuvre ces capacités de manière effective. Les contrats d'acquisition ou de licence de systèmes d'IA à haut risque devraient inclure des clauses spécifiques relatives aux capacités de logging et aux modalités d'accès aux logs.