Un système à haut risque n'est pas un modèle à haut risque

Le risque ne réside pas dans un modèle comme une étiquette d'avertissement. Il émerge de la finalité prévue, du déploiement, de l'autorité, des interfaces...

Un système à haut risque n'est pas un modèle à haut risque

L'étiquette est attachée à un usage, pas à une boîte

Un modèle peut être copié d'un serveur à un autre sans rien apprendre. Ses poids, son code et ses capacités annoncées peuvent être inchangés. Pourtant, la question que l'Europe pose à propos de ce qui l'entoure peut changer complètement. À quoi sert-il ? Qui l'utilise ? Quelle position peut-il modifier ? Quel dossier entre dans le flux de travail ? Qui peut contester la réponse, la corriger, l'arrêter ou découvrir plus tard pourquoi elle a été suivie ?

Il ne s'agit pas de rendre un sujet simple plus grandiose qu'il ne l'est. C'est la différence ordinaire entre un composant et un système. Un disque de frein n'est pas un véhicule routier. Une formule de tableur n'est pas une décision fiscale. Un modèle d'IA à usage général n'est pas, en soi, chaque système d'IA qui pourra être construit autour de lui plus tard. La distinction est facile à approuver d'un signe de tête et remarquablement facile à perdre dès qu'une réunion d'approvisionnement commence à parler d'un modèle comme s'il contenait déjà tout le déploiement futur.

La loi européenne sur l'intelligence artificielle maintient la distinction en vue. Elle définit un système d'IA et définit séparément un modèle d'IA à usage général. Ses règles relatives aux risques élevés concernent les systèmes d'IA dans des circonstances particulières, y compris les systèmes qui sont des composants de sécurité de produits réglementés et les systèmes utilisés dans des domaines listés. La loi rend également la finalité prévue centrale pour la classification et la documentation d'un système d'IA. Elle n'invite pas une équipe à pointer un nom de modèle, à apposer une étiquette rouge, orange ou verte et à déclarer le travail terminé.

Cela devrait être libérateur autant qu'exigeant. Un modèle ne porte pas d'horoscope moral permanent. Une analyse minutieuse peut être étroite là où la finalité prévue est étroite, et elle peut devenir sérieuse là où l'autorité, l'exposition et les conséquences deviennent sérieuses. Le piège, c'est que l'analyse doit suivre le système réel. Pas la démo. Pas la présentation du fournisseur. Pas la tâche inoffensive qui a ouvert le projet il y a six mois. Le système qui recevra des entrées, rendra des sorties disponibles, façonnera une décision et sera exploité un mardi ordinaire.

Prenons une illustration délibérément hypothétique. Le même modèle de langage est d'abord connecté à un outil interne de recherche de connaissances. Il récupère des passages de politique pour un collègue formé, qui peut ouvrir la source originale et rédiger sa propre réponse. Plus tard, une organisation connecte le modèle à un formulaire de saisie, donne à sa recommandation une place en haut d'un dossier de cas, applique un délai au dossier et fait de l'acceptation de la recommandation le moyen le plus rapide de vider la file d'attente. Aucun conseil, patient, employé ou incident fictif n'est nécessaire pour voir le changement. Le modèle peut être identique. Le rôle de la sortie, le chemin des données, l'incitation, la personne concernée et l'autorité pratique de l'interface ne le sont pas.

C'est l'argument de l'article : un système à haut risque n'est pas un modèle à haut risque. Un modèle peut être une partie importante du système et peut avoir ses propres obligations. Mais l'analyse des risques ne devient significative que lorsqu'elle atteint la finalité prévue, le contexte de déploiement, les utilisateurs, les personnes concernées et l'intégration en aval. Ces détails ne sont pas de la paperasse ajoutée après l'ingénierie. Ce sont les circonstances qui donnent à une sortie une force institutionnelle.

Survolez ou sélectionnez une couche. Le modèle n'est qu'une couche ; la conséquence n'apparaît que lorsque les couches se rencontrent.

L'Europe utilise délibérément deux noms différents

La distinction commence dans les définitions du règlement. Un système d'IA est un système fondé sur une machine, conçu pour fonctionner avec différents niveaux d'autonomie et pouvant faire preuve d'adaptabilité après son déploiement, qui déduit, à partir des entrées, comment générer des sorties telles que des prédictions, du contenu, des recommandations ou des décisions pouvant influencer des environnements physiques ou virtuels. Un modèle d'IA à usage général est différent : c'est un modèle d'IA capable d'exécuter avec compétence un large éventail de tâches distinctes, qu'il soit ou non mis sur le marché, et pouvant être intégré dans une variété de systèmes ou d'applications en aval.

