Un régulateur peut-il auditer une cible mouvante ?

Oui, mais pas en prétendant qu'un système adaptatif est un objet statique. Un audit exige un état capturé, une revendication délimitée, des preuves...

Un régulateur peut-il auditer une cible mouvante ?

Un audit a le droit de prendre une photographie

Une cible mouvante n'échappe pas à l'examen. Elle échappe seulement au type d'examen qui pose une question intemporelle et attend une réponse intemporelle. Cette distinction compte. Les systèmes d'IA évoluent de plusieurs manières à la fois. Un fournisseur publie une nouvelle version de modèle. Un déployeur modifie l'invite ou le seuil de décision. Un corpus de récupération gagne un nouveau document de politique. Une règle d'identité change qui peut appeler un outil. Un outil gagne un champ, en perd un, ou commence à renvoyer un sens différent sous le même nom de champ. Une équipe humaine change sa procédure. Le monde qui fournit les entrées change sans demander l'avis du responsable des versions de qui que ce soit.

Aucun de ces éléments ne rend un audit futile. Cela rend l'objet de l'audit plus précis. La question n'est pas de savoir si une organisation peut prouver qu'un système restera inchangé pour toujours. Ce serait une promesse étrange même pour une calculatrice connectée à une base de données. La question est de savoir si l'organisation peut montrer quel système était en fonctionnement à un moment pertinent, ce qu'il était censé faire, quelles preuves soutenaient cet usage, quelles conditions délimitaient ces preuves, qui détenait la décision, et quel changement ultérieur devrait conduire à rouvrir la décision.

Un audit a le droit de prendre une photographie. Il ne doit simplement pas appeler la photographie le paysage. Un enregistrement approprié identifie l'état qui a été inspecté et conserve le chemin de cet état au suivant. Il peut alors dire quelque chose d'utile : cette évaluation concernait ce modèle, ces paramètres, cette limite de données, ces outils, cette politique, ce flux de travail et cette décision de publication. Il peut aussi dire quelque chose de moins confortable et de plus précieux : la conclusion ne s'est pas automatiquement transportée à l'état suivant.

C'est un meilleur point de départ que le théâtre familier des badges immuables. Un badge suggère que quelqu'un a réglé la question. Un enregistrement d'audit devrait permettre de voir ce qui a été réglé, sur quelle base, pour quel usage, et pendant combien de temps cette base est restée applicable. Un régulateur n'a pas besoin d'une organisation figée. Un régulateur a besoin d'une organisation qui peut distinguer un enregistrement figé d'un service en direct sans traiter ni l'un ni l'autre comme un objet mystique.

Les règles européennes sur l'IA pointent déjà dans cette direction. Pour les systèmes d'IA à haut risque, la loi sur l'intelligence artificielle exige une documentation technique avant qu'un système ne soit mis sur le marché ou mis en service, et exige qu'elle soit tenue à jour. Elle exige également l'enregistrement automatique des événements pertinents pendant la durée de vie du système et un système documenté de surveillance après mise sur le marché proportionné à la technologie et au risque. Ce ne sont pas des instructions pour capturer une seule capture d'écran cérémonielle. Ce sont des instructions pour conserver une piste de preuves à travers le changement.

La cible mouvante est généralement un système

Il est tentant de décrire un système d'IA comme un modèle, puis de discuter du versionnage comme si un nouveau fichier de poids de modèle était toute l'histoire. C'est pratique pour les présentations et inexact pour la plupart des questions opérationnelles. Un modèle est un composant important. Il est rarement l'objet complet dont le comportement affecte une personne, un flux de travail ou une obligation légale.

Considérons un parcours ordinaire d'aide à la décision, décrit ici comme un exemple hypothétique plutôt que comme le compte rendu d'un déploiement réel. Un utilisateur soumet une demande. Le service récupère les documents qu'il est autorisé à utiliser. Un modèle rédige une recommandation. Une règle vérifie si les preuves requises sont présentes. Un examinateur formé peut accepter, modifier ou rejeter la recommandation. Un flux de travail enregistre ensuite une action. Le résultat observé dépend de plus que du modèle. Il dépend des versions des sources, des paramètres de récupération, des autorisations, du libellé de l'interface, des seuils, des règles de file d'attente, de l'autorité humaine et de la limite d'action.

