Le travail discret de l'AI Act européen : des registres, pas des slogans

La partie difficile de l’AI Act européen ne consiste pas à répéter ses principes, mais à transformer le risque, la documentation, la journalisation, la...

Le travail discret de l'AI Act européen : des registres, pas des slogans

Le dossier qui arrive après la décision

Il y a un moment, après qu’une recommandation automatisée a été acceptée, où la pièce change de forme. L’écran affiche toujours le résultat. La conversation est passée à la suite. Quelqu’un demande quelle version du système l’a produit, quelles informations étaient disponibles à ce moment-là, si l’opérateur aurait pu le rejeter, et quelle règle a rendu l’itinéraire admissible. Ces questions ne sont pas une attaque spectaculaire contre la technologie. Ce sont les questions ordinaires que les institutions posent lorsqu’une action acquiert une conséquence.

Imaginons un cas composite, volontairement sans organisation, système ou incident nommé. Un organisme public utilise un système d’IA à haut risque pour assister une décision qui affecte une personne. Un membre du personnel formé reste responsable de la décision. Le modèle produit une sortie, le membre du personnel la vérifie, et la décision est prise. Plus tard, un superviseur doit comprendre le cheminement. La sortie elle-même est présente. La décision est présente. La chaîne entre les deux ne l’est pas. Il n’existe aucun enregistrement clair des instructions en vigueur, des données utilisées, de la version déployée, de l’intervention disponible ou de la raison pour laquelle l’humain a accepté le résultat. Rien dans cette description n’exige un dysfonctionnement spectaculaire. Un dossier manquant suffit à transformer un examen en exercice de reconstitution.

Le règlement sur l’intelligence artificielle de l’Union européenne est souvent présenté comme un catalogue d’interdictions, de catégories et de sanctions. Ces éléments comptent, mais ils ne constituent pas l’ensemble de l’œuvre. Le règlement décrit aussi une infrastructure de preuve plus discrète : une gestion des risques documentée et maintenue, des pratiques en matière de données qui ont une origine et une finalité, une documentation technique qui peut être évaluée, des journaux qui consignent les événements pertinents, des instructions qui indiquent au déployeur comment interpréter un système, une surveillance humaine dotée d’une autorité réelle, et des enregistrements qui restent disponibles lorsqu’une question survient plus tard. La loi demande à une institution de se souvenir délibérément.

C’est une tâche moins cinématographique que le lancement d’un modèle. C’est aussi là que la responsabilité devient réelle. Un slogan peut affirmer qu’une organisation assume ses responsabilités. Un dossier peut montrer ce que cette responsabilité signifiait à un moment précis. Il peut montrer une limite, une incertitude, une approbation, un refus, une correction ou une absence. Il ne peut pas rendre une décision illégale légale en existant après coup, et il ne peut pas réparer à lui seul le préjudice subi par une personne. Il peut rendre le cheminement suffisamment inspectable pour permettre un recours, une correction et une meilleure décision concernant la version suivante.

Cet article porte sur ce travail discret. Il lit les obligations de tenue de registres et de documentation du règlement sur l’IA comme des exigences opérationnelles plutôt que comme des formalités administratives attachées à un lancement. Il s’interroge sur ce que les dossiers peuvent établir, sur ce qu’ils ne peuvent pas établir, sur la manière dont un dossier tire son sens du contexte, sur la raison pour laquelle l’exhaustivité n’est pas la même chose que le volume, et sur la manière dont une organisation peut instaurer une routine qui laisse des preuves sans transformer chaque interaction humaine en objet de surveillance permanent. Les exemples qui ne sont pas tirés directement d’une source citée sont présentés comme proposés, hypothétiques ou composites. Il n’y a pas d’incident inventé qui attend à la fin de l’histoire. Le but est d’éviter d’en avoir besoin.

Les obligations du règlement ne sont pas des rayons séparés. Elles forment un parcours qui va de la finalité et du risque jusqu'à la preuve, à la supervision et au recours.

Pourquoi le travail discret compte

Les enregistrements sont faciles à mal comprendre parce qu'ils sont présents dans presque toutes les organisations. Une ligne de base de données, un ticket, une demande de modification, une décision signée, un horodatage et une ligne de journal ressemblent tous à des enregistrements. Leur seule présence ne dit pas grand-chose. Un enregistrement devient utile lorsqu'il répond à une question définie avec suffisamment de contexte pour distinguer ce qui s'est passé de ce que quelqu'un croit aujourd'hui qu'il s'est passé. Cette distinction est particulièrement importante pour l'IA, car la sortie visible masque souvent le nombre de transformations qui l'ont précédée.

Un système logiciel classique peut laisser une trace familière à ses opérateurs. Une demande entre, un service valide des champs, une règle s'exécute, un état change et une réponse sort. Les systèmes d'IA peuvent ajouter des catégories inférées, un contexte récupéré, des instructions en langage naturel, des sorties probabilistes, des appels d'outils, des modifications humaines et un état adaptatif. Cette flexibilité supplémentaire peut être utile. Elle crée aussi davantage d'occasions pour qu'un fait perde son origine ou pour qu'une instruction devienne autoritaire sans être reconnue comme telle. L'enregistrement doit conserver les distinctions que l'interface est tentée d'estomper.

Le règlement sur l'IA n'exige pas qu'une organisation conserve chaque octet qui a traversé un modèle. Ses exigences sont liées à la finalité, au risque, à la traçabilité, au cycle de vie et au contrôle. C'est un point de départ utile. Il indique que la preuve doit être proportionnée à la finalité prévue et aux risques, tout en restant suffisamment rigoureuse pour l'obligation concernée. Un enregistrement d'une suggestion de rédaction à faible impact ne doit pas être traité comme s'il s'agissait d'un dossier complet pour une décision affectant les droits fondamentaux. À l'inverse, une décision importante ne peut pas être rendue responsable en stockant une seule phrase finale et une coche verte.

Le travail discret commence donc avant qu'un système ne soit mis en service. Quelqu'un doit indiquer ce que le système est censé faire, où il n'est pas censé fonctionner, quelles personnes et quels environnements sont concernés, quelles entrées il peut recevoir, qui peut agir sur la sortie et ce qui se passe lorsque le système est incertain ou indisponible. Ce ne sont pas seulement des questions de conception. Ce sont les conditions qui donnent un sens aux enregistrements ultérieurs. Sans elles, un horodatage nous dit quand quelque chose s'est produit, mais pas si c'était autorisé, attendu ou une exception.