Ces définitions se chevauchent dans la conversation courante parce que le même mot, IA, fait une grande partie du travail non rémunéré. Elles ne devraient pas se chevaucher dans une évaluation. Un modèle à usage général est fait pour voyager. Ses usages possibles sont délibérément larges. Un système d'IA est l'arrangement opérationnel par lequel les sorties influencent un environnement. Il a un but, une configuration, une interface et un cadre. Il peut inclure un modèle, plusieurs modèles, des règles déterministes, des bases de données, des capteurs, des personnes, des procédures et un grand nombre de petites décisions que personne n'appelle intelligence artificielle jusqu'à ce qu'elles échouent.

C'est pourquoi un fournisseur de modèle d'IA à usage général et un fournisseur ou un déployeur de système d'IA ne peuvent pas simplement échanger leurs listes de contrôle. Les orientations de la Commission sur les modèles d'IA à usage général indiquent que les fournisseurs de modèles doivent mettre des informations et de la documentation à la disposition des fournisseurs de systèmes d'IA en aval, afin que ces fournisseurs puissent comprendre les capacités et les limites du modèle et satisfaire à leurs propres obligations. Cette phrase est plus intéressante qu'il n'y paraît. Elle suppose que le fournisseur en aval a un travail qui ne peut pas être accompli par le fournisseur du modèle. La documentation du modèle voyage, mais elle ne termine pas le voyage.

Il y a une humilité pratique dans tout cela. Un fournisseur de modèle peut décrire l'architecture, le processus d'entraînement, l'évaluation, les tâches prévues, les exigences d'intégration, les entrées et sorties, les limites et les conditions connues. Une équipe en aval sait si un utilisateur est un spécialiste formé, si une personne affectée peut contester un résultat, si une recommandation est consultative de nom mais contraignante en pratique, si un appel à un service externe modifie un enregistrement, et si une action défectueuse peut être inversée. Aucune des deux parties n'a une image complète à elle seule.

La division n'est pas une échappatoire. C'est une carte de responsabilité. Elle dit qu'un système ne peut pas être gouverné en demandant au fournisseur du modèle de promettre un contrôle sur un déploiement qu'il n'exploite ni ne voit. Elle dit aussi qu'un intégrateur ne peut pas plaider l'ignorance là où la documentation rend une limitation importante visible. Le but n'est pas de faire un transfert propre entre entités juridiques. C'est d'éviter de perdre la question dans l'écart entre elles.

Il existe une seconde distinction à conserver à côté de la première. Une classification à haut risque ne vaut pas en elle-même autorisation, sécurité, équité ou légalité. Dans leur avis conjoint sur la proposition initiale de la Commission, le Comité européen de la protection des données et le Contrôleur européen de la protection des données ont souligné que la classification comme à haut risque ne signifiait pas nécessairement qu'un système était licite en soi ni qu'il pouvait être déployé tel quel par son utilisateur. L'acte final a modifié le paysage juridique depuis cet avis, mais l'avertissement de fond reste utile. La classification est une condition réglementaire. Ce n'est pas un reçu attestant que l'institution peut cesser de réfléchir.

Cela importe parce qu'une étiquette de haut risque peut produire deux erreurs opposées. Une équipe peut la traiter comme une tache permanente sur un modèle et décider que la réponse consiste simplement à ne pas regarder plus loin. Une autre peut considérer une procédure de conformité achevée comme un laissez-passer pour tout contexte ultérieur. Les deux approches substituent une étiquette à un raisonnement. L'Europe a choisi une approche plus exigeante : identifier le système, sa finalité et son rôle, puis examiner les risques et obligations pertinents tout au long de son cycle de vie.

La finalité prévue est ce qui donne son cap à l'analyse

La finalité prévue semble modeste, presque administrative. Elle ne l'est pas. L'acte la définit comme l'utilisation pour laquelle un système d'IA est destiné par son fournisseur, y compris le contexte et les conditions d'utilisation précisés dans les informations fournies par le fournisseur. En d'autres termes, la finalité n'est pas un slogan sur une page produit. Elle inclut le contexte et les conditions dans lesquels le fournisseur indique que le système doit être utilisé. Une déclaration de finalité utile a des contours nets. Elle dit ce que fait le système, pour qui, avec quelles entrées, dans quel flux de travail, et où s'arrête son autorité.

Comparons deux descriptions. La première dit qu'un système utilise l'IA pour aider les organisations à prendre de meilleures décisions. Elle est assez large pour figurer sur un fond de conférence et trop large pour être opérationnelle. La seconde dit qu'un système présente aux examinateurs formés des projets de synthèse sourcés d'un dossier existant ; il ne peut pas prendre, transmettre ni exécuter une décision ; l'examinateur doit vérifier les sources citées avant d'utiliser une synthèse ; et la fonction est indisponible pour les catégories nécessitant une procédure légale distincte. La seconde description est moins enthousiasmante. C'est aussi une description avec laquelle un ingénieur, un responsable des achats, un collègue de la conformité et une personne concernée peuvent être en désaccord de manière concrète.