Si le corpus source change, le modèle peut recevoir une base factuelle différente sans qu'un seul paramètre ne soit modifié. Si une invite change, un modèle peut être amené à porter un type de jugement différent. Si un écran de relecture cesse d'afficher l'incertitude, la supervision humaine décrite dans un fichier de risques peut ne plus être celle que les personnes exercent réellement. Si une intégration commence à appliquer des recommandations automatiquement, le système acquiert une nouvelle autorité, même si la réponse du modèle est identique octet pour octet.

C'est pourquoi un registre d'audit pertinent commence par l'objectif visé et le périmètre du système. Les exigences de documentation technique de l'AI Act à l'annexe IV incluent des descriptions de l'objectif visé, des versions, des fonctions de surveillance et de contrôle, de la validation et des tests, de la gestion des risques, des modifications apportées au cours du cycle de vie et des indicateurs de performance pertinents. L'idée n'est pas que chaque système nécessite une cathédrale de paperasse. L'idée est qu'un relecteur ne peut pas évaluer une affirmation lorsque l'objet désigné par cette affirmation change silencieusement de forme.

Appeler système l'objet plus large n'est pas une façon de donner plus d'ampleur au travail. C'est une façon d'éviter une erreur de catégorie. Une évaluation de modèle peut répondre à une question sur le modèle. Un audit de système doit répondre à une question sur le système. La première peut établir comment un composant s'est comporté dans des conditions définies. Le second doit montrer comment ce composant était relié à des personnes, des données, des règles, des outils et des conséquences. Ni l'un ni l'autre ne remplace l'autre. Un score de modèle n'est pas une description de flux de travail, tout comme un bon test de pneu n'est pas un itinéraire.

Ce qu'un auditeur cherche réellement à établir

Auditer un système en évolution ne signifie pas rejouer chaque instant de sa vie dans une salle de réunion. Cela signifie rendre certaines propositions inspectables. Le système a-t-il été utilisé dans le cadre de l'objectif déclaré ? La décision de mise en production était-elle étayée par des preuves adaptées à cet objectif ? L'organisation a-t-elle conservé les informations nécessaires pour enquêter sur un résultat contesté ? Les modifications importantes ont-elles déclenché une réévaluation ? La surveillance a-t-elle rendu visible la différence entre une mise à jour bénigne et un changement substantiel ? Les personnes responsables pouvaient-elles suspendre, limiter ou corriger la trajectoire lorsque les preuves ne tenaient plus ?

Ce sont des questions pratiques, car chacune a un pendant observable. L'objectif visé figure dans un registre. Une évaluation a une suite de tests, une configuration, une population de test ou une limite d'entrée, une méthode, un résultat et des limites. Une décision de mise en production a un responsable et des conditions. Un changement a une identité, une date, une raison et un effet évalué. La surveillance a des signaux nommés, des seuils ou des déclencheurs de revue. Une procédure de suspension a une autorité et une opération. Les détails varient, mais l'auditabilité vient de la transformation d'assurances abstraites en éléments que quelqu'un d'autre peut inspecter.

Il y a ici une limite importante. Un audit ne prouve pas que chaque résultat futur sera correct, équitable ou sans danger. Il ne peut pas transformer un monde incertain en un monde déterministe. Il peut établir si une organisation a formulé des affirmations suffisamment circonscrites pour être examinées, si elle a recueilli des preuves capables d'étayer ces affirmations et si elle a conservé la capacité de les reconsidérer. Cela peut sembler modeste. C'est aussi là que commence la responsabilité.

La différence entre la preuve et le langage d'assurance importe. Dire qu'un modèle a été évalué n'est pas encore une preuve d'une évaluation utile. Le mot a besoin d'un objet. Évalué par rapport à quelle tâche, quels critères et quelles données ? Avec quel modèle et quel état du système ? Dans quelles conditions d'exploitation ? Qui a vérifié la méthode ? Qu'est-ce qui était hors périmètre ? Qu'est-ce qui rendrait le résultat obsolète ? Sans ces questions, l'évaluation n'est qu'un passé rassurant.

Les lignes directrices antérieures de la Commission européenne sur une IA de confiance définissaient la reproductibilité en des termes simples : une expérience d'IA devrait présenter le même comportement lorsqu'elle est répétée dans les mêmes conditions. Cette définition est utile car elle contient sa propre limite. Les mêmes conditions font un travail concret. Une expérience répétée peut montrer si l'affirmation enregistrée est reproductible. Elle ne peut pas montrer qu'un comportement inchangé émergera après une modification de la source de données, de la politique ou du parcours de déploiement. La reproductibilité n'est donc pas une promesse que le monde reste immobile. C'est une discipline pour dire précisément ce qui s'est passé.