Il existe une raison institutionnelle de prendre cela au sérieux. La personne qui demande des preuves n'est souvent pas celle qui a construit le système. Une autorité compétente, un examinateur interne, une personne concernée ou une équipe successeur peuvent rencontrer le dossier après que le personnel, les fournisseurs et les modèles ont changé. Des preuves qui n'ont de sens que pour leur auteur d'origine constituent une forme fragile de responsabilité. L'insistance de la loi sur une documentation claire, des instructions compréhensibles et l'accès des autorités est une réponse à cette fragilité. Elle traite la continuité comme une partie de la conformité.

Lire la loi comme une séquence, pas comme un slogan

Les exigences relatives aux risques élevés du règlement peuvent être lues comme une séquence de questions. Que doit faire le système. Quels risques peut-il créer dans ce contexte. Quelles données et quelles hypothèses le soutiennent. Comment le système a-t-il été construit et testé. Que doit savoir un déployeur. Quels événements doivent être enregistrés. Qui peut superviser, remplacer ou arrêter le système. Que se passe-t-il lorsque le système n'est pas conforme ou présente un risque. La séquence n'est pas un pipeline logiciel bien ordonné. C'est une chaîne de responsabilité qui boucle en arrière lorsque les preuves changent.

L'article 9 décrit la gestion des risques comme un processus continu et itératif planifié et mené tout au long du cycle de vie d'un système d'IA à haut risque. Il doit être établi, mis en œuvre, documenté et maintenu. Cette formulation a une conséquence pratique. Une évaluation des risques n'est pas un document cérémonial qui prend sa retraite le jour du lancement. C'est le dossier d'un processus vivant qui identifie et évalue les risques connus et raisonnablement prévisibles, tient compte des informations issues de la surveillance après mise sur le marché et adopte des mesures ciblées. Le dossier doit permettre à un lecteur ultérieur de voir ce qui a été pris en compte, ce qui n'a pas pu être éliminé, ce qui restait comme risque résiduel et qui a accepté cette position.

L'article 10 place les données et la gouvernance des données dans cette même discipline. Les pratiques pertinentes incluent les choix de conception, l'origine des données, les opérations de préparation, les hypothèses sur ce que les données représentent, leur disponibilité et leur adéquation, les biais possibles, les lacunes dans les données et les mesures utilisées pour y remédier. C'est une idée différente de celle qui consiste à dire qu'un ensemble de données était propre. Propre est une conclusion. L'origine, la préparation, les hypothèses et les lacunes sont des preuves sur la manière dont la conclusion a été atteinte et sur le point où elle peut cesser d'être fiable. Un dossier qui ne conserve qu'une étiquette de qualité a oublié les questions qui rendaient la qualité significative.

L'article 11 exige une documentation technique pour un système d'IA à haut risque avant sa mise sur le marché ou sa mise en service, et exige que cette documentation soit tenue à jour. Elle est destinée à fournir aux autorités nationales compétentes et aux organismes notifiés les informations nécessaires pour évaluer la conformité. Le point important n'est pas que chaque lecteur devienne un spécialiste d'une annexe. C'est que le système doit avoir un compte rendu de lui-même suffisamment clair et complet pour une évaluation externe. Ce compte rendu a besoin d'une version, d'un objectif et d'une relation avec les versions antérieures. Un document qui décrit un système qui n'existe plus est une archive, pas une preuve actuelle.

L'article 12 fait ensuite du fonctionnement du système lui-même une partie de la preuve. Les systèmes d'IA à haut risque doivent techniquement permettre l'enregistrement automatique des événements sur leur durée de vie. Les capacités de journalisation doivent enregistrer les événements pertinents pour identifier les situations susceptibles de créer un risque ou une modification substantielle, faciliter la surveillance après mise sur le marché et la surveillance du fonctionnement dans le cadre des obligations du déployeur. Le niveau de traçabilité requis est lié à la finalité prévue. La loi ne demande pas au journal d'être un journal intime de la vie humaine. Elle demande au système de laisser suffisamment de mémoire opérationnelle pour les questions pertinentes.

Les articles 13 et 14 relient cette mémoire aux personnes. Un système à haut risque doit être suffisamment transparent pour que les déployeurs puissent interpréter sa sortie et l'utiliser de manière appropriée, et il doit être accompagné d'une notice d'utilisation. La surveillance humaine doit être effective et proportionnée au risque, à l'autonomie et au contexte. Les personnes chargées de la surveillance doivent être capables de comprendre les capacités et les limites, de remarquer les anomalies et les performances inattendues, d'éviter une confiance excessive, d'interpréter les sorties, de les écarter ou de les remplacer et, le cas échéant, d'interrompre le système en toute sécurité. Ces capacités ne peuvent pas se limiter à une diapositive de formation. Un dossier sérieux devrait permettre de déterminer ce que la personne pouvait savoir et faire au moment de la décision.

Les articles 15 à 21 complètent le parcours, de la performance au recours. La précision, la robustesse et la cybersécurité sont des propriétés qui s'appliquent à l'ensemble du cycle de vie. Les fournisseurs doivent maintenir un système de gestion de la qualité documenté de manière ordonnée, comprenant des procédures relatives aux données, la gestion des risques, la surveillance après mise sur le marché, la notification des incidents, la communication, la tenue de registres et un cadre de responsabilité. La documentation et les journaux doivent rester disponibles pendant les périodes et aux fins prévues par le règlement. Les mesures correctives et la coopération avec les autorités compétentes sont des obligations, et non une communication facultative. Le résultat n'est pas un slogan sur une IA digne de confiance. C'est un ensemble d'artefacts qui permettent à une institution de démontrer, d'enquêter, de corriger et d'expliquer.

Trois choses qu'un dossier peut faire

Premièrement, un dossier peut établir un événement. Il peut montrer qu'un système a été sollicité, qu'une version particulière était active, qu'une entrée a été reçue, qu'un appel d'outil a été proposé, qu'une approbation humaine a été enregistrée, qu'une action a été menée à bien ou qu'un système a été arrêté. La preuve par l'événement est la couche que la plupart des gens imaginent lorsqu'ils entendent le mot journal. Elle importe parce qu'une action contestée ne peut pas faire l'objet d'une enquête si l'organisation ne peut pas déterminer si l'action a eu lieu. C'est aussi la couche la moins complète si elle est seule.