La finalité ne doit pas tenir en une seule phrase. Dans un système sérieux, elle constitue généralement un ensemble compact : tâche, résultat, utilisateur, population concernée, contexte, autorité, exclusions, dépendances et conditions. Les exigences de documentation technique de l'acte laissent précisément la place à ce type de compte rendu. L'annexe IV demande une description générale du système d'IA, y compris la finalité prévue, les personnes et groupes sur lesquels il est destiné à être utilisé, et les versions ou formes spécifiques sous lesquelles il est mis sur le marché. Elle demande aussi des descriptions de l'architecture du système, des exigences en matière de données, des mesures de surveillance humaine, du suivi du cycle de vie et des mesures de gestion des risques. La documentation a cette ampleur parce qu'une simple fiche de modèle ne peut pas décrire un déploiement.

La finalité est aussi le moment où une équipe découvre qu'elle décrivait une ambition plutôt qu'une opération. « Nous aiderons les gestionnaires de dossiers » peut dissimuler une douzaine d'arrangements différents. L'outil recherche-t-il des documents, ordonne-t-il le travail, rédige-t-il une réponse, recommande-t-il une catégorie, rejette-t-il une demande, remonte-t-il une alerte, fixe-t-il une priorité ou appelle-t-il un autre service ? Le collègue l'utilise-t-il avant ou après avoir formé un avis indépendant ? Le résultat est-il une suggestion dans un panneau latéral ou un champ qui doit être validé avant que le dossier puisse progresser ? L'effet est-il immédiat, différé, réversible ou difficile à repérer ? La réponse change le système, même lorsque l'interface utilisateur semble familière.

L'intention déclarée d'un fournisseur ne peut pas faire disparaître la réalité. Une équipe ne peut pas conférer à un système une large autorité pratique, le décrire comme un assistant inoffensif et s'attendre à ce que cette description règle la question. Mais une finalité correctement délimitée reste un moyen de contrôle. Elle indique aux utilisateurs quels éléments de preuve ont été pris en compte, indique aux intégrateurs ce qu'ils ne doivent pas étendre à la légère, et indique aux évaluateurs quel changement nécessiterait de rouvrir l'évaluation. Une finalité vague transforme chaque question ultérieure en débat sur ce qui était voulu. Une finalité délimitée permet à une organisation de se demander si elle fait encore ce qu'elle a approuvé.

Cela devient particulièrement important lorsqu'une organisation apporte une modification substantielle. Le règlement contient des règles concernant les cas où un distributeur, un importateur, un déployeur ou un autre tiers peut devenir fournisseur, notamment lorsqu'il met un système sur le marché sous son propre nom, apporte une modification substantielle ou modifie la finalité prévue d'une manière qui rend le système à haut risque. L'application juridique exacte dépend des faits et doit être vérifiée dans son contexte. La leçon opérationnelle est plus simple : un changement d'intégration peut constituer un événement de gouvernance. Déplacer la sortie d'un modèle d'un volet de brouillon vers une file de décision peut être à la fois un changement de produit, un changement de flux de travail et un changement de responsabilité.

Le contexte n'est pas un décor

Le contexte de déploiement est souvent traité comme l'élément qui arrive après le vrai travail : une liste de pays, un choix d'hébergement, quelques profils d'utilisateurs, peut-être un diagramme avec des flèches menant docilement de gauche à droite. Mais le contexte donne sa forme au risque. Le même type de sortie peut être gênant dans un cadre et lourd de conséquences dans un autre. Une complétion erronée dans un outil d'aide à l'écriture peut être corrigée dans la phrase suivante. Une priorité erronée dans un flux de travail de service rare peut décider quel fichier une personne voit en premier. Un score qui semble n'être qu'une entrée parmi d'autres peut devenir décisif si toutes les autres entrées sont lentes, vagues ou cachées derrière une autre équipe.

L'approche du règlement concernant les systèmes à haut risque reflète cela. L'article 6 relie la classification à haut risque aux systèmes destinés à être utilisés comme composants de sécurité de certains produits, ou aux systèmes visés à l'annexe III. L'annexe III énumère les domaines où les systèmes d'IA peuvent être à haut risque parce qu'ils sont destinés à des usages spécifiques, comme certains usages biométriques, les infrastructures critiques, l'éducation et la formation professionnelle, l'emploi, l'accès aux services et prestations essentiels privés et publics, les forces de l'ordre, la migration et le contrôle aux frontières, ainsi que l'administration de la justice et les processus démocratiques. Le détail juridique compte, mais la grammaire aussi. Il ne s'agit pas de dire qu'un artefact technique est à haut risque dans l'abstrait. Le texte répète à plusieurs reprises « destiné à être utilisé ».

L'article 6 contient également une réserve pour certains systèmes de l'annexe III : ils ne sont pas considérés comme à haut risque lorsqu'ils ne présentent pas de risque significatif d'atteinte à la santé, à la sécurité ou aux droits fondamentaux des personnes physiques, notamment en n'influençant pas matériellement l'issue d'une prise de décision. Les fournisseurs doivent documenter cette évaluation avant de mettre le système sur le marché ou de le mettre en service. Ce n'est pas une carte d'exemption générale. C'est un rappel que l'effet réel du système compte. Une analyse utile contient suffisamment de détails pour expliquer pourquoi un système influence, ou n'influence pas, matériellement une issue. Si cette explication ne peut pas être rédigée sans approximations vagues, l'équipe a appris quelque chose avant la mise en production.