Une évaluation capturée est un instantané. L'audit devient durable lorsque l'état suivant peut lui être comparé.

Un numéro de version est nécessaire mais pas suffisant

Les numéros de version sont utiles car ils empêchent un enregistrement de prétendre que les noms suffisent. Pourtant, une étiquette de version peut aussi créer un faux sentiment de sécurité. Une étiquette telle que version 4.2 peut identifier une version logicielle, mais elle n'identifie pas nécessairement l'état effectif d'un parcours d'IA. Une valeur de configuration peut se trouver en dehors du dépôt du modèle. Un index de récupération peut être reconstruit à partir de documents changeants. Un indicateur de fonctionnalité peut choisir un chemin d'outil différent. Un moteur de politique peut modifier une action autorisée. Un service peut donc avoir un numéro de version impeccablement formaté et rester difficile à reconstruire.

Ce qui importe, c'est l'identité adaptée à l'affirmation. Si l'affirmation concerne un benchmark de modèle hors ligne, l'artefact du modèle, le code d'inférence, les paramètres, la version du jeu de données, la définition des métriques et l'environnement d'exécution peuvent être essentiels. Si l'affirmation concerne un service d'aide à la décision en direct, l'enregistrement peut en outre nécessiter le prompt ou le modèle de texte, la configuration de récupération, les identifiants et la fraîcheur des sources, l'état des autorisations, les schémas d'outils, la version de la politique, l'interface de relecture et la règle de flux de travail. Un paquet d'audit n'a pas besoin de contenir chaque octet de chaque système. Il doit contenir ou pointer de manière fiable vers les éléments qui pourraient changer le sens de l'affirmation.

C'est pourquoi un manifeste est souvent plus utile qu'une archive déposée sur un disque dur. Un manifeste indique quels artefacts vont ensemble, leurs identifiants, leurs références d'intégrité, leurs relations et leurs conditions d'accès. Il permet à un auditeur de localiser le paquet pertinent sans supposer que chaque source peut être copiée dans un dossier sans restriction. Certaines preuves contiennent des données personnelles, des détails sensibles pour la sécurité, du matériel sous licence ou des secrets commerciaux. L'auditabilité exige un accès contrôlé et une traçabilité significative, et non une divulgation publique obligatoire de tout ce qui fait fonctionner un système.

L'annexe IV adopte une approche pratique similaire. Elle ne traite pas la documentation technique comme une brève description de produit. Elle demande des informations sur le système et son cycle de vie, y compris les modifications apportées pendant le développement et après la mise sur le marché, les fonctions de surveillance et de contrôle, les procédures et résultats de validation et de test, les mesures de gestion des risques, ainsi qu'une description des indicateurs de performance. Le document doit être suffisamment clair pour permettre aux autorités nationales compétentes et aux organismes notifiés d'évaluer la conformité. En d'autres termes, les informations doivent être organisées pour être examinées, et non simplement collectées parce qu'un système de stockage était disponible.

Une question de conception, petite mais décisive, se cache derrière tout cela : qu'est-ce qui devrait changer pour que les preuves antérieures ne puissent plus étayer la présente affirmation ? La réponse crée la limite de version. Si une nouvelle source de récupération modifie le fondement factuel des recommandations, elle appartient à l'identité. Si une nouvelle interface de relecteur masque un avertissement, elle appartient à l'identité. Si une correction cosmétique de copie ne peut pas affecter le comportement évalué, elle appartient probablement à l'historique des modifications, mais pas à l'empreinte d'évaluation. Un bon versionnage n'est pas une collecte maximale. C'est une pertinence raisonnée.

Capturer le contrat, pas seulement le résultat

Un résultat est la preuve de quelque chose, mais ce n'est pas toujours la preuve de suffisamment de choses. Une capture d'écran peut montrer ce qui est apparu à l'écran. Elle ne peut souvent pas montrer quel modèle l'a produite, quelle source a été récupérée, ce qu'un outil a renvoyé, quelle règle a été appliquée, quelles entrées ont été omises, ou si la vue masquait un avertissement. C'est l'une des raisons pour lesquelles les captures d'écran s'accumulent dans les dossiers de conformité avec la solennité de découvertes archéologiques et nettement moins de pouvoir explicatif.