Un dossier d'événement nécessite une identité stable, une référence temporelle, un acteur ou un rôle responsable, une identité de système ou de composant et suffisamment d'état pour éviter toute ambiguïté. Les champs exacts dépendent de l'objectif et du droit. Un horodatage sans base de temps peut prêter à confusion entre les systèmes. Un identifiant d'utilisateur sans rôle en dit peu sur l'autorité. Un nom de modèle sans version ne permet pas d'établir quel comportement était concerné. Un dossier peut être techniquement authentique et néanmoins institutionnellement mince.

Deuxièmement, un dossier peut établir un fondement. Il peut montrer quel objectif, quelle règle, quelle instruction, quelle source de données, quelle version de politique ou quelle évaluation a étayé une action. La preuve par le fondement est ce qui empêche une décision de devenir une sortie flottante. Elle n'a pas à reproduire chaque calcul interne. Elle doit identifier les conditions qui ont rendu la sortie pertinente et les limites qui restreignaient ce qu'une personne était autorisée à en faire. Lorsque le fondement manque, une organisation peut savoir ce qu'elle a fait sans savoir pourquoi elle était en droit de le faire.

Troisièmement, un dossier peut établir une réponse. Il peut montrer qu'une anomalie a été remarquée, qu'un opérateur a rejeté une sortie, qu'un risque a été signalé, qu'un système a été suspendu, qu'une correction a été appliquée ou qu'une réclamation a été reçue et orientée. La preuve par la réponse est souvent négligée parce que les équipes se concentrent sur la première sortie du modèle. En pratique, la responsabilité se joue dans ce qui se passe une fois que l'incertitude devient visible. Un système qui peut produire un dossier d'un problème mais qui n'a aucun dossier de la réponse a construit un capteur sans frein.

Ces trois fonctions se recoupent, mais elles ne doivent pas être confondues. Une citation de source peut établir un fondement sans prouver que la source a réellement été utilisée lors de l’exécution. Une approbation humaine peut établir une réponse sans prouver que le relecteur a vu un contexte complet. Une version de modèle peut établir une identité sans prouver que la version s’est comportée de manière cohérente. De bons enregistrements rendent explicites les affirmations qu’ils peuvent étayer. Ils n’empruntent pas l’autorité des enregistrements voisins pour qualifier cet arrangement de chaîne.

L’exhaustivité n’est pas une question d’octets. C’est la capacité à répondre aux questions que créent la finalité du système et ses conséquences.

Ce qu’un enregistrement ne peut pas faire

Un enregistrement ne peut pas transformer une pratique interdite en pratique autorisée. Si l’utilisation elle-même est hors du cadre légal, une journalisation parfaite ne constitue pas une défense. Les preuves peuvent exposer une décision erronée, mais elles ne peuvent pas conférer rétroactivement une autorité qui n’a jamais existé. C’est pourquoi la documentation ne doit jamais être présentée comme un substitut à l’analyse juridique, à l’évaluation des droits fondamentaux ou à une finalité claire. Une violation magnifiquement indexée reste une violation. L’index ne fait que la rendre plus facile à trouver.

Un enregistrement ne peut pas prouver qu’une décision était équitable simplement parce que les champs sont remplis. L’équité n’est pas une propriété qui apparaît lorsqu’un formulaire atteint cent pour cent. La question pertinente est de savoir si le système, les données, le flux de travail et le jugement humain ont traité les personnes d’une manière qui respecte les droits et obligations applicables. Un enregistrement peut conserver des preuves sur cette question. Il peut montrer quelles informations ont été utilisées, quelle règle a été appliquée, quelles exceptions ont été examinées et comment un recours a été traité. Il ne peut pas trancher lui-même la question morale et juridique.

Un enregistrement ne peut pas rendre une explication faible significative en ajoutant des détails techniques. Une personne concernée par une décision peut avoir besoin d’un compte rendu clair du rôle joué par l’IA et des principaux éléments de la décision. Déverser sur cette personne des identifiants internes, des traces brutes de jetons ou un écran de télémétrie machine n’est pas automatiquement de la transparence. La forme des preuves doit correspondre à la question et au public. L’autorité a besoin d’une documentation évaluable. Les opérateurs ont besoin d’instructions utilisables. Les personnes concernées ont besoin d’une voie compréhensible pour comprendre et contester.

Un enregistrement ne peut pas préserver l'avenir. C'est une vue depuis un moment précis, constituée avec les informations et l'état du système qui existaient alors. Cette limite n'est pas un défaut. C'est une raison d'enregistrer les versions, les périodes de validité et les incertitudes. Si une politique a changé après une décision, l'enregistrement ne doit pas silencieusement afficher la nouvelle politique comme si elle avait régi l'ancienne action. Si une source a été corrigée, la saisie antérieure doit rester identifiable tandis que la correction et son effet sont enregistrés. Le temps fait partie du sens, pas un ornement sur le côté droit d'un tableau de bord.

Un enregistrement ne peut pas dire à une organisation ce qu'elle n'a pas enregistré. Cela semble évident, mais c'est une limite importante à l'ère des explications générées. On peut demander à un modèle de raconter une décision passée. La prose qui en résulte peut être utile comme hypothèse ou comme résumé. À moins qu'elle ne soit fondée sur des preuves conservées, ce n'est pas une machine à remonter le temps. La pratique la plus sûre consiste à qualifier la reconstruction de reconstruction, à identifier les preuves manquantes et à éviter de présenter un récit plausible comme un récit observé. Une incomplétude honnête est plus utile qu'une fiction complète.

Les journaux sont des preuves, pas une excuse morale

La journalisation est attrayante parce qu'elle semble objective. Une ligne avec un horodatage et un identifiant système paraît plus neutre qu'une note humaine. Elle n'est pas neutre. Quelqu'un a décidé quoi enregistrer, quoi omettre, quels champs conserver, comment les protéger, comment synchroniser le temps et qui peut inspecter le résultat. La journalisation est un choix d'ingénierie avec des conséquences juridiques et humaines. Les dispositions de l'AI Act relatives à la tenue de registres rendent ce choix visible, mais elles ne suppriment pas la nécessité de le concevoir avec soin.