Le contexte inclut le temps. Une recommandation formulée au début d’une enquête approfondie a un effet différent d’une recommandation émise au moment où une personne n’a qu’une seule occasion de fournir des éléments manquants. Il inclut le volume. Un examinateur individuel peut contester un résultat lorsque cinq dossiers arrivent chaque jour, et l’accepter par défaut lorsque cinq cents arrivent avant le déjeuner. Il inclut la langue. Un examinateur qui peut lire les preuves dans sa propre langue de travail peut exercer un type de contrôle différent de celui d’un examinateur qui reçoit un résumé affirmatif de documents qu’il ne peut pas vérifier de manière indépendante. Il inclut la procédure locale, les droits de recours, le personnel, l’accès à un spécialiste, la disponibilité d’une solution de repli, et la question de savoir si un résultat parvient à une personne disposant de l’autorité suffisante pour agir utilement.

Aucun de ces éléments ne nécessite un scénario catastrophe inventé pour être vrai. C’est simplement ainsi que fonctionnent les systèmes. Une politique formelle peut mentionner la présence d’un humain dans la boucle, mais le système peut néanmoins être fonctionnellement automatique si la personne n’a ni le temps, ni l’information, ni l’autorité, ni la voie pratique pour exprimer un désaccord. L’article 14 de la loi parle donc d’une supervision humaine effective, adaptée aux risques, au niveau d’autonomie et au contexte d’utilisation. Il exige que les systèmes à haut risque soient conçus et développés afin que les personnes puissent comprendre les capacités et les limites pertinentes, rester conscientes d’une tendance à se fier automatiquement aux résultats, interpréter correctement ces résultats, décider de ne pas les utiliser, les remplacer ou les annuler, et arrêter le système en toute sécurité lorsque cela est approprié. Ce sont des questions opérationnelles. Elles ne peuvent pas être résolues par un simple benchmark de modèle.

Sélectionnez une posture de déploiement. Le modèle reste en place ; la frontière du système, l’autorité et les preuves requises, elles, changent.

Les utilisateurs font partie de la surface de contrôle

Il est tentant de parler des utilisateurs comme s’ils se trouvaient à l’extérieur du système, un clavier à la main, chargés de la partie humaine. Ils font partie du dispositif de fonctionnement. Leurs connaissances, leur charge de travail, leur autorité, leurs incitations et les voies d’aide dont ils disposent déterminent l’effet du résultat. Un système conçu pour un spécialiste capable d’examiner les documents sources n’est pas automatiquement adapté à un généraliste censé travailler rapidement. Un outil utile pour un examinateur pouvant rejeter une recommandation n’est pas automatiquement adapté à un collègue qui ne peut que cliquer sur « approuver » ou attendre que quelqu’un d’autre le fasse.

Cela ne signifie pas que l'utilisateur doive remettre en question chaque composant à chaque fois. Ce serait une définition étrange de la technologie utile. Cela signifie que la supervision doit être conçue comme une véritable tâche. La personne doit savoir quand le système est utilisé, quelle est la limitation pertinente, quelles preuves sont disponibles, quel type de désaccord elle peut enregistrer, et ce qui se passe après l'enregistrement. Elle doit disposer d'une autorité à la hauteur de sa responsabilité. Demander à quelqu'un de superviser une sortie qu'il ne peut ni interrompre, ni corriger, ni orienter relève moins de la supervision humaine que de la décoration humaine.

Le règlement confère ici un rôle aux déployeurs. L'article 26 exige que les déployeurs de systèmes à haut risque prennent des mesures techniques et organisationnelles appropriées pour garantir qu'ils utilisent les systèmes conformément aux instructions qui les accompagnent. Il leur demande d'attribuer la supervision humaine à des personnes physiques disposant des compétences, de la formation et de l'autorité nécessaires, et de surveiller le fonctionnement sur la base des instructions. Dans certains cas, il exige également de conserver sous leur contrôle les journaux générés automatiquement. Il ne s'agit pas de demander qu'une personne compétente reste à proximité au cas où l'interface deviendrait nerveuse. Il s'agit d'exiger l'organisation d'une pratique de travail.

La formation est souvent présentée comme la réponse complète. Elle ne l'est pas. La formation peut aider une personne à reconnaître une limitation, mais elle ne peut pas créer un enregistrement source que l'interface dissimule. Elle ne peut pas créer le temps qu'une conception de file d'attente consomme. Elle ne peut pas créer l'autorité qu'un contrat réserve ailleurs. Elle ne peut pas réparer une intégration qui transforme une recommandation prudente en action irréversible. Une organisation devrait former ses collaborateurs, bien sûr. Elle devrait aussi rendre possible, dans le système réellement fourni, la tâche pour laquelle ils sont formés.