Un contrat capturé est plus riche. Il relie le résultat aux conditions dans lesquelles le système était censé agir. Pour une évaluation, cela peut inclure la suite exacte, les entrées ou une référence protégée à celles-ci, les assertions attendues, la configuration du modèle et du service, les versions pertinentes des politiques et des outils, l'environnement d'exécution lorsqu'il affecte le résultat, et la règle d'acceptation. Pour une exécution en direct, cela peut inclure l'identité de la demande, le périmètre autorisé, les enregistrements de source et de récupération, la route du modèle, les appels d'outils, les contrôles, l'intervention humaine et le changement d'état résultant. L'objectif n'est pas d'enregistrer un journal sans fin. C'est de conserver suffisamment d'informations causalement pertinentes pour pouvoir poser une question sérieuse plus tard.

Une distinction utile s'impose. Une capture d'évaluation démontre une affirmation concernant un test ou un exercice défini. Un enregistrement opérationnel aide à reconstituer un événement ou une décision particulière. Un enregistrement de version explique pourquoi une organisation a autorisé un système dans une route définie. Un enregistrement de modification explique ce qui a changé ensuite. Ces enregistrements se chevauchent, mais ils ne doivent pas être confondus. Traiter un journal de production comme un benchmark, ou un benchmark comme une preuve d'un flux de travail de production, est un moyen efficace de faire porter à chaque enregistrement plus qu'il ne peut supporter.

La règle de journalisation de l'AI Act pour les systèmes à haut risque est également liée à un objectif. L'article 12 exige l'enregistrement automatique des événements pertinents pendant toute la durée de vie du système, avec des capacités de journalisation adaptées à l'objectif visé. Le Règlement fait référence à la traçabilité du fonctionnement du système, à la surveillance de l'exploitation et à la surveillance après mise sur le marché. Il n'exige pas une habitude d'enregistrement indistincte. Il exige des enregistrements qui ont une fonction.

Cette expression, « dossiers avec un emploi », est un meilleur guide qu’une demande générique d’observabilité. L’identifiant du modèle peut aider à distinguer une mise à jour. La provenance des données d’entrée peut expliquer une recommandation surprenante. Une version de règle peut expliquer pourquoi un résultat a été bloqué. Une dérogation de relecteur peut expliquer pourquoi l’action opérationnelle diffère de la proposition du modèle. Un horodatage peut établir un ordre. Une conception soucieuse de la vie privée se demande encore si chaque champ est nécessaire, proportionné, conservé pour une durée définie et protégé du système même qu’il est censé inspecter.

La reproductibilité a deux formes honnêtes

Les gens utilisent souvent le mot reproductible pour désigner plusieurs choses différentes. La confusion est compréhensible. Une équipe peut vouloir dire qu’elle peut relancer une évaluation fixe et obtenir le même score. Un chercheur peut vouloir dire qu’une autre équipe peut exécuter la méthode indiquée et inspecter le résultat. Un opérateur peut vouloir dire qu’une enquête peut recréer l’état utilisé pour une décision particulière. Un client peut vouloir dire qu’un flux de travail offre un traitement cohérent plutôt que de changer arbitrairement du mardi au jeudi. Ce sont des objectifs liés. Ce ne sont pas une seule propriété portant plusieurs chapeaux.

Premièrement, il y a la reproductibilité de l’exécution capturée. Si l’artefact, la configuration, les entrées, l’état pertinent et les conditions d’exécution sont maintenus fixes, une répétition devrait produire le résultat documenté dans les conditions promises par le système. Certains systèmes peuvent faire une affirmation déterministe plus forte pour un chemin d’exécution défini. D’autres reposent sur un aléa contrôlé, une infrastructure distribuée ou des services tiers et ne peuvent faire qu’une affirmation plus restreinte. Le langage responsable est précis. Il dit ce qui est fixe, ce qui est mesuré, quelle variation reste possible et comment la comparaison est effectuée.

Deuxièmement, il y a la reproductibilité de l’argument d’évaluation. Un relecteur doit pouvoir voir pourquoi la suite représente l’affirmation, si la métrique a le sens indiqué, si le seuil d’acceptation est justifié et si les preuves peuvent être transposées au contexte opérationnel. Cela n’est pas résolu par une somme de contrôle. Une somme de contrôle peut établir qu’un fichier n’a pas changé. Elle ne peut pas établir que le fichier testait la bonne question, que la population était appropriée ou qu’un score soutient la décision qui lui est attachée.