La première question de conception est la finalité. L'article 12 cite la traçabilité, l'identification des risques, la surveillance après mise sur le marché et la surveillance du fonctionnement comme raisons d'enregistrer les événements pertinents. Chaque raison peut exiger une vue différente. Un exploitant peut avoir besoin d'une explication concise d'un refus et d'un chemin vers un superviseur. Un spécialiste de la sécurité peut avoir besoin de la version et de la lignée des entrées. Une autorité compétente peut avoir besoin de documentation et de journaux suffisants pour évaluer la conformité. Un délégué à la protection des données peut avoir besoin de savoir quelles données personnelles le journal contient et pourquoi elles sont conservées. Un flux unique et indifférencié peut être à la fois trop bruyant pour une personne et trop faible pour une enquête.

La deuxième question est la portée. Un journal utile enregistre les événements qui comptent pour la finalité et le risque visés, pas chaque geste accessoire. Pour un système qui ne rédige que du texte interne, l'événement pertinent peut être l'invocation, l'ensemble des sources, la version du modèle, la version des instructions, la validation humaine et le sort final. Pour un système qui peut modifier un enregistrement externe, les transitions d'état et les accusés de réception des outils deviennent essentiels. Pour un système qui appuie une décision à fort impact, la portée des entrées, la sortie, l'examen humain et la voie de correction importent plus qu'un compteur décoratif de jetons. L'enregistrement doit suivre la conséquence.

La troisième question est l'intégrité. Un enregistrement qui peut être modifié sans être détecté peut encore être utile pour l'exploitation, mais il constitue une revendication plus faible sur l'histoire. Les contrôles d'intégrité peuvent inclure des restrictions d'accès, un stockage en ajout seul, des sommes de contrôle, des signatures, des références temporelles indépendantes, des corrections contrôlées et une conservation documentée. Le mécanisme approprié dépend du risque. L'important est de préciser ce que le mécanisme protège et ce qu'il ne protège pas. La preuve de falsification peut montrer qu'un enregistrement a changé. Elle ne peut pas montrer que l'enregistrement original était complet ou que l'événement capturé était licite.

La quatrième question est celle de la vie privée. Les journaux peuvent contenir des invites, des identifiants, des extraits de sources, des sorties de modèle, des arguments d'outil et des notes humaines. Les conserver tous indéfiniment peut créer un second problème au nom de la résolution du premier. Le règlement lui-même relie les obligations de journalisation aux autres droits de l'Union et aux droits nationaux, y compris la protection des données. Une conception sensée sépare les preuves opérationnelles du contenu superflu, limite l'accès, définit la conservation et permet la correction ou la suppression lorsque cela est requis. La minimisation n'est pas une ennemie de la responsabilité. C'est ce qui empêche la responsabilité de devenir une licence pour constituer une biographie privée de chaque utilisateur.

La cinquième question est celle de la relecture. Rejouer ne signifie pas toujours relancer un modèle probabiliste en espérant obtenir la même phrase. Cela peut signifier reconstruire l'état pertinent : les versions du modèle et de la politique, les références de sources, la classification des entrées, le jeu d'instructions, la sortie, l'intervention humaine, le résultat de l'outil et l'action subséquente. Une relecture peut révéler qu'une reproduction exacte est impossible parce qu'une dépendance distante a changé. Ce résultat constitue néanmoins une preuve si le système indique ce qui a été conservé, ce qui ne l'a pas été et pourquoi. La limite honnête de la relecture a plus de valeur qu'un bouton théâtral étiqueté « reproduire ».

Enfin, les journaux ont besoin d'un propriétaire. Un champ sans propriétaire devient une promesse orpheline. Quelqu'un doit décider quels événements sont pertinents, vérifier que l'enregistrement fonctionne, surveiller les défaillances dans le chemin de journalisation, protéger l'accès, tester la récupération et retirer les enregistrements conformément à la finalité déclarée. Le propriétaire peut être une équipe plutôt qu'une personne, mais la responsabilité ne peut pas être déléguée à un compartiment de stockage. Le compartiment n'assiste pas à la réunion d'examen. Il a également une compréhension décevante de la proportionnalité.

La documentation est une description vivante

La documentation technique est parfois traitée comme le lieu où une équipe d'ingénierie explique un produit à elle-même. Au titre de la législation sur l'IA, elle a un public plus large. Elle doit fournir des informations qu'une autorité nationale compétente ou un organisme notifié peut utiliser pour évaluer la conformité. Cela change le ton du document. Il ne doit pas être une publicité pour le système, ni un carnet privé rempli de références que personne d'autre ne peut suivre. C'est une description maîtrisée de la finalité, de la conception, du fonctionnement, des limites, des données, des tests et des modifications.

Une description vivante entretient une relation avec l'identité du système. Elle nomme le fournisseur, la finalité prévue et les versions pertinentes. Elle explique comment le système interagit avec d'autres logiciels et matériels. Elle décrit les composants et les processus qui affectent les exigences. Elle consigne les tests et les validations qui étayent les allégations de performance. Elle identifie les conditions prévisibles qui peuvent modifier le comportement. Elle énonce les interfaces et les mesures de surveillance dont un déployeur a besoin. Cela ne signifie pas que le document doive divulguer sans discernement des secrets commerciaux. Cela signifie que la confidentialité ne peut pas devenir une excuse pour ne pas avoir de compte rendu évaluable.

Le versionnage est le point charnière. Un document qui change sans historique peut dissimuler un changement en faisant passer le nouvel état pour l'ancien. Un historique qui consigne chaque correction de ponctuation peut enterrer un changement substantiel dans un bruit inoffensif. Un registre de modifications utile identifie ce qui a changé, pourquoi cela a changé, qui l'a autorisé, quelle évaluation a été répétée, quels documents en aval doivent être mis à jour et quand le nouvel état est entré en vigueur. La législation sur l'IA fait référence à la modification substantielle à plusieurs endroits. Une organisation a besoin d'un moyen de remarquer le changement avant que l'étiquette ne devienne un sujet de litige.

La provenance s’applique aussi aux hypothèses. Un système peut reposer sur une hypothèse concernant la population représentée dans un jeu de données, la fraîcheur d’une source, la signification d’un champ ou la compétence de la personne qui déploie le système. Les hypothèses ne sont pas des imperfections gênantes à dissimuler dans une note de bas de page. Elles constituent les limites de la prétention du système. Un enregistrement qui les nomme donne à un opérateur la possibilité de reconnaître quand la limite est atteinte. Un enregistrement qui les dissimule invite à utiliser le système en dehors des conditions dans lesquelles ses preuves avaient un sens.