Il existe un test utile : décrire l'action de l'utilisateur sans utiliser le verbe examiner. Que lit-il ? Quelle comparaison peut-il faire ? Que peut-il refuser ? Où va la justification ? Qui la voit ? Qu'advient-il de la recommandation après le rejet ? La personne concernée par le résultat peut-elle demander ce qui s'est passé ? Un collègue ultérieur peut-il reconstituer l'état pertinent ? Si les réponses restent générales, la conception de la supervision est probablement générale aussi.

Ce test s'applique au-delà des systèmes à haut risque. La loi a un champ d'application et des dates précis ; un bon jugement opérationnel n'attend pas une étiquette de catégorie pour se demander si une personne a été placée dans un rôle de pure représentation. Il est tout à fait possible de construire un outil à faible enjeu qui rend les gens plus stupides à propos de leur propre travail parce que la sortie est trop lisse pour être contestée. Il est également possible de construire un outil contraint qui accroît la capacité d'une personne à poser de bonnes questions parce qu'il préserve les preuves, limite son autorité et rend l'incertitude visible. Le modèle peut contribuer à l'un ou l'autre résultat. C'est le système qui décide quel résultat a un lieu où se produire.

Les personnes concernées se trouvent hors de la console

Nombre des personnes les plus importantes d'un système d'IA n'y touchent jamais. Elles peuvent être candidates, élèves, travailleurs, patients, passagers, résidents, clients, demandeurs, emprunteurs, témoins ou membres du public. Elles peuvent ignorer qu'un modèle était impliqué. Elles peuvent seulement faire l'expérience d'une réponse qui arrive rapidement, d'une demande qui est retardée, d'un service qui devient indisponible, d'une priorité qui change, ou d'une décision qui semble impossible à comprendre. Leur absence de l'interface ne les rend pas absents du système.

C'est l'une des raisons pour lesquelles le cadre de risque du règlement se réfère à la santé, à la sécurité et aux droits fondamentaux. Il attire l'attention sur des conséquences qui ne peuvent être réduites à la question de savoir si un collègue connecté a apprécié l'outil. C'est aussi pourquoi une déclaration d'objectif devrait nommer les personnes et les groupes sur lesquels le système est destiné à être utilisé, comme l'exige l'annexe IV. Un système construit autour d'une catégorie appelée utilisateur peut dissimuler silencieusement une différence entre la personne qui opère l'interface et la personne qui vit avec le résultat.

Les personnes concernées changent les questions qu'une équipe doit se poser. Existe-t-il un moyen de savoir que le système a joué un rôle significatif ? La décision repose-t-elle sur des informations qui peuvent être corrigées ? Une langue, un handicap, un appareil, un lieu ou un statut administratif rendent-ils la participation plus difficile ? L'équipe en charge reçoit-elle des signaux des personnes concernées, ou seulement du tableau de bord ? Une correction atteint-elle les données, la recommandation, la décision et toute copie en aval qui s'y appuyait ? Ces questions ne demandent pas de transformer chaque système en consultation publique. Elles demandent de suivre la conséquence assez loin pour voir la personne à l'autre bout.

Le droit de la protection des données s'applique lorsque des données personnelles sont traitées, en complément du cadre de l'AI Act. Le CEPD et le Contrôleur européen de la protection des données l'ont clairement indiqué dans leur avis conjoint de 2021 sur la proposition : le droit existant de l'Union en matière de protection des données s'applique au traitement de données personnelles relevant du champ de la proposition. L'analyse juridique exacte dépendra du traitement et des acteurs concernés. La leçon en matière de gouvernance est simple. Un exercice de classification ne peut pas absorber toutes les autres obligations. La vie privée, la non-discrimination, les obligations sectorielles, les exigences du droit administratif, les règles de consommation et les engagements contractuels ne disparaissent pas parce qu'une équipe a constitué un registre des risques présentable.

Il y a aussi une question fondamentale de lisibilité. Une personne n'a pas besoin de devenir spécialiste de l'apprentissage automatique pour comprendre comment demander une correction. Mais un système ne doit pas utiliser la complexité technique comme prétexte pour rendre la correction impossible. Un bon parcours distingue ce que le système a enregistré, ce qu'un humain a décidé, quels éléments de preuve ont été examinés, ce qui reste incertain et ce qui peut encore être modifié. Il ne revendique pas une précision que les enregistrements ne peuvent pas étayer. Dans ce domaine, l'honnêteté n'est pas seulement une question de ton. Elle fait partie du service.

L'intégration est le moment où les responsabilités changent de main