Les deux formes devraient se rejoindre. Un test parfaitement répétable qui mesure la mauvaise chose reste le mauvais test. Un argument sophistiqué attaché à une exécution non reproductible laisse les relecteurs incapables de distinguer un résultat d’un coup de chance. La norme utile n’est pas une demande abstraite de reproductibilité parfaite. C’est une correspondance visible entre l’affirmation, la méthode, les conditions capturées, le résultat observé et l’usage que l’organisation souhaite permettre.

Les orientations de la Commission sur les obligations des fournisseurs d’IA à usage général maintiennent également l’évaluation liée à la documentation et au risque. Elles décrivent une documentation technique pour les autorités et des informations séparées pour les fournisseurs en aval, y compris les capacités, les limites et les informations d’intégration. Pour les modèles d’IA à usage général présentant un risque systémique, l’article 55 exige une évaluation utilisant des protocoles normalisés et des outils de pointe, y compris des tests contradictoires documentés pour identifier et atténuer les risques systémiques. Une évaluation qui ne peut pas dire ce qui a été testé, dans quelles conditions et avec quelles limites ne devient pas plus utile parce qu’elle est qualifiée de normalisée.

Les preuves ont une condition d’expiration

Les preuves ne périment pas parce que quelqu’un a décidé de se montrer difficile. Elles périment lorsque les conditions qui leur permettaient d’étayer une affirmation ont suffisamment changé pour que le lien ne puisse plus être présumé. C’est un raisonnement ordinaire. Un test de conception de pont ne couvre pas automatiquement un matériau différent. Un contrôle de sécurité alimentaire ne couvre pas un nouveau fournisseur par simple optimisme. Une évaluation d’un itinéraire d’IA ne devrait pas couvrir automatiquement un modèle modifié, une limite de données modifiée, une autorité d’outil modifiée ou une conséquence de décision modifiée.

Le travail difficile consiste à déterminer quels changements importent. Cela relève du jugement technique, de l’analyse des risques et de la gouvernance, et non d’un simple pourcentage inscrit dans une politique. Un correctif qui change la couleur d’un bouton peut n’avoir aucune incidence sur une évaluation. Un changement qui rend un avertissement moins visible peut être important si l’argument de sécurité dépend du fait qu’un évaluateur le voie. Réindexer un corpus source peut être sans danger pour une tâche et critique pour une autre. Un nouveau point de terminaison de modèle peut préserver une capacité générale tout en modifiant la latence, le comportement de refus, la couverture linguistique ou les schémas d’utilisation d’outils qui importent pour l’itinéraire.

Un contrôle utile des changements commence donc par une question d’impact, et non par un rituel de publication. Quelle affirmation ce changement pourrait-il affecter ? Quelle hypothèse perturbe-t-il ? Quelles preuves dépendaient de l’état antérieur ? Un contrôle limité répond-il à la question, ou l’itinéraire nécessite-t-il une nouvelle évaluation et une nouvelle décision de publication ? Qui peut prendre cette décision, et qui peut la contester ? Les réponses devraient être consignées, car sinon le prochain évaluateur devra les déduire des titres de tickets, du folklore et d’un léger changement dans la police utilisée par le tableau de bord de publication.

C’est également là que la surveillance fait partie des preuves plutôt que d’être un passe-temps d’observabilité distinct. L’article 72 exige que les fournisseurs de systèmes d’IA à haut risque collectent, documentent et analysent activement et systématiquement les données pertinentes sur les performances tout au long de la durée de vie du système, afin de pouvoir évaluer la conformité continue. Le plan de surveillance après mise sur le marché fait partie de la documentation technique. La surveillance n’est donc pas simplement un moyen de savoir si le service est occupé. C’est un moyen d’apprendre si les conditions qui sous-tendent l’affirmation initiale continuent de tenir.

La surveillance ne rend pas chaque résultat explicite de lui-même. Une augmentation des désaccords entre les évaluateurs et un système peut avoir de nombreuses causes. Un changement dans la fraîcheur des sources peut refléter un problème de pipeline de données plutôt qu’une dérive du modèle. Un taux de refus plus élevé pourrait représenter une politique plus sûre, une intégration défaillante ou une nouvelle population de demandes. Le dossier devrait préserver suffisamment de contexte pour une enquête humaine. Les métriques sont des signaux. Ce ne sont pas des témoins.