La documentation doit rendre l’incertitude lisible sans prétendre que chaque inconnue peut être quantifiée. Certaines incertitudes sont numériques. D’autres concernent une couverture manquante, des conflits non résolus, une évolution du droit, des entrées nouvelles ou une interaction non testée avec un autre composant. Une bonne description peut indiquer qu’une condition n’a pas été évaluée, qu’un résultat dépend d’un jugement humain ou que le système ne devrait pas être utilisé à une fin nommée. Ces déclarations ne sont pas des signes de faiblesse d’un système. Elles constituent l’information qui permet à un système solide de rester dans le cadre de sa justification.

Il existe une différence entre une limitation et un refus. Une limitation indique où la prétention d’un système devient peu fiable. Un refus indique que le système ne procédera pas dans une condition donnée. Les deux doivent être documentés. Si un utilisateur ne voit qu’une erreur générique, l’organisation perd la possibilité d’expliquer si la restriction protège la sécurité, la vie privée, les droits, la qualité ou la capacité. Des enregistrements de refus clairs soutiennent également l’amélioration. Des refus répétés peuvent montrer qu’un flux de travail demande au système d’effectuer une tâche pour laquelle il n’a jamais été conçu.

La supervision humaine a besoin de preuves autour d’elle

Les dispositions de l’AI Act relatives à la supervision humaine sont faciles à résumer et difficiles à mettre en œuvre. Désigner une personne ne revient pas à permettre la supervision. La personne a besoin de compétences, de formation, d’autorité et de soutien. Elle doit comprendre les capacités et les limites, détecter les anomalies, éviter le biais d’automatisation, interpréter les résultats et décider de ne pas utiliser, de remplacer, d’inverser ou d’arrêter le système. Ce sont des pouvoirs opérationnels. Une personne techniquement désignée comme relecteur mais qui ne peut pas voir l’entrée, modifier le résultat ou suspendre le flux de travail est un témoin, pas un superviseur.

Les enregistrements peuvent montrer si la supervision avait une réelle portée. Ils peuvent identifier le rôle assigné, les informations présentées, l’avertissement ou la limitation affichée, l’action prise par le relecteur et la décision finale. Ils peuvent conserver une raison pour un remplacement sans obliger une personne à rédiger un essai à chaque fois. Ils peuvent également montrer quand le système était indisponible ou quand la voie de relecture a été contournée. L’absence d’une action humaine n’est pas automatiquement une faute. C’est un signal pour examiner si la conception a rendu l’action possible, nécessaire et visible.

Considérez un modèle proposé plutôt qu’un événement signalé. Un système fournit une recommandation et un court panneau de preuves. Le relecteur peut accepter, modifier, rejeter ou escalader. L’interface enregistre la version du système, les références de sources, l’état de la politique, le rôle du relecteur et la décision. Si le relecteur rejette la recommandation, l’enregistrement stocke une raison contrôlée et envoie un cas pour suivi lorsque le modèle suggère un défaut récurrent. Ce n’est pas une affirmation que le modèle est suffisant pour chaque contexte à haut risque. Cela montre comment une interface peut transformer la supervision humaine d’une case à cocher en une partie observable de la décision.

La supervision humaine doit aussi être protégée de la fatigue et de la pression sociale. Un historique qui montre des milliers d’approbations mais aucune intervention significative peut indiquer que le processus est sain, ou bien que le relecteur ne peut pas réellement contester le résultat. Les chiffres seuls ne permettent pas de trancher. Une routine de suivi utile combine les décisions avec l’échantillonnage, les constats d’erreur, la qualité des escalades, le temps disponible, la formation et les conséquences d’une mauvaise réponse. La mesure doit éclairer le travail, et non créer un quota qui apprend aux gens à approuver plus vite.

La supervision doit inclure le droit d’arrêter. L’article 14 décrit l’intervention ou l’interruption par un bouton d’arrêt ou une procédure similaire permettant au système de s’arrêter dans un état sûr. Une commande d’arrêt qui n’existe que dans un manuel d’exploitation n’est pas la même chose qu’une commande qu’une personne autorisée peut atteindre sous pression. L’historique doit montrer si l’arrêt était disponible, qui pouvait l’utiliser, quel état a suivi et comment le processus a repris. Un système qui peut être arrêté mais qui ne peut pas expliquer ce qui a été arrêté n’a résolu que la moitié du problème.

Il y a un côté humain dans ces preuves. Lorsqu’un résultat est contesté, les enregistrements peuvent protéger le relecteur autant que la personne concernée. Ils peuvent montrer que le relecteur a vu une limite, a suivi la procédure, a escaladé un conflit ou a arrêté une action risquée. Cela ne rend pas chaque décision correcte. Cela rend visibles les conditions du jugement. La responsabilité n’est pas la chasse à la plus proche empreinte humaine. C’est la tentative de comprendre la chaîne assez bien pour l’améliorer.

Le système qualité derrière la paperasse

L’article 17 exige que les fournisseurs de systèmes d’IA à haut risque mettent en place un système de gestion de la qualité et le documentent de manière systématique et ordonnée par des politiques, des procédures et des instructions. Sa liste est volontairement large. Elle comprend la conformité réglementaire et la gestion des modifications, les contrôles de conception et de développement, les essais et la validation, les spécifications techniques, la gestion des données, la gestion des risques, la surveillance après mise sur le marché, le signalement des incidents graves, la communication avec les autorités et les autres opérateurs, la tenue des registres, la gestion des ressources et un cadre de responsabilité pour la direction et le personnel.

Lue dans son ensemble, cette exigence ne demande pas un dossier de conformité de plus. Elle demande que l’organisation puisse relier ses décisions. La procédure d’essai doit avoir un lien avec le risque. Le processus de données doit avoir un lien avec la finalité prévue. Le processus de modification doit avoir un lien avec la documentation. Le processus de surveillance doit avoir un lien avec les actions correctives. Le cadre de responsabilité doit avoir un lien avec les personnes qui peuvent réellement modifier le système. Si chaque document est tenu isolément, le système qualité devient une archive de bonnes intentions sans rapport entre elles.