Les équipes représentent parfois une architecture d'IA comme une chaîne ordonnée : modèle, invite, réponse, utilisateur. Les déploiements réels ressemblent davantage à un plan municipal après que quelqu'un a rappelé les canalisations de service. Il y a des systèmes d'identité, des magasins de récupération, des autorisations d'outils, des files d'attente, des schémas, des caches, des plateformes d'observabilité, des extensions de navigateur, des tâches par lots, des règles d'approbation, des paramètres de conservation, des fournisseurs et des personnes qui héritent d'une tâche parce que la personne précédente est partie en vacances. Le modèle est important. Il est rarement seul.

Chaque intégration peut modifier ce que le système est capable de faire et la manière dont une erreur se propage. La récupération peut donner l'impression qu'une sortie du modèle est fondée alors que la source est obsolète, incomplète ou mal cadrée. Un appel d'outil peut transformer un brouillon en changement d'état. Une file d'attente peut transformer une recommandation opportune en recommandation tardive. Une couche d'orchestration peut sélectionner un modèle ou une version d'invite différente. Une interface utilisateur peut masquer une incertitude qui existe dans une couche inférieure. Une intégration d'identité peut donner à un outil utile l'accès à des éléments qu'un utilisateur ne pourrait pas ouvrir autrement. Aucune de ces observations n'accuse un produit ou une organisation en particulier. Elles décrivent des propriétés système ordinaires, ce qui explique précisément pourquoi elles devraient être documentées avant de devenir surprenantes.

Les orientations de la Commission sur l'IA à usage général sont utiles ici car elles placent l'information au point de transfert. La documentation destinée aux fournisseurs en aval vise à les aider à comprendre les capacités et les limites du modèle, ses tâches prévues, les exigences d'intégration technique, les spécifications d'entrée et de sortie, et les informations sur les données d'entraînement. Ces informations sont nécessaires. Elles ne suffisent pas. Les équipes en aval doivent encore décider comment le modèle est invité, si une sortie est affichée avec des preuves, quelles autorisations d'outils sont autorisées, comment un changement est testé, quels journaux sont conservés et si une recommandation peut influencer un flux de travail particulier.

Voilà pourquoi l'achat d'un service de modèle n'est pas l'achat d'une posture de risque complète. La documentation du fournisseur peut indiquer à une équipe qu'un modèle présente une limitation connue ou qu'il a été évalué dans certaines conditions. Elle ne peut pas prouver que l'index de récupération de l'acheteur est à jour, que le personnel de l'acheteur dispose des autorisations nécessaires, ou qu'une personne concernée a accès à une voie de recours. À l'inverse, l'acheteur ne peut pas exiger qu'un fournisseur de modèles connaisse chaque politique locale ou processus en aval. La chose responsable n'est pas de prétendre qu'un seul côté peut connaître l'ensemble du système. C'est de rendre la frontière explicite et de faire circuler les preuves à travers elle.

L'article 25 fournit un repère juridique utile pour cette réalité opérationnelle. Il énonce les circonstances dans lesquelles une partie autre que le fournisseur d'origine est considérée comme un fournisseur d'un système d'IA à haut risque. Il s'agit notamment de la mise sur le marché du système sous le nom ou la marque de cette partie, de la réalisation d'une modification substantielle, ou de la modification de la finalité prévue d'une manière qui rend le système à haut risque. La disposition est technique et dépend des faits ; personne ne devrait s'auto-classifier à partir d'un article de blog. Mais son orientation est claire. L'intégration et le changement de finalité peuvent modifier qui porte les obligations du fournisseur. Un arrangement en aval n'est pas définitivement en aval simplement parce que le modèle d'origine venait d'ailleurs.

Il existe une raison institutionnelle de prendre cela au sérieux. Lorsque la responsabilité change silencieusement, la sécurité et les recours deviennent un jeu de ping-pong organisationnel. Le fournisseur du modèle pointe vers le déploiement. Le déployeur pointe vers le modèle. L'intégrateur pointe vers le service cloud. Le propriétaire du service pointe vers une configuration qui n'existe plus. Les personnes concernées reçoivent une explication soignée de la complexité de tout cela. Cela peut être exact, mais ce n'est pas une réponse. Le système a besoin d'un enregistrement indiquant quelle organisation détient la question à chaque frontière, et d'un chemin pour que la question circule lorsque la réponse se trouve ailleurs.

La documentation doit décrire un système qui peut encore évoluer

La documentation technique a la réputation d'arriver à la fin d'un projet avec une légère odeur de panique. Le règlement décrit un rôle différent. Pour les systèmes à haut risque, la documentation technique doit être établie avant la mise sur le marché ou la mise en service du système et tenue à jour. La liste de l'annexe IV va au-delà du comportement du modèle pour couvrir la finalité prévue, les versions, l'architecture du système, le développement, les exigences en matière de données, la validation et les tests, la surveillance humaine, les mesures de précision et de cybersécurité, la gestion des risques, les modifications et la surveillance après la mise sur le marché. Ce n'est pas une annexe décorative. C'est une tentative de préserver suffisamment de mémoire pour que quelqu'un puisse inspecter le système après que la réunion de lancement soit devenue un lointain souvenir.