Les preuves sont valables dans un contexte défini. Un changement important soulève une question à examiner, et non une échappatoire à l’examen.

Un changement important nécessite un chemin de décision

The phrase material change is often treated as if it names a self-evident property. It does not. Material to which claim, risk and user? The answer must be specific enough that people can use it when they are tired, late and keen to call a change minor. A good policy does not promise to classify every possible update in advance. It names the factors that determine whether reassessment is needed.

Those factors usually include intended purpose, affected people, authority granted to the route, data sources and their quality controls, model or system architecture, evaluation scope, decision thresholds, monitoring signals, human oversight, security controls and recovery paths. A modification that changes any of these may or may not be material. What matters is whether it can alter the evidence required for the existing claim or the risk left after controls.

The AI Act contains an explicit responsibility around substantial modification. Its exact legal application depends on the system and actors involved, so it should not be compressed into a slogan. The operational lesson is simpler and broader: an organisation should know when a change transfers or creates responsibility, when the existing documentation is no longer adequate, and when the system must be assessed again before a new use continues. It is less exciting than a feature launch. It is also less likely to produce a difficult call in which everyone agrees the system changed but nobody owns the decision.

A decision path gives a change somewhere to go. One path may permit a documented no-impact finding. Another may require a targeted regression evaluation. Another may require a broader risk review, a change to instructions for use, a revised monitoring plan or a fresh release approval. The most serious path may require the route to remain limited or paused until evidence is available. The point is not to make every edit expensive. It is to make the important edit impossible to disguise as routine housekeeping.

There is a satisfying lack of romance in this. A change record can show the previous state, the proposed state, the affected claims, the evidence reviewed, the decision, the authority and the conditions after release. That is governance in its working clothes. It will never look as thrilling as a model demonstration. It has the more useful property of helping an organisation explain itself when a demonstration has become a real service.

Evaluation should be able to fail in public, or at least in the file

Evaluation becomes performative when every result is assumed to be a release result. A mature evaluation programme must be able to conclude that evidence is incomplete, that a threshold was missed, that a known limitation prevents a proposed use, or that a claim needs narrowing. These are not embarrassing exceptions to the process. They are outputs of the process.

That is particularly important for adaptive or externally connected systems. A team may discover that a suite no longer represents a live input population. A tool contract may become too unstable to support a replay claim. A model update may improve one task but make a protected route harder to supervise. An operational signal may show that the hand-off from system to reviewer fails under ordinary workload. The right answer is not necessarily a dramatic shutdown. It may be a limit, a revised workflow, a further test, a new acceptance condition or a decision not to make the original claim.

The record must let a reviewer see that negative result. Otherwise an organisation builds a very effective machine for collecting only the evidence it likes. The quality-management requirements in Article 17 are relevant here. They cover, among other things, techniques and procedures for design, development and quality control; examination, test and validation; data management; risk management; post-market monitoring; incident reporting; and communication with authorities. A quality system is not a folder that makes failures disappear. It is a way to detect, document and address them.

The same principle governs access. An external regulator, notified body or authorised reviewer may need technical evidence that cannot be published openly. A public summary may be appropriate for other parts of the record. These are different access routes, not different facts. The public should not be offered a cheerful account while the controlled record describes a narrower and more conditional reality. Confidentiality can be legitimate. Contradiction is a governance failure.

At Dweve, our public Trust Centre makes a small, deliberately limited example of this distinction. Its evaluations page says that an evaluation identifies the model, exact suite, configuration, captured state, evidence and reviewer decision. It also says that a repeated captured contract should produce byte-identical results on supported architectures, while a live rerun can differ when external evidence or adaptive state changes. The page separates the public method from a filled-in marketing result. That is not proof of a model's quality. It is simply the right shape of a claim about evaluation records.

Live monitoring is not a substitute for a pre-release decision

Monitoring is sometimes described as the answer to uncertainty: release the system, watch the dashboard, improve continuously. There is a useful instinct in that sentence. Systems need observation after release because deployment produces information that a laboratory cannot. But monitoring cannot retroactively support a decision for which the evidence was never adequate. It cannot tell a person affected by a flawed high-consequence action that the organisation will learn from the graph next month.