Un enregistrement qualité utile répond à quatre questions pratiques. Ce qui était censé se produire. Ce qui s’est réellement produit. Comment la différence a été remarquée. Ce qui a changé en conséquence. La réponse peut être répartie entre un registre des risques, un rapport d’essai, un enregistrement de modification, un rapport d’incident et une décision de mise en production. Cela est acceptable si les relations sont stables et intelligibles. Cela ne l’est pas si un relecteur doit deviner quels fichiers appartiennent au même état du système ou quel résultat d’essai a été utilisé pour appuyer une mise en production particulière.

Le système doit aussi pouvoir enregistrer une décision de ne pas modifier. Un risque peut être évalué et jugé acceptable dans les conditions documentées. Une fonctionnalité proposée peut être rejetée parce que les preuves sont insuffisantes. Une mise en production peut attendre parce qu’une évaluation est incomplète. Ce sont des décisions fondées, et non des cases vides dans le calendrier. Les enregistrer évite qu’un lecteur ultérieur confonde une limite délibérée avec une omission accidentelle. Cela aide aussi une équipe à résister à la pression de transformer chaque question non résolue en plan de lancement.

La gestion de la qualité a une dimension temporelle. Un processus qui fonctionnait pour un modèle statique peut ne plus fonctionner lorsque le système apprend après son déploiement, modifie son index de recherche ou reçoit un nouvel outil. Un processus qui fonctionne pour un assistant interne peut ne plus fonctionner lorsque le même composant est intégré à un flux de décision. L’enregistrement doit donc identifier les déclencheurs de révision : une version de modèle, une source de données, une finalité, une population d’utilisateurs, une permission d’outil, une exigence légale, un incident ou une tendance dans la surveillance. Le déclencheur fait partie du contrôle.

La proportionnalité compte également ici. Le règlement précise que la mise en œuvre doit être proportionnée à la taille de l’organisation du fournisseur, tout en respectant la rigueur et la protection nécessaires à la conformité. Proportionné ne signifie pas informel. Un petit fournisseur peut utiliser un ensemble compact d’enregistrements bien conçus plutôt que de reproduire la machinerie d’une grande institution. Il doit néanmoins savoir qui est responsable de chaque décision, où les preuves sont stockées, comment les modifications sont évaluées et comment une autorité peut obtenir les informations dont elle a besoin. Petit ne signifie pas exempt de mémoire.

La conservation est un choix de conception

L’article 18 exige que les fournisseurs tiennent la documentation spécifiée à la disposition des autorités nationales compétentes pendant une période se terminant dix ans après la mise sur le marché ou la mise en service d’un système d’IA à haut risque. L’article 19 traite des journaux générés automatiquement et exige qu’ils soient conservés, lorsqu’ils sont sous le contrôle du fournisseur, pendant une période appropriée à la finalité prévue et d’au moins six mois, sauf disposition contraire d’une autre loi, y compris la législation sur la protection des données. Ce sont des exigences légales aux portées précises. Elles ne doivent pas être généralisées à la légère à chaque enregistrement de chaque flux d’IA.

La leçon pratique est que la conservation doit être conçue par catégorie d’enregistrement. La documentation technique, les enregistrements du système de qualité, les éléments de conformité, les journaux, les données sources, les notes humaines, les ensembles d’évaluation, les preuves d’incident et les explications publiques peuvent avoir des finalités et des durées de vie différentes. Un paramètre de conservation par défaut unique est un raccourci architectural, pas une stratégie de gouvernance. Il peut effacer des preuves trop tôt ou conserver des éléments sensibles bien après la fin de leur finalité. Le système doit savoir quelle couche il détient et pourquoi.

La conservation a également besoin d’un début et d’une fin. Un enregistrement qui indique « conserver dix ans » sans définir l’événement à partir duquel la période court n’est pas opérationnellement complet. Un journal conservé six mois sans préciser si la période suit l’événement, la publication ou la fin d’un cycle de surveillance invite à une confusion évitable. Le texte juridique fournit les points d’ancrage pertinents pour les obligations spécifiques. L’organisation doit mapper ces points d’ancrage aux états du système et rendre ce mappage inspectable.

La suppression d’un enregistrement est elle-même un événement. Si une invite de travail est supprimée parce que sa finalité a pris fin, le système peut devoir conserver une référence montrant que la suppression a eu lieu et quelle règle de conservation l’a autorisée. Si une erreur est corrigée, la preuve originale peut devoir rester disponible sous un historique contrôlé plutôt que de disparaître sans explication. Si des données personnelles sont supprimées, les artefacts dérivés et les chemins d’accès peuvent nécessiter une analyse distincte. L’enregistrement de la suppression ne doit pas être confondu avec une preuve que chaque copie a disparu. C’est la preuve d’une action contrôlée dans un périmètre défini.

La conservation peut également protéger l’apprentissage institutionnel. Une revue d’incident qui ne conserve que la conclusion finale perd les conditions qui ont produit le problème. Un enregistrement d’évaluation qui ne conserve qu’un score perd la charge de travail, la population, la méthode et les limites qui rendaient le score interprétable. Un enregistrement de correction qui ne conserve que la nouvelle valeur perd le fait qu’une valeur erronée a circulé dans un système. Tout conserver n’est pas la réponse. Conserver les bonnes preuves pour la question posée l’est.

Lorsque les preuves manquent

The most useful record systems are designed for absence. They can say that a source was unavailable, that a field was redacted, that a version identifier was unknown, that a human review did not occur, that a tool acknowledgement failed or that a replay cannot be completed. This is not an invitation to manufacture a tidy placeholder. It is a way to prevent missing evidence from being silently converted into confidence.

Absence has types. Not collected means the system never attempted to preserve the field. Not available means the field existed elsewhere but could not be obtained. Not applicable means the condition did not belong to the workflow. Redacted means the evidence exists but is restricted under a rule. Conflicted means two sources disagree. Unknown means the organisation has not established the answer. These labels are proposed operating vocabulary, not terms mandated by the AI Act. Their value is that they keep different problems from collapsing into one empty cell.

A completeness inspector should therefore ask questions, not count fields. Does the record identify the system state. Does it show the purpose and input scope. Can the source or policy basis be found. Is the human authority visible. Are uncertainty and exclusions named. Can a person correct, appeal, suspend or delete within the applicable boundary. The answers depend on context. A record may be complete for an operational alert and incomplete for an individual decision. Completeness is a relationship between evidence and consequence.