La documentation ne fonctionne que lorsqu'elle peut montrer des relations. Une version de modèle doit être reliée à la version du système qui l'a utilisée. Un test doit être relié à ses conditions d'entrée et à sa finalité. Une politique doit être reliée à un point d'application. Un rôle d'utilisateur doit être relié à l'autorité qu'il possède dans l'interface. Une politique de journalisation doit être reliée à l'événement qu'elle peut reconstituer. Une modification doit être reliée à l'évaluation qu'elle a déclenchée. Sinon, une équipe dispose d'une bibliothèque de bons documents mais d'aucun moyen de répondre à une question particulière.

Les journaux sont un cas similaire. L'article 12 exige que les systèmes d'IA à haut risque disposent de capacités techniques d'enregistrement automatique des événements tout au long de la durée de vie du système, proportionnées à la finalité prévue. Les journaux peuvent faciliter la traçabilité, la surveillance après mise sur le marché et la surveillance opérationnelle. Ils n'expliquent pas une décision par magie. Un journal peut indiquer à un enquêteur ultérieur qu'un outil a été appelé, qu'une version était active ou qu'un examinateur a cliqué sur une commande. Il ne peut pas, à lui seul, établir si l'examinateur a compris les éléments de preuve, si la source d'entrée faisait autorité ou si un processus était équitable. Les enregistrements ont de la valeur parce qu'ils donnent à une enquête un point de départ honnête, et non parce qu'ils suppriment le besoin de jugement.

La surveillance après mise sur le marché complète le tableau. L'article 72 exige que les fournisseurs de systèmes à haut risque établissent et documentent un système de surveillance après mise sur le marché d'une manière proportionnée à la nature des technologies et aux risques du système d'IA à haut risque. Cela a une implication simple pour les équipes de déploiement : une version n'est pas le moment où le système devient pleinement connu. L'organisation a besoin d'un moyen de recevoir des informations pertinentes, de distinguer un signal d'une conclusion, de décider si la limite de la finalité prévue tient toujours, et de procéder à une modification ou d'interrompre une utilisation lorsque les éléments de preuve l'exigent.

Ce travail n'est pas prestigieux. Il ressemble à des identifiants de version, à des critères de publication clairs, à un enregistrement des dépendances, à un test pour une voie de retour en arrière, à un propriétaire désigné pour une limitation, et à une décision qui reste visible après que la personne qui l'a prise a changé de fonction. Il ressemble au fait de se demander si une intégration a changé avant de se demander si le modèle a changé. Il ressemble au fait de conserver suffisamment d'éléments de preuve pour corriger une conséquence plutôt que de simplement l'expliquer après coup. Ici, le caractère ennuyeux n'est pas l'opposé de l'ambition. C'est ce qui permet à l'ambition de s'inscrire dans une institution.

Comment raisonner sur l'ensemble du système sans prétendre à la certitude

Une analyse complète n'est pas une quête d'un score de risque universel. C'est une séquence de questions qui devient plus précise à mesure qu'une conception devient plus précise. La première question est la finalité : qu'est-ce que ce système est censé faire, et qu'est-ce qu'il n'est spécifiquement pas censé faire ? La deuxième est la conséquence : qui peut être affecté, comment, et par quelle décision ou quel service ? La troisième est l'autorité : quelle sortie peut modifier un état, influencer une décision, définir une priorité ou changer ce qu'une personne reçoit ? La quatrième est la preuve : qu'est-ce qui étaye l'utilisation du système dans ce contexte, et quelles conditions permettent à ces éléments de preuve de voyager ?

Viennent ensuite les questions inconfortables. Que se passe-t-il lorsque le modèle est incertain, erroné, indisponible ou utilisé en dehors de sa limite déclarée ? Qu'est-ce qui change lorsqu'une source est obsolète ou qu'un outil est refusé ? Et si un utilisateur est pressé, nouveau dans le rôle ou incapable d'inspecter le matériel sous-jacent ? Et si une personne concernée demande une correction ? Et si une mise à jour modifie une invite, un corpus de récupération, une valeur par défaut de l'interface, une version du modèle ou une permission de rôle ? La réponse est parfois un contrôle technique, parfois une procédure, parfois une utilisation plus restreinte, parfois un propriétaire différent, et parfois une décision de ne pas déployer. Une gouvernance qui ne permet jamais cette dernière réponse n'est qu'une approbation dans une veste plus jolie.

Il est utile de maintenir plusieurs affirmations séparées. Un fait confirmé indique ce que le fournisseur du modèle a documenté ou ce que l'organisation a observé dans un test défini. Une inférence explique pourquoi ce fait peut avoir de l'importance dans un flux de travail particulier. Un contrôle proposé indique ce que l'équipe a l'intention de mettre en œuvre. Un risque résiduel indique ce qui reste après le contrôle. Une conclusion juridique indique ce qui s'applique en vertu de la loi. Ces éléments ne sont pas interchangeables. Un bon document les étiquette parce que le lecteur peut avoir besoin d'en contester un sans rejeter les autres.