Pre-release evaluation and post-release monitoring answer different questions. Evaluation asks whether the organisation has enough evidence to permit a defined use now. Monitoring asks whether the conditions behind that permission still hold and whether new risks or failures are emerging. The first establishes a starting boundary. The second watches the boundary in operation. A credible system needs both, as well as a route for data and operational learning to return to risk assessment, documentation and change control.

That loop is what turns a static assurance packet into a living record. An evaluation gives a baseline. A deployment record says which baseline was adopted. Logging and monitoring show relevant behaviour. A change may alter the baseline or reveal its limits. A review then updates the claim, its evidence, its constraints or its status. The system moves. The record moves with it, but does not rewrite its own past. An auditor can see both the current position and the path by which it arrived there.

For high-risk systems, the AI Act is explicit that post-market monitoring should gather and analyse relevant performance data throughout the lifetime and allow continuous compliance to be evaluated. It also requires deployers to monitor operation based on instructions for use, and to inform the provider and relevant authority without undue delay where they have reason to consider that use may present a risk. Those requirements do not remove the need for professional judgement. They give professional judgement records, triggers and routes.

Il existe une tentation organisationnelle de considérer la surveillance comme la responsabilité de l'équipe des opérations et l'évaluation comme celle de l'équipe des modèles. Cette division échouera dès la première question importante concernant une route en production. Le modélisateur peut savoir pourquoi un test a été choisi. L'opérateur peut savoir que les sources étaient obsolètes. Le responsable de la politique peut savoir qu'une règle de décision a changé. Le réviseur peut savoir que l'interface crée un biais d'automatisation. Une piste d'audit devrait relier leurs preuves sans prétendre qu'une seule personne voit l'ensemble du système.

Un régulateur peut-il reproduire une décision ?

Parfois, la réponse devrait être oui, dans un cadre défini. Si une organisation prétend qu'une décision ou une évaluation peut être rejouée, elle doit préciser ce que signifie « rejouer ». Cela signifie-t-il répéter un appel de modèle avec la même invite ? Cela signifie-t-il reconstruire la séquence complète de récupération et d'outils ? Cela signifie-t-il reconstituer l'enregistrement qu'un réviseur a vu ? Cela signifie-t-il valider un calcul déterministe à partir d'entrées préservées ? Chacune de ces options est utile. Chacune a des prérequis techniques et juridiques différents.

Une reproduction significative commence par une identité préservée. Le réviseur doit savoir quelle version du système et quelle configuration étaient en vigueur, quelles entrées et versions de sources étaient admissibles, quelles politiques et autorisations s'appliquaient, quelles dépendances externes ont répondu, et quelles actions humaines ont modifié le parcours. Certains éléments peuvent devoir être stockés directement. D'autres peuvent être référencés par des identifiants stables et reconstruits via des systèmes contrôlés. Ce qui n'est pas acceptable, c'est de qualifier un exercice de rejouable lorsqu'il dépend d'une recherche web en direct, d'une ligne de base de données écrasée et d'un paramètre mémorisé depuis l'ordinateur portable d'un ingénieur.

Même dans ce cas, une reproduction peut reproduire un enregistrement plutôt que répéter le monde. Une source en direct peut être mise à jour ou retirée. Un service tiers peut changer. Un service adaptatif peut accumuler de nouvelles données gouvernées. Un humain peut porter un jugement différent lorsqu'on lui présente les mêmes informations. Ce ne sont pas des défauts dans l'idée de reproduction. Ce sont des distinctions que l'enregistrement doit préserver. La reproduction peut montrer ce que le système a fait dans le cadre du contrat capturé. Elle ne prétend pas que le monde actuel est identique à ce contrat.

C'est pourquoi les enregistrements de décisions humaines doivent être conservés aux côtés des enregistrements techniques lorsque la supervision humaine fait partie de l'argument de sécurité ou de droits. Un audit peut avoir besoin de savoir qu'une personne a examiné une recommandation, quelles informations étaient à sa disposition, ce qu'elle a choisi et quelle autorité elle détenait. Il n'a pas besoin de transformer chaque réviseur en cible de surveillance ni de conserver des données personnelles illimitées. Il a besoin de suffisamment d'informations pour établir si la supervision promise existait dans l'événement en question.