Missing records should trigger a response that matches the risk. A low-impact missing label may be repaired in the next release. A missing model version for a consequential decision may require the decision to be reviewed or the workflow suspended. A missing log of a state-changing tool call may require investigation outside the model team. The organisation should decide these thresholds before the incident, because deciding them during a heated review usually produces a policy made of adrenaline.

The absence path also needs an owner and a timestamp. If a required record cannot be produced, someone should know who is responsible for investigating, who can decide whether work continues, which evidence is being sought and when the status will be reviewed. That turns a gap into a managed state. It does not make the gap harmless. It prevents the institution from pretending that a missing page is an empty page.

The AI Office and the work of interpretation

The AI Act creates institutions and procedures that help turn the Regulation into practice. The Commission’s AI Office has a role in supervising and enforcing the obligations for general-purpose AI models, while national competent authorities and market surveillance authorities have responsibilities within the broader framework. The AI Act Service Desk provides an explainer for Article 12 that summarises the record-keeping duty and points readers to the official text. Its summary is explicitly non-binding. That distinction is worth preserving.

Guidance can make a rule usable by translating a legal requirement into examples, questions and implementation choices. It cannot replace the Regulation. An organisation should be able to show which claim comes from the binding text, which comes from guidance and which is its own control decision. This source discipline is not academic fussiness. It prevents a helpful example from becoming a fictional obligation and prevents a voluntary practice from being marketed internally as a legal minimum.

La communication AI@EC de la Commission offre un exemple institutionnel utile, sans prétendre décrire tous les organismes publics. En janvier 2024, la Commission a défini une approche pour son propre développement et usage de l'IA, incluant des orientations opérationnelles internes, une évaluation et une classification fondées sur les risques, l'évitement de systèmes incompatibles avec les valeurs européennes ou menaçant les droits et la sécurité, ainsi que des structures organisationnelles pour remplir ses obligations. L'idée n'est pas qu'une communication résolve la mise en œuvre. L'idée est qu'une institution qui se prépare à utiliser l'IA doit aussi préparer sa propre capacité à encadrer cet usage.

Cette capacité se construit à partir de dossiers qui peuvent circuler. Une politique doit désigner un responsable. Une évaluation des risques doit renvoyer à une identité de système. Une description technique doit renvoyer à une version. Un dossier de formation doit renvoyer à un rôle et à une compétence. Un signal de surveillance doit renvoyer à une action. Une plainte doit renvoyer à une voie de recours. Lorsque ces relations sont explicites, les orientations peuvent être appliquées sans inventer un univers parallèle de paperasse. Lorsqu'elles ne le sont pas, chaque nouvelle orientation devient un document supplémentaire dont l'organisation espère qu'il modifiera les comportements.

Le droit européen possède une texture institutionnelle particulière. Les responsabilités sont réparties entre les institutions de l'Union, les États membres, les autorités, les fournisseurs, les déployeurs et les autres opérateurs. Un dossier doit rendre cette répartition visible plutôt que de fondre chaque acteur dans un propriétaire de système générique. La question n'est pas seulement de savoir qui a construit le modèle. Elle est de savoir qui l'a mis en service, qui contrôle les données d'entrée, qui a assigné la supervision, qui peut suspendre l'usage et qui doit coopérer avec une autorité. Les noms et les contrats comptent, mais aussi les pouvoirs opérationnels qu'un dossier peut révéler.

Du langage juridique à la routine quotidienne

Le droit devient pratique lorsqu'une organisation convertit chaque obligation en un petit nombre de routines répétables. Il s'agit d'un modèle de fonctionnement proposé, non d'une liste de contrôle juridique. À l'admission, classifiez l'objectif visé, les personnes concernées, les catégories de données, l'autonomie, les outils et l'autorité de décision. Avant la mise en service, liez l'identité du système, la version, l'état des instructions, les sources de données, les tests, les limites, le rôle de supervision et la voie d'arrêt. Pendant l'exploitation, consignez les événements pertinents, surveillez les risques et rendez l'incertitude visible. Après un changement ou un incident, enquêtez, corrigez, mettez à jour la description et décidez si l'usage doit se poursuivre.

Remarquez ce que ce modèle ne dit pas. Il ne dit pas de conserver chaque message indéfiniment. Il ne dit pas qu'un journal automatisé équivaut à une explication. Il ne dit pas qu'un tableau de bord prouve la sécurité. Il ne dit pas qu'un nom humain dans un flux de travail prouve la supervision. Il dit que le système doit disposer d'un dossier indiquant les conditions dans lesquelles il est autorisé à fonctionner et les événements qui peuvent montrer si ces conditions ont été respectées.

Une bonne routine a un début et une fin. Un dossier est créé lorsqu'un état significatif commence, mis à jour lorsque les preuves ou l'autorité changent, et clos lorsque l'objectif ou la période d'examen se termine. L'événement de clôture importe, car les dossiers ouverts deviennent silencieusement permanents. Il doit indiquer si le système a été mis en service, rejeté, suspendu, remplacé, corrigé ou retiré. Si le dossier ne peut pas être clos, l'organisation doit savoir pourquoi. Un statut provisoire sans fin est une manière polie d'éviter une décision.

Les routines doivent aussi distinguer les faits des interprétations. Un journal peut consigner qu'un modèle a produit une sortie. Un évaluateur peut consigner que la sortie a été rejetée parce qu'une source entrait en conflit avec une politique. Une équipe d'incident peut ensuite déduire qu'un changement de récupération a contribué au conflit. L'inférence peut être solide, mais elle ne constitue pas le même type de preuve que l'événement. Des couches étiquetées rendent les investigations ultérieures plus honnêtes. Sans elles, chaque conclusion se durcit progressivement en fait, parce que personne ne se souvient quelle phrase a été observée et laquelle a été écrite en réunion.

La propriété devrait être visible au niveau du champ lorsque c'est réalisable. Le fournisseur peut être propriétaire de la documentation technique. Un déployeur peut être propriétaire de la pertinence des entrées et de la surveillance opérationnelle. Un délégué à la protection des données peut être propriétaire des droits de source et de la qualité. Un rôle de supervision humaine peut être propriétaire de la décision d'accepter, de remplacer ou d'arrêter. Une fonction d'enregistrement peut être propriétaire de la conservation et de l'accès. La répartition variera selon le contexte et le contrat. L'enregistrement devrait permettre de poser une question au bon propriétaire sans envoyer un courriel circulaire à toute l'organisation.