Par exemple, il est possible de dire : la documentation du fournisseur indique que le modèle présente une certaine limitation ; l'équipe de déploiement en déduit que la limitation pourrait affecter un usage précis ; l'équipe propose un contrôle de vérification de la source ; ce contrôle n'a pas encore été testé sous la charge de travail prévue ; et le conseiller juridique doit évaluer l'usage qui en résulte au regard du droit applicable. Cette phrase est moins satisfaisante qu'une coche verte. Elle est plus utile qu'une coche verte car elle ne laisse aucun doute sur ce qui est établi et ce qui ne l'est pas.

Les équipes doivent être particulièrement attentives au mot humain. Un rôle humain peut constituer un contrôle, mais uniquement lorsqu'il comporte une tâche définie, des informations adéquates, du temps, une formation, une autorité et une voie d'action. Un rôle humain peut aussi devenir un moyen de transférer la responsabilité à la personne la plus proche de l'écran. La distinction n'est pas philosophique. Elle est visible dans le flux de travail. Si un relecteur ne peut qu'approuver, si le désaccord disparaît dans un champ de commentaires non surveillé, ou si personne ne peut corriger la conséquence en aval, le système n'a pas acquis une supervision significative du simple fait qu'une personne a cliqué sur quelque chose.

La même prudence s'applique à la transparence. Un long document peut rendre un système descriptible sans le rendre contestable. Un tableau de bord peut le rendre visible sans le rendre compréhensible. Une divulgation peut indiquer à un utilisateur que l'IA est impliquée sans lui dire ce qu'il peut faire en cas d'erreur. La question utile est pratique : la personne concernée peut-elle trouver la limite, les preuves, le rôle responsable et la voie de correction au moment où ces éléments comptent ? Si ce n'est pas le cas, l'information se trouve au mauvais endroit pour que la gouvernance puisse s'exercer.

Une petite note de notre part

Chez Dweve, notre Centre de confiance public traite la fiche du modèle et l'intégration en aval comme des enregistrements liés mais distincts. Sa page en aval indique que les équipes qui intègrent ou déploient Loom ont besoin des capacités actuelles, des limites, des interfaces, du contexte d'évaluation et des changements, tandis que la fiche publique précise qu'un modèle est un fil dans une trame plus large de composants et de limites opérationnelles. Il s'agit d'une posture documentaire, et non d'une affirmation selon laquelle une page publique classifie chaque déploiement possible ou prouve la conformité pour un intégrateur. L'objectif de la séparation est plus modeste : une fiche de modèle doit accompagner l'intégration sans prétendre remplacer l'analyse du système propre à l'intégrateur.

C'est la norme à conserver. Un fournisseur de modèles doit rendre disponibles des informations utiles. Une organisation qui déploie ou intègre le modèle doit décrire le système réel qu'elle a construit : objectif, personnes, données, interfaces, autorité, surveillance et correction. Aucune des deux parties ne devrait utiliser la documentation comme un échange cérémoniel dans lequel l'une reçoit un PDF et l'autre reçoit l'absolution.

La question la plus difficile est généralement la meilleure

Lorsqu'une équipe se demande si un modèle présente un risque élevé, elle cherche peut-être une réponse rapide à une préoccupation légitime. Mais la question la plus utile est généralement plus longue : quel système construisons-nous à partir de ce modèle, pour quel objectif, dans quel contexte, avec quelles personnes, et que se passe-t-il lorsqu'il se trompe ? Cette question ne peut pas toujours être répondue en une seule réunion. Elle peut révéler que l'usage proposé est plus restreint que prévu, que les preuves sont incomplètes, qu'un rôle d'utilisateur manque d'autorité, qu'un contrat laisse une limite importante sans propriétaire, ou qu'une intégration en aval est discrètement devenue le centre du système.

Aucune de ces constatations n'est un échec de l'innovation. Ce sont les choses qu'une institution apprend avant de donner à un système le pouvoir de façonner les options d'une autre personne. L'approche européenne est souvent décrite comme un ensemble d'obligations. C'est aussi une discipline de dénomination : nommer le but, l'acteur, le contexte, la version, la personne concernée, la limitation, les preuves et la voie d'intervention. Une fois nommées, ces choses peuvent être testées, modifiées et contestées. Avant d'être nommées, elles ont tendance à réapparaître plus tard comme une surprise.

Un modèle peut être capable, soigneusement documenté et précieux. Il peut aussi être placé dans un système qui lui demande trop, cache trop de choses à ses utilisateurs ou laisse trop peu de place à une personne affectée par le résultat. La différence se fait en dehors des poids. C'est là que se trouve le travail difficile, et c'est aussi là que se trouve la véritable opportunité : construire des systèmes dont l'autorité correspond à leurs preuves, dont les limites survivent à l'intégration, et dont les opérateurs peuvent encore dire non.

Sources