La reproduction est donc une échelle, pas une vantardise. À un échelon, un réviseur peut identifier la version. Au suivant, il peut inspecter les preuves. Plus haut, il peut recréer un test ou analyser un parcours de décision en production. L'organisation devrait indiquer quel échelon elle soutient, où se situent les limites et quelles parties nécessitent un accès autorisé. Une revendication de reproduction modeste et testable est bien plus solide qu'une assurance vague que tout est traçable.

Les audits ont besoin d'enregistrements qui divergent entre eux

Le registre public de statut d'une organisation, son registre interne de versions, son rapport d'évaluation, ses journaux opérationnels et son registre d'incidents ne devraient pas dire des choses différentes sur le même état de base. Mais ils ne devraient pas non plus être des documents identiques. Chacun a un public et un objectif différents. Le registre public peut indiquer l'objectif prévu, le statut, les limitations connues et une voie vers des informations supplémentaires. Le fichier technique peut contenir l'architecture détaillée, les données, les tests et les contrôles. Le registre opérationnel peut contenir une traçabilité au niveau des événements. Le fichier de modifications peut expliquer pourquoi une conclusion antérieure a été réexaminée.

The integrity comes from correspondence. If a public page says a route is limited to recommendation, the technical and operational records should not describe automatic action. If an evaluation says it concerns a captured source set, the release record should not silently apply it to a later one. If a change record says a model update was immaterial, the impact assessment should state the affected claim and evidence. If a monitoring signal raises a review, the subsequent decision should be traceable. The documents may disagree in granularity. They must not disagree about reality.

That correspondence is useful for regulators because it reduces the need to trust one polished artefact. A reviewer can compare records. It is useful for organisations because it exposes drift between teams before an external audit does. And it is useful for affected people because the public explanation can become a real route to accountability rather than a decorative layer placed over a separate private system.

The architecture does not have to be elaborate. A small organisation may use a controlled register, versioned documents, signed exports and disciplined change reviews. A larger organisation may use structured manifests, append-only logs, policy engines and automated evidence capture. The important question is whether the method can reliably connect claim, state, evidence, decision and later change. A gigantic tooling estate that loses this relationship is simply a more expensive way to be vague.

There is a particularly European virtue in making the record inspectable without making it theatrical. Not every answer belongs on a public dashboard. Not every documented uncertainty needs a cheerful icon. But when an organisation has made a consequential claim about an adaptive system, it should be able to show a regulator where that claim lives, what state it referred to, and how the organisation would know that it had become stale.

The audit question changes the design question

Ask early whether a regulator could audit the system as it will actually operate. The answer changes design choices well before a formal audit begins. It favours stable identifiers over ambiguous labels. It favours explicit policy versions over rules embedded in prose. It favours tool contracts that can be recorded and tested. It favours source provenance and freshness markers. It favours a clear boundary between recommendation and action. It favours review screens that preserve the information a reviewer needs. It favours pause and recovery mechanisms with named authority.

It also changes procurement. A supplier's statement that a model is regularly improved is not enough when the deployment depends on a defined evaluated state. The buyer needs to know how changes are notified, what artefacts can be identified, which information is available for impact assessment, whether historical records remain interpretable, and how a route can be limited or paused. These are not exotic demands. They are the practical terms under which an organisation remains responsible for a system that contains a supplier component.

The same question changes evaluation design. A useful suite has an identity and a rationale. Its inputs or references are controlled. Its metrics and thresholds are defined before the result is read. Its exclusions are visible. Its results attach to the system state actually under discussion. Its failures have a route into a decision. Its re-run conditions are clear. An evaluation with these properties can be challenged. That is a feature, not an unfortunate side effect of being thorough.

Par-dessus tout, la question change le rôle du changement. Le changement cesse d'être une gêne que la documentation tente de dissimuler. Il devient un événement de première classe dans le modèle de preuves du système. Certains changements n'exigeront guère plus qu'un enregistrement. D'autres déclencheront un test. D'autres encore rouvriront la décision de mise sur le marché. L'organisation disciplinée ne confond pas ces catégories, et elle n'a pas besoin d'un incident futur pour découvrir qu'elles existaient.

Alors oui : un régulateur peut auditer une cible mouvante. L'audit commence par refuser le faux choix entre une fiche de modèle figée et un service en direct totalement inconnaissable. Capturez l'état. Énoncez la revendication. Préservez les conditions. Reliez les preuves à la décision. Enregistrez ce qui change. Réévaluez lorsque le lien ne tient plus. La cible peut bouger. La trace doit rester lisible.

Sources