Tester la procédure est aussi important que de la rédiger. Un contrôle proposé devrait être exercé avec un scénario sûr et clairement étiqueté. L'équipe peut-elle récupérer l'enregistrement par version du système ? Un opérateur peut-il voir l'état des instructions utilisé lors de la publication ? Un examinateur peut-il rejeter une sortie et conserver la raison ? Le chemin d'arrêt peut-il laisser un état clair ? Une autorité compétente peut-elle recevoir la documentation pertinente sans chasse au trésor ? Ce sont des exercices, pas des incidents signalés. Leurs résultats devraient être enregistrés comme des tests, avec toutes les limitations énoncées clairement.

La procédure devrait être conçue pour un jour calme. Si elle ne fonctionne que lorsqu'un spécialiste est éveillé, qu'un fournisseur répond rapidement et que tout le monde se souvient de l'historique de déploiement, ce n'est pas une procédure. C'est une mémoire collective avec un accord de niveau de service. Un système d'enregistrement sérieux donne au personnel ordinaire un moyen de répondre à des questions ordinaires, et il donne aux spécialistes un chemin plus profond lorsque la question devient conséquente. Le jour calme est celui où le système gagne le droit d'être digne de confiance le jour bruyant.

Il y a une tentation de rendre les enregistrements beaux. Une conception claire aide les gens à les utiliser, mais le poli visuel n'est pas une preuve. Un statut coloré, un score de maturité ou une carte d'aspect complet peuvent cacher des champs manquants. L'interface devrait rendre l'incertitude, les données obsolètes et les affirmations non vérifiées plus difficiles à ignorer. Elle devrait soutenir les actions ennuyeuses qui maintiennent un enregistrement véridique : épingler une version, identifier une source, nommer un rôle, marquer une limitation, lier une correction et clore un état. Une bonne conception donne des poignées à l'enregistrement. Elle ne donne pas à l'enregistrement des pouvoirs qu'il n'a pas gagnés.

Une petite note de notre part

Chez Dweve, notre Centre de confiance est organisé autour de cette même question : qu'est-ce qu'une autre personne devrait pouvoir inspecter à propos d'un modèle et de son fonctionnement. L'index public relie l'identité du modèle, le contenu de la formation, les évaluations, la gestion des risques, la surveillance après mise sur le marché, les incidents, la gouvernance des données et la documentation technique. Cet arrangement n'est pas une affirmation qu'une page publique prouve la conformité, et ce n'est pas un substitut à l'évaluation d'une autorité. C'est une tentative délibérée de garder les enregistrements et leurs limites visibles. Notre travail Ledger fait un argument connexe au niveau opérationnel : un enregistrement devrait porter suffisamment d'identité et d'historique pour qu'un lecteur ultérieur puisse vérifier ce qui a changé. Le test utile n'est pas de savoir si la page semble rassurante. C'est de savoir si les preuves disent la vérité sur ce qu'elles peuvent et ne peuvent pas établir.

Les enregistrements font partie de l'institution

L'erreur la plus profonde est de traiter les exigences d'enregistrement de l'AI Act comme une taxe sur l'innovation. Elles sont mieux comprises comme une description de ce dont une institution a besoin pour utiliser un système puissant et changeant sans abandonner sa mémoire. Un modèle peut produire une sortie rapidement. Une institution doit décider si la sortie appartient à une décision, si quelqu'un peut la contester, si une correction peut traverser le système et si un lecteur futur peut comprendre le chemin.

Voilà pourquoi les enregistrements ne peuvent pas être laissés à la périphérie de l'architecture. Ils ont leur place à côté des données, des instructions, des versions de modèles, des outils, des interfaces, des rôles humains et des recours. L'enregistrement est le tissu conjonctif qui permet à ces éléments de répondre les uns aux autres. Il transforme une déclaration de risque en une condition vérifiable. Il transforme une source en une base traçable. Il transforme une approbation humaine en un acte observable. Il transforme une correction en un changement qui peut être contrôlé. Il transforme un champ manquant en une question gérée plutôt qu'en un vide dont personne n'est responsable.

Le travail est discret parce qu'il semble ordinaire. Nommer le système. Fixer l'objectif. Enregistrer la version. Maintenir la frontière de la source. Tester le journal. Donner à l'examinateur l'autorité nécessaire. Marquer ce qui est inconnu. Préserver la réponse. Retirer l'enregistrement lorsque l'objectif prend fin. Rien de tout cela n'a le glamour d'une vidéo de lancement. Cela a la propriété plus précieuse de survivre à un changement de personnel, à un changement de modèle, à un changement de fournisseur et à une question posée par quelqu'un qui n'était pas dans la pièce.

Il y aura toujours des désaccords sur l'interprétation de l'AI Act, sur le niveau de détail approprié et sur la manière dont les normes traduiront les exigences légales en pratique technique. Les enregistrements n'éliminent pas ces arguments. Ils les rendent plus précis. Une organisation peut montrer quel texte elle a utilisé, quelle hypothèse elle a formulée, quelles preuves elle avait, quel contrôle elle a choisi et où demeure son incertitude. C'est un meilleur point de départ pour un régulateur, un collègue, une personne concernée et l'organisation elle-même.

La leçon pratique est simple. Ne demandez pas seulement si un système d'IA peut produire un résultat. Demandez si l'institution peut se souvenir des conditions de ce résultat, montrer les preuves qui importaient, nommer l'autorité qui a agi, identifier l'incertitude qui demeurait et faire voyager une correction. Si la réponse est non, le système peut toujours être techniquement impressionnant. Il n'est pas encore prêt sur le plan institutionnel.

Le travail discret de l'AI Act de l'UE ne consiste donc pas à faire paraître la technologie sérieuse. Il consiste à rendre le sérieux observable. Les enregistrements ne sont pas des slogans horodatés. Ce sont des preuves délimitées, créées dans un but précis, liées à la responsabilité et ouvertes à la correction. Construisez-les avec soin, et une organisation peut utiliser l'IA sans demander à la fluidité de remplacer la mémoire. Laissez-les en après-coup, et la première question difficile découvrira que le système a conservé sa sortie mais a égaré son historique.

Sources