Un petit modèle peut porter une grande obligation.

La taille du modèle est une propriété technique. L’obligation découle de la finalité, du contexte, des données, de l’autorité et des personnes entourant le...

Un petit modèle peut porter une grande obligation.

La loi ne demande pas quelle est sa taille

Ouvrez la loi européenne sur l'intelligence artificielle et vous ne tomberez pas sur un compteur de modèles. Il n'y a pas de première page sur laquelle une machine est pesée, mesurée et rangée dans un tiroir juridique bien net. La loi commence par un système : un système fondé sur une machine qui fonctionne avec différents niveaux d'autonomie, peut s'adapter après son déploiement et déduit des données d'entrée comment générer des prédictions, du contenu, des recommandations ou des décisions susceptibles d'influencer un environnement physique ou virtuel. Sa définition porte sur ce que fait le système et sur ce que ses résultats peuvent changer.

C'est un point de départ utile, car le débat technologique ne cesse de vouloir faire de la taille un substitut au contexte. Un modèle plus petit semble modeste. Il peut tenir sur du matériel ordinaire, répondre à une question étroite ou renvoyer une étiquette au lieu d'un paragraphe. Ce sont là des propriétés d'ingénierie précieuses. Elles peuvent réduire la surface à tester, diminuer l'appétit d'un déploiement en ressources ou rendre un composant plus facile à remplacer. Aucune d'elles ne nous dit si une personne peut perdre un droit, un service, un emploi ou un itinéraire sûr à cause de l'étiquette.

L'obligation apparaît dans la relation entre un système et le monde qui l'entoure. Qui utilise le résultat. Quelle décision s'ensuit. Quelles données entrent dans le parcours. Quelle autorité le système détient-il. Une personne peut-elle contester le résultat. Quelqu'un peut-il l'annuler avant que le préjudice ne devienne durable. La personne concernée dépend-elle du résultat, peut-être parce qu'il n'existe pas d'alternative pratique. Un modèle peut être techniquement petit et institutionnellement grand. C'est l'argument de cet article, et le mot institutionnellement fait tout le travail.

Il ne s'agit pas de traiter chaque classifieur comme une urgence publique. Il s'agit de proportionnalité. La proportionnalité ne signifie pas que les petits systèmes reçoivent un sourire de courtoisie et aucune question. Elle signifie que les questions suivent la conséquence réelle. Un modèle utilisé pour trier une collection privée de notes et un modèle utilisé pour décider qui fera l'objet d'un contrôle peuvent se ressembler dans un référentiel. Ils ne se ressemblent pas dans le monde réel.

La taille du modèle décrit un composant. La finalité, les personnes concernées et le contrôle déterminent l'obligation que porte ce composant.

Petit est une mesure, pas un contexte

« Petit » peut recouvrir plusieurs réalités bien distinctes, et ces sens sont souvent échangés sans qu’on s’en aperçoive. Cela peut vouloir dire moins de paramètres, une empreinte mémoire plus réduite, moins de puissance de calcul pour l’entraînement, un vocabulaire restreint, un schéma de sortie étroit, ou une fenêtre d’entrée courte. Cela peut aussi signifier qu’un modèle s’exécute sur un appareil plutôt que via un service distant. Cela peut enfin vouloir dire qu’une équipe a confié au modèle une mission étroite. Ces affirmations ne sont pas équivalentes. Un nombre de paramètres minuscule n’implique pas un rôle social minuscule, tout comme un nombre de paramètres élevé ne vous dit pas où le système est autorisé à agir.

Il existe une deuxième confusion. On utilise « petit » pour dire « local », et « local » pour dire « inoffensif ». Un déploiement local peut améliorer le contrôle sur les flux de données, la disponibilité ou la propriété opérationnelle. Il peut aussi placer une décision directement au sein d’un lieu de travail, d’un guichet public, d’un parcours de soins, ou d’un appareil dont une personne ne peut pas facilement se séparer. La proximité physique peut réduire un type de dépendance tout en augmentant l’importance des personnes qui exploitent le système. Un serveur dans le même bâtiment n’est pas une catégorie morale.

Il y a ensuite « petit » comme promesse de capacité. Un composant peut être entraîné pour une seule tâche et influencer néanmoins un processus plus vaste. Il peut ne renvoyer que « approuver », « examiner » ou « refuser ». Le flux de travail en aval peut traiter ces trois mots comme un sas de validation. Le composant n’a pas besoin de rédiger une dissertation pour prendre une décision qui compte. Il lui suffit d’être placé là où le système suivant, ou la personne suivante, ne peut pas facilement le remettre en question.

Pour la gouvernance, l’unité utile n’est donc pas le modèle seul. C’est le modèle tel qu’il est déployé, avec un objectif, un opérateur, une limite d’entrée, un contrat de sortie, une action en aval et une voie de recours. C’est moins ordonné qu’un classement. C’est aussi plus proche de la réalité. Le classement peut vous dire comment un modèle a performé sur une tâche. Il ne peut pas vous dire si cette tâche était autorisée, si les personnes concernées pouvaient s’y opposer, ou si l’organisation avait le pouvoir d’utiliser le résultat.

Le langage de la Commission européenne autour de l’IA à usage général illustre subtilement cette distinction. La Commission fournit des critères techniques pour aider à déterminer quand un modèle peut relever des obligations de l’IA à usage général, mais elle précise aussi que ces critères sont indicatifs et qu’une évaluation au cas par cas reste nécessaire. La ligne directrice ne prétend pas qu’un seul chiffre peut décrire tous les rôles qu’un modèle pourrait jouer. Elle tente de rendre une question de classification opérationnelle sans la transformer en théorie universelle du préjudice.

Le seuil n’est pas le verdict

Il y a des chiffres dans l’AI Act, et c’est l’une des raisons pour lesquelles les gens se tournent vers les chiffres lorsqu’ils veulent de la certitude. L’article 51 crée une présomption de capacités à fort impact pour un modèle d’IA à usage général entraîné avec une quantité cumulée de calcul supérieure à 1025 opérations en virgule flottante. Cette présomption appartient à la classification des modèles d’IA à usage général présentant un risque systémique. Ce n’est pas une règle selon laquelle un modèle sous le seuil est sûr, ni une règle selon laquelle chaque modèle au-dessus cause le même préjudice.

Les orientations de la Commission sur l’IA à usage général utilisent un seuil indicatif différent, supérieur à 1023 opérations en virgule flottante, associé à une capacité générative étendue, pour aider à identifier les modèles qui peuvent être à usage général. La page est explicite sur les limites. Un modèle sous l’indicateur peut tout de même être qualifié s’il fait preuve d’une généricité significative. Un modèle qui l’atteint peut exceptionnellement ne pas être qualifié s’il manque de la généricité pertinente. Les orientations sont une interprétation pour une question juridique particulière, et non un laissez-passer pour chaque usage en aval.

Ces deux seuils sont utiles précisément parce qu'ils sont étroits. Ils aident les autorités et les fournisseurs à classer une catégorie spécifique d'obligations relatives aux modèles. Ils ne tranchent pas la question de savoir si un petit modèle intégré dans un système à haut risque mérite une attention particulière. Ils ne tranchent pas la question de savoir si le traitement des données est licite. Ils ne tranchent pas la question de savoir si une personne peut contester une décision. Un seuil peut établir qu'une question doit être posée. Il ne peut pas répondre à la question qui relève d'une autre couche.

Les seuils techniques vieillissent également. Le règlement dispose que la Commission peut ajuster le seuil de risque systémique au regard des évolutions technologiques, y compris les améliorations algorithmiques et l'efficacité matérielle. Les orientations de la Commission indiquent que son propre critère n'est pas absolu. C'est une admission raisonnable. Un chiffre qui semble stable dans un tableur d'appel d'offres peut bouger lorsque la technologie environnante change. La réponse responsable ne consiste pas à se méfier de chaque chiffre. Elle consiste à maintenir le chiffre rattaché à la question qu'il était conçu pour répondre.

Il y a une leçon pratique pour les équipes qui publient des fiches de modèles ou des notes d'architecture interne. Indiquez le seuil, l'unité, la disposition légale et la limite. Précisez si un chiffre est une présomption légale, un indicateur de la Commission, une condition de référence ou une cible de conception interne. Ne laissez pas une métrique acquérir une signification plus grande parce qu'elle est pratique dans une présentation. Une petite métrique peut aussi porter une grande obligation. Le chiffre a besoin de sa propre provenance.

Un système est plus que le modèle qu'il contient

Le règlement sur l'IA rend la frontière du système visible. Il définit les fournisseurs et les déployeurs, sépare les modèles des systèmes et attribue des obligations le long d'une chaîne de valeur. Un fournisseur peut être la personne ou l'organisation qui développe un système ou le fait développer et le met sur le marché ou le met en service sous son propre nom. Un déployeur est la personne ou l'organisation qui utilise un système sous son autorité. Ces rôles comptent parce que le même composant sous-jacent peut se trouver dans des arrangements différents avec des responsabilités différentes.

Imaginez un classificateur de texte compact qui renvoie l'une de quatre catégories. Le modèle n'a pas d'interface utilisateur, pas de mémoire et aucune capacité à appeler un outil. Dans un contexte, il trie les documents d'une équipe dans des dossiers. Dans un autre, il étiquette des demandes pour un service public afin que certaines personnes soient soumises à un examen supplémentaire. Le composant peut être techniquement identique. Le deuxième système a un objectif différent, des personnes concernées différentes, une relation de pouvoir différente et un besoin différent d'explication et de réparation.

Les règles de classification des risques élevés du règlement suivent ce type de différence. Elles examinent si un système est un composant de sécurité, s'il est utilisé dans un domaine énuméré à l'annexe III et s'il présente un risque significatif pour la santé, la sécurité ou les droits fondamentaux. La voie des usages énumérés n'est pas un jugement sur l'élégance du modèle. C'est un jugement sur ce que le système fait dans un contexte où une sortie erronée peut avoir de l'importance. Une tâche procédurale étroite peut relever d'une exception soigneusement formulée lorsqu'elle n'influence pas matériellement une décision, mais le fournisseur doit documenter cette évaluation.

Cette exigence de documentation est facile à sous-estimer. Une équipe qui affirme que le système est seulement préparatoire fait une affirmation de causalité. Elle dit que la sortie n'influence pas matériellement la décision qui suit. Si l'examinateur traite l'étiquette comme une raison d'ouvrir un dossier, si le personnel se fie à un classement, ou si un demandeur n'a aucun moyen significatif de corriger les données derrière le signal, l'influence pratique peut être plus grande que ce que l'interface suggère. Le mot préparatoire ne peut pas être autorisé à signifier invisible.

Les limites du système incluent aussi la mécanique banale qui entoure un modèle : la source de données, le seuil, la file d'attente, la personne qui reçoit le résultat, l'enregistrement qui subsiste, le contrat du fournisseur, le processus de mise à jour et le moyen d'arrêter le flux de travail. Un petit modèle peut être l'objet visible alors que le risque réel se situe dans la transmission. C'est pourquoi une revue des risques qui ne demande que ce que le modèle prédit est incomplète. La question la plus difficile est de savoir ce que l'organisation fait parce qu'elle l'a prédit.

La finalité change le sens d'une même sortie

Une sortie n'a aucune obligation dans le vide. La même probabilité, la même catégorie ou la même recommandation peut être bénigne dans une tâche et lourde de conséquences dans une autre. Ce n'est pas parce que les mots changent de sens dans le dictionnaire. C'est parce qu'une sortie entre dans une structure de décision. Un classement utilisé pour choisir quelles notes de recherche lire en premier n'est pas la même chose qu'un classement utilisé pour décider quel foyer fait l'objet d'une enquête pour fraude. La machine peut utiliser les mêmes mathématiques. L'institution n'a pas la même relation avec les personnes à l'autre bout.

L'article 7 de la loi sur l'IA énumère les critères que la Commission doit prendre en compte lorsqu'elle ajoute ou modifie des cas d'utilisation à haut risque. Ils incluent la finalité prévue, l'ampleur de l'utilisation du système ou de son utilisation probable, la nature et la quantité des données, l'autonomie et la possibilité d'intervention humaine, l'étendue et l'intensité des dommages possibles, la dépendance au résultat, le déséquilibre de pouvoir, la vulnérabilité, la réversibilité, le bénéfice et la disponibilité de voies de recours. Lus ensemble, ces critères constituent une réfutation utile de la pensée centrée sur la taille du modèle. Ils décrivent une relation, pas un fichier de poids.

Le composant reste petit tandis que la finalité, le pouvoir, la dépendance et la réversibilité qui l'entourent changent la question du contrôle.

La dépendance est particulièrement importante. Une personne peut parfois ignorer une recommandation, chercher un autre service ou demander à un collègue de vérifier la réponse. Une personne peut aussi n'avoir aucune alternative pratique. Si une étape de filtrage automatisée détermine si un service est retardé, si une demande reçoit de l'attention ou si un travailleur est convoqué à une réunion, la personne concernée peut devoir vivre avec la première interprétation du système pendant que l'organisation décide de réexaminer ou non. Plus la décision visible est petite, plus il peut être facile de manquer la dépendance qui se cache en dessous.

La réversibilité compte pour la même raison. Une coquille dans une balise interne peut être corrigée avant que quiconque ne s’y fie. Un signal de risque peut modifier l’ordre dans lequel un dossier est traité, et ce délai peut lui-même avoir des conséquences. Un refus peut entraîner un non-respect d’échéance. Un classement peut devenir le seul classement qu’une équipe occupée consulte. Le fait qu’un administrateur puisse techniquement modifier une base de données ne prouve pas que le résultat social soit facile à inverser. La réversibilité technique et la réversibilité vécue sont liées, mais elles ne sont pas identiques.

C’est ici que la proportionnalité prend tout son sens. Une suggestion interne à faible impact peut nécessiter un enregistrement léger et un responsable clairement désigné. Un système qui influence l’accès à un service public exige un parcours de preuve plus solide, une voie humaine informée et un moyen de contester les données d’entrée comme les résultats. Des contrôles proportionnés ne sont pas l’absence de contrôles. Ce sont des contrôles choisis parce que la relation les mérite.

Les données conservent leurs obligations

La taille d’un modèle ne rend pas les données anonymes par simple effet d’ambiance. L’avis 28/2024 du Comité européen de la protection des données indique que la question de savoir si un modèle d’IA peut être considéré comme anonyme doit être évaluée au cas par cas. Le test décrit dans le résumé public du CEPD demande s’il est très peu probable que le modèle puisse identifier directement ou indirectement les personnes dont les données ont servi à le créer, et s’il est très peu probable que leurs données personnelles puissent être extraites par des requêtes. Un modèle plus petit peut contenir moins d’informations, mais « moins » n’est pas une conclusion juridique.

Le CEPD garde également en vue le contexte entourant l’intérêt légitime. Son analyse pointe vers la nécessité et la mise en balance, et énumère la relation entre les personnes et le responsable du traitement, la nature du service, le contexte dans lequel les données ont été collectées, la source, les utilisations ultérieures possibles et ce que les personnes pouvaient raisonnablement attendre. Ces facteurs ne disparaissent pas lorsqu’un modèle est compressé, distillé, quantifié ou placé derrière une API soignée. La compression modifie un objet technique. Elle ne réécrit pas l’histoire de la raison pour laquelle les données ont été collectées ni ce qui a été dit aux personnes.

Il y a une discipline utile à lire cet avis en parallèle de l’ingénierie des modèles. Demandez-vous à quoi le modèle a été entraîné ou adapté, quelles données il reçoit au moment de l’exécution, quels enregistrements sont conservés et qui peut l’interroger. Puis demandez-vous ce qui se passe en aval. Le résultat est-il copié dans un dossier de cas. Un classement devient-il une instruction. Un examinateur humain voit-il le matériel source ou seulement l’étiquette du modèle. Existe-t-il un moyen pour la personne concernée de corriger une erreur factuelle. Ce sont des questions de données et de gouvernance, et pas seulement des questions de précision.

Le résumé public du CEPD note également que l’utilisation de données personnelles traitées illégalement dans le développement d’un modèle peut affecter la légalité du déploiement, à moins que le modèle n’ait été dûment anonymisé. Cette phrase résiste à une échappatoire familière. Une équipe ne peut pas faire disparaître un problème en disant que le modèle final est petit, que les données ne sont plus visibles ou que le modèle n’est qu’un composant parmi d’autres. L’histoire juridique et éthique des données reste une partie de l’histoire du système.

Pour les ingénieurs, cela signifie que le dossier d’entraînement et le dossier de déploiement ne doivent pas être traités comme des univers séparés. Pour les achats, cela signifie qu’une déclaration d’un fournisseur sur la taille du modèle ne remplace pas la provenance des données, la finalité, la conservation, la gestion des droits ou la documentation en aval. Pour une personne concernée, cela signifie que la question utile n’est pas de savoir combien de paramètres étaient impliqués. C’est ce qui est arrivé à ses informations et ce que l’organisation peut faire lorsque le résultat est erroné.

Un petit signal peut déplacer une grande file d’attente

Prenons l’exemple hypothétique d’un service d’assistance qui reçoit des demandes de la part des habitants. Un classifieur compact lit le premier message et attribue une orientation : information, travail courant, examen urgent ou prise en charge par un spécialiste. L’exemple est volontairement ordinaire et entièrement illustratif. Il n’y a ni conseil municipal nommé, ni déploiement réel, ni horodatage, ni affirmation que cela s’est produit. L’objectif est de rendre la limite visible.

Si les catégories servent uniquement à aider un agent à organiser un ensemble de notes privées, le risque peut être modeste. Si l’orientation urgente détermine qui reçoit une inspection de sécurité, le résultat se rapproche alors d’une décision publique. Si un mot-clé manquant envoie la demande d’une personne vers le travail courant, le retard peut avoir de l’importance même si le modèle ne s’adresse jamais à l’habitant. Si l’agent peut voir le message original, modifier l’orientation, consigner la raison et répondre rapidement à une contestation, le système adopte une posture de contrôle différente de celle où l’étiquette devient un guichet caché.

Le modèle n’est pas devenu plus grand. L’obligation est devenue plus claire. Elle suit le chemin de l’entrée vers la conséquence. L’organisation doit savoir ce que signifient les catégories, quels éléments de preuve le modèle peut utiliser, quels cas exigent un refus ou une escalade, qui peut annuler l’orientation, et quel enregistrement permet à un examinateur ultérieur de comprendre la décision. La modestie du modèle n’est pas une raison pour éviter ces questions. Elle peut être une raison d’y répondre avec plus de précision, car le contrat du composant peut être rendu étroit.

Une hypothèse similaire apparaît dans le domaine de l’emploi. Un petit modèle pourrait extraire des compétences d’un CV, classer un poste ou signaler un certificat manquant. L’extraction semble moins lourde de conséquences que la sélection, mais l’extraction peut façonner le classement qui suit. Si le résultat n’est jamais utilisé pour décider qui progresse, le système peut rester du côté préparatoire d’une limite. Si les gens traitent l’étiquette extraite comme un résumé objectif et cessent de consulter le document, la limite se déplace. L’obligation réside dans l’usage, non dans le verbe choisi pour décrire le travail du modèle.

Dans les deux illustrations, la bonne réponse n’est pas de paniquer face à un petit modèle. C’est de rendre la passation explicite. Nommer l’objectif visé. Déclarer ce que le résultat peut et ne peut pas modifier. Conserver la source et la version du modèle lorsque une décision en dépend. Donner à une personne suffisamment d’informations et d’autorité pour être en désaccord. Tester les segments où le système est censé être incertain. Examiner le flux de travail lorsque l’organisation modifie les données, le seuil, le public ou l’action en aval.

Ce que l’arrêt néerlandais SyRI enseigne réellement

L’Europe dispose déjà d’un exemple documenté d’un système de risque d’apparence compacte portant une obligation à la mesure des droits. Le 5 février 2020, le tribunal de district de La Haye a décrit SyRI comme un instrument gouvernemental légal utilisé pour lutter contre la fraude dans les prestations, les allocations et les impôts. Le tribunal n’a pas tranché l’affaire en demandant combien de paramètres le système possédait. Il a évalué le cadre juridique au regard de l’article 8 de la Convention européenne des droits de l’homme, notamment en vérifiant si l’ingérence dans la vie privée établissait un juste équilibre.

Le tribunal a conclu que la législation SyRI ne satisfaisait pas à ce critère. Selon le tribunal, l’utilisation de SyRI était insuffisamment transparente et contrôlable. Le cadre juridique était donc incompatible avec le droit supérieur et ne pouvait subsister sous sa forme existante. La page publique de l’affaire est concise, mais sa leçon n’est pas mince : lorsqu’un État utilise un système d’indication de risque contre des personnes qui ont peut-être peu de moyens de le comprendre ou de le contester, le système doit offrir un niveau de transparence et de contrôle à la hauteur de cette relation.

SyRI était un instrument néerlandais d'indication de risque prévu par la loi, et non une étude de cas sur un modèle neuronal moderne, et la page du tribunal ne nous fournit pas un nombre de paramètres à discuter. C'est précisément pour cela qu'il a sa place ici. L'exemple nous empêche de considérer l'architecture des modèles comme le seul objet digne d'intérêt. Un moteur de règles, une grille de score, un modèle statistique ou un petit classifieur peuvent tous faire partie d'une décision institutionnelle. La question des droits se pose à travers l'usage.

Le jugement place également la transparence au bon endroit. Il ne s'agit pas simplement d'une demande d'explication après qu'une personne a subi un préjudice. Elle fait partie des conditions dans lesquelles le système peut être évalué avant et pendant son fonctionnement. Si les personnes ne peuvent pas voir suffisamment l'objectif, l'utilisation des données, les garanties et la voie de recours pour comprendre l'ingérence, une organisation pourrait ne pas être en mesure de démontrer l'équilibre équitable qu'elle prétend avoir établi.

Il n'est pas nécessaire de faire de SyRI une analogie universelle. Le cadre juridique néerlandais, les faits de l'affaire et la Convention européenne sont spécifiques. Le transfert utile est plus étroit : ne demandez pas si un système est techniquement impressionnant avant de demander si sa relation institutionnelle est visible, contrôlable et contestable. Une machine plus petite n'excuse pas un silence plus grand.

L'étiquette se déplace en aval

Un modèle peut être introduit comme composant et faire néanmoins partie d'un système qui porte une autre obligation. Les orientations de la Commission sur les GPAI expliquent pourquoi les fournisseurs en aval ont besoin d'informations sur les capacités et les limites d'un modèle. Ils ont besoin de ces informations pour intégrer le modèle de manière responsable et pour satisfaire à leurs propres obligations au titre de l'AI Act. Le fournisseur du modèle et le fournisseur du système ne rédigent pas le même document parce qu'ils ne répondent pas à la même question.

Cette distinction importe lorsque les équipes traitent une fiche de modèle comme un passeport. Une fiche de modèle peut décrire l'architecture, la formation, l'évaluation, les limites connues et les usages prévus. Elle ne peut pas, à elle seule, décrire chaque environnement dans lequel une équipe en aval pourrait placer le modèle. Le système en aval ajoute un utilisateur, un objectif, des flux de données, une interface, des rôles humains, une décision et un ensemble de personnes concernées. Ces ajouts peuvent modifier l'obligation même lorsque les poids du modèle restent inchangés.

La responsabilité peut également changer lorsqu'une organisation modifie l'objectif prévu ou apporte une modification substantielle. Les dispositions de l'AI Act relatives à la chaîne de valeur décrivent les circonstances dans lesquelles un acteur peut assumer des responsabilités de fournisseur, notamment en modifiant l'objectif prévu d'un système d'IA de sorte qu'il devienne à haut risque. C'est un avertissement utile contre le brouillard contractuel. Un fournisseur peut fournir un composant, mais un déployeur ne peut pas faire disparaître son propre usage en qualifiant le composant de bibliothèque.

La passation pratique devrait donc comporter plus qu'un lien de téléchargement. Elle devrait indiquer les tâches prévues, les limites d'entrée et de sortie, les exigences d'intégration, les informations de formation et de validation le cas échéant, les limites connues et les conditions dans lesquelles le composant ne devrait pas être utilisé. Elle devrait expliquer ce que le modèle n'a pas évalué. Une équipe en aval ne devrait pas avoir à déduire l'absence d'une garantie de la présence d'un schéma confiant.

Il y a une raison humaine à cette paperasse. La personne concernée par le système final ne rencontre pas un fournisseur de modèle dans l'abstrait. Elle rencontre une organisation qui a choisi un flux de travail. L'organisation doit être en mesure de dire ce que le composant a fait, ce que l'organisation en a fait et comment une personne peut contester le résultat. Si les réponses vivent dans trois contrats et aucun enregistrement opérationnel, le système n'est pas bien intégré. Il est simplement bien distribué.

La voie humaine doit être réelle

La supervision humaine est souvent présentée comme une personne assise près d'un écran. L'AI Act est plus précis. Pour les systèmes à haut risque, la supervision doit être efficace et proportionnée aux risques, au niveau d'autonomie et au contexte d'utilisation. La personne chargée de la supervision doit être capable de comprendre les capacités et les limites pertinentes, de surveiller les anomalies, d'interpréter la sortie, de décider de ne pas l'utiliser, de l'ignorer ou de la remplacer, de l'annuler, et d'intervenir ou d'arrêter le système en toute sécurité.

Aucun de ces verbes n'est garanti par un petit modèle. Une sortie étroite peut être plus facile à interpréter, mais l'interprétation n'est pas la même chose que l'autorité. Un bouton de remplacement que personne ne peut utiliser parce que la file d'attente est trop longue n'est pas une supervision efficace. Un réviseur qui ne voit qu'une couleur ou une étiquette ne peut pas vérifier utilement la source. Une personne tenue responsable d'une décision mais qui ne peut pas suspendre le flux de travail n'est pas le point de contrôle. C'est un vide décoratif en forme d'humain dans le schéma.

Une supervision proportionnée peut être discrète. Il peut s'agir d'une voie claire pour qu'un travailleur signale des preuves insuffisantes, d'un second contrôle pour une catégorie sensible, d'un enregistrement des raisons pour lesquelles une recommandation a été rejetée, ou d'une pause automatique lorsque des champs obligatoires sont manquants. Il peut s'agir d'une personne qui assume la décision et qui a le temps d'examiner les cas que le système lui transmet. Les détails dépendent du contexte. L'exigence est que la voie fonctionne lorsque le système est incertain, erroné, indisponible ou contesté.

Pour les petits modèles, un refus structuré peut être un avantage. Si un classifieur peut dire source manquante, hors périmètre ou nécessite un examen, l'organisation dispose d'un événement concret à traiter. C'est mieux qu'un paragraphe fluide qui transforme silencieusement l'incertitude en instruction. Mais le refus a toujours besoin d'un responsable. Si chaque refus devient une impasse, le système a simplement déplacé la charge sur quelqu'un sans lui donner de voie pour la traiter.

La voie humaine s'étend à la personne concernée. Une personne ne devrait pas avoir besoin de la terminologie du fournisseur pour contester un résultat. L'organisation devrait savoir quelles informations peuvent être expliquées, ce qui peut être corrigé, qui examine le cas et ce qui se passe pendant que l'examen est en cours. Un petit modèle peut rendre la trace interne plus facile à décrire. Cela ne réduit pas l'importance de la personne extérieure au système.

Des contrôles proportionnés restent des contrôles

Une gouvernance proportionnée commence par refuser deux mauvais marchés. Le premier dit que chaque système mérite le même processus lourd, ce qui transforme la gestion des risques en paperasse et finit par apprendre aux équipes à cacher leur travail. Le second dit que les petits modèles ne méritent aucun processus sérieux, ce qui confond un composant étroit avec une institution inoffensive. Une approche proportionnée demande ce que le système peut changer, qui peut être affecté et quelles preuves permettraient à l'organisation de réparer une erreur.

Le premier contrôle est un énoncé d'objectif qu'un non-spécialiste peut comprendre. Il doit nommer la tâche, les utilisateurs prévus, les personnes concernées, les données d'entrée autorisées, la sortie et les actions que le système ne peut pas entreprendre. Un objectif tel que soutien à la priorisation est trop vague s'il peut signifier organiser un arriéré privé, décider qui reçoit une inspection réglementaire ou sélectionner des candidats pour un examen disciplinaire. La phrase n'est pas un texte marketing. C'est la limite par rapport à laquelle les changements ultérieurs sont vérifiés.

Le deuxième contrôle est une limite d'entrée et de preuves. Quelles sources le système peut-il lire. Quels champs sont faisant autorité. Quelle doit être leur fraîcheur. Que se passe-t-il lorsqu'une valeur est manquante ou entre en conflit avec une autre source. Des données personnelles peuvent-elles entrer dans le parcours. Quel enregistrement est conservé. Un modèle compact peut être strict sur l'entrée et échouer quand même si le flux de travail environnant élargit silencieusement les données. Le périmètre a besoin d'un responsable, pas seulement d'un schéma.

The third control is an output contract. State the allowed labels, the uncertainty states, the refusal conditions, and the downstream actions for each result. If the system returns a score, say what the score means and what it does not mean. If it returns a ranking, say whether the ranking is a suggestion or a gate. If it returns a category, say who may change it and what record captures the change. A small vocabulary is useful only when the institution agrees not to smuggle extra authority into it.

The fourth control is a change path. Model updates, threshold changes, new data sources, a different user group, a new supplier, or a changed downstream action can alter the system's risk. The AI Act's lifecycle language is a reminder that risk management is iterative. A component that was narrow in January may sit inside a different decision in August. The obligation follows the changed relationship, not the date on the first design document.

The fifth control is an exit. Can the organisation pause the component, fall back to a human route, export the records, explain the decision history, and replace the supplier without losing the evidence needed to repair cases. Exit is not a luxury for large systems. A small model can become a single point of institutional memory if nobody preserves the source, version, and decision path around it.

A proportionate evidence file

A proportionate evidence file is not a warehouse of every thought anyone had about the model. It is a readable answer to the questions a reviewer, operator, affected person, or regulator may reasonably ask. What was the intended purpose. Which version ran. What data did it receive. What did it return. Which rule or threshold turned that output into an action. Who had authority to change the result. What happened when evidence was missing. How can the decision be replayed or challenged.

For a low-consequence suggestion, the file may be small. It might contain the purpose, source, version, basic evaluation, owner, retention rule, and a link to the correction route. For a system that influences access, safety, employment, or rights, the file needs more. It should connect the risk analysis to the data and the output contract, show how human oversight works in practice, document known limitations, and retain enough operational history to investigate a disputed result. Proportion grows with consequence, not with parameter count.

Testing should follow the same logic. A single accuracy figure cannot describe a system's fitness for every context. Test the data slices and conditions that matter to the purpose. Include missing and conflicting inputs. Include cases where refusal is correct. Check whether the model's output is used differently by different teams. Record what was measured, under which conditions, and what remains unknown. A model that performs well on a clean test set can still be badly placed in a messy institution.

Monitoring is not a dashboard ornament. It is how the organisation learns that the real workflow has changed. Watch for shifts in input data, disagreement rates, refusal rates, changes in human overrides, new downstream uses, and complaints or correction requests. The exact signals depend on the system. The principle is stable: the evidence should include the relationship that creates the obligation, not only the model's internal score.

Good evidence also has an expiry date, even when the records are retained longer. A legal interpretation can change. A service can reach a new population. A supplier can update a model. A route that was reversible can become embedded in another system. Mark what was assessed, when, by whom, and against which purpose. The record then becomes a history of decisions rather than a static certificate that outlives the conditions that made it meaningful.

The failure modes of small models

Les petits systèmes échouent de manière reconnaissable. Un classifieur peut manquer une catégorie parce que la définition du libellé est ambiguë. Un extracteur peut renvoyer un champ plausible issu de la mauvaise phrase. Un modèle de classement peut privilégier les cas familiers et masquer les cas inhabituels. Un seuil peut transformer une incertitude continue en un faux binaire. Un modèle local peut fonctionner de manière fiable alors que les données sources sont obsolètes. Aucune de ces défaillances n’est automatiquement catastrophique. Chacune devient importante lorsque le flux de travail traite la sortie comme plus autoritaire que ne le permet le contrat du composant.

Le premier mode de défaillance est la fausse modestie. L’équipe affirme que le modèle ne fait que signaler, trier ou assister, puis conçoit le flux de travail de sorte que le personnel ne soit que rarement en désaccord. Le libellé devient une décision par habitude. Ce n’est pas un défaut du nombre de paramètres du modèle. C’est un défaut dans la gestion de l’autorité par l’institution. Le remède consiste à rendre la transmission visible, à mesurer les dérogations et les désaccords, et à donner aux personnes un moyen pratique de modifier le résultat.

Le deuxième est la composition cachée. Un petit modèle peut côtoyer la récupération, des règles, une file d’attente, un classement et un service de notification. Chaque composant semble limité. Ensemble, ils peuvent créer un chemin de décision puissant. L’examen des risques doit suivre le chemin de bout en bout. Quelle source entre en premier. Quelle transformation supprime du contexte. Quel libellé déclenche une action. Quel enregistrement survit. Quelle personne peut arrêter la chaîne. L’assurance au niveau du composant est nécessaire, mais ce n’est pas la vue système.

Le troisième est l’obligation obsolète. Un modèle reste inchangé alors que son objectif ou son public change. Une équipe ajoute une nouvelle source de données, envoie la sortie à un autre service ou commence à utiliser un outil de priorisation privé dans un flux de travail public. La fiche du modèle reste la même, alors tout le monde suppose que le risque est le même. Il ne l’est pas. L’objectif prévu a changé, et le dossier de preuves devrait suivre.

Le quatrième est le halo du petit modèle. Une facture de ressources faible ou un déploiement local soigné donne l’impression que le système est plus responsable qu’il ne l’est. L’organisation peut encore échouer à expliquer le résultat, à conserver l’entrée, à offrir un recours ou à désigner une personne ayant autorité. L’efficacité technique est bienvenue. Elle ne remplace pas le contrôle institutionnel. Un système peut être peu coûteux à exécuter et coûteux à défendre.

Le cinquième est la sortie manquante. Les petits composants sont faciles à ajouter et difficiles à retirer lorsqu’ils sont intégrés dans un processus chargé. Un remplacement change les catégories, les seuils ou les enregistrements que les équipes en aval attendent. Si personne n’a répété le changement, le système devient collant. Le modèle peut être petit, mais la migration est désormais un problème public. La portabilité appartient à la première conversation de conception, pas à la dernière réunion d’approvisionnement.

Quand le petit est le bon choix d’ingénierie

Rien de tout cela ne doit se transformer en campagne contre les petits modèles. Le petit peut être exactement ce qu’il faut. Une tâche étroite avec un contrat clair peut ne pas nécessiter un modèle généraliste. Un composant local peut garder les entrées sensibles plus près des personnes qui en sont responsables. Une sortie fixe peut faciliter la validation et la surveillance. Un modèle qui refuse en dehors de son périmètre peut être plus sûr à composer qu’un modèle qui répond à chaque question avec une confiance gracieuse.

Le cas d’ingénierie est le plus solide lorsque l’équipe peut nommer ce que le composant ne fera pas. Il ne classera que les catégories approuvées. Il ne lira que les champs déclarés. Il renverra des preuves insuffisantes lorsqu’un champ requis est manquant. Il n’appellera pas un outil. Il ne prendra pas la décision finale. Il portera une version et un dossier d’évaluation. Il sera remplaçable parce que l’interface et le contrat de preuves sont documentés. Ces contraintes ne rendent pas le système enfantin. Elles rendent ses responsabilités lisibles.

Les petits composants peuvent aussi favoriser une meilleure division du travail. Un modèle large peut interpréter un langage imprécis ou rédiger une explication lisible par un humain. Un composant strict peut extraire un champ, appliquer une règle de contrôle, classer un ensemble déclaré de sources ou vérifier qu’une sortie respecte une forme connue. Un moteur de règles ou un solveur peut prendre en charge la partie qui doit être exacte. Une personne peut assumer le jugement qui ne peut être réduit sans risque. L’important n’est pas la pureté. C’est que chaque partie ait une tâche délimitée et que le système enregistre comment les tâches se connectent.

Il y a une dimension pratique européenne dans cette organisation. Les institutions remplacent rarement tout d’un coup. Elles ont besoin de systèmes capables de fonctionner dans les conditions matérielles, juridiques, linguistiques et d’approvisionnement qui sont réellement les leurs. Les petits composants peuvent parfois être déployés plus près du travail, évalués sur la base de preuves locales et remplacés sans demander à toute une organisation de changer sa mémoire. C’est une attente, pas une affirmation sur chaque petit modèle. Le déploiement exige encore la preuve que l’adéquation est réelle.

La petitesse est aussi utile comme discipline. Lorsqu’une équipe ne peut pas résoudre un problème en ajoutant davantage de capacité générale, elle doit décider quelles informations comptent, quelle incertitude peut être exposée et quels cas nécessitent une personne. Ce travail de conception peut révéler qu’un modèle n’est pas nécessaire. Parfois, le bon composant est une contrainte de base de données, un index de recherche, un enregistrement signé ou un formulaire bien conçu. Un modèle plus petit peut porter une grande responsabilité. Un non-modèle peut en porter une aussi.

Quand la petitesse sert de camouflage

La petitesse devient un camouflage lorsqu’elle est présentée comme la réponse avant que quiconque ait décrit la question. Le discours peut affirmer que le composant est léger, local, privé, efficace ou ouvert. Ce sont tous des faits utiles. Ils ne disent pas à une personne concernée si le système peut être contesté, ni à un opérateur si le résultat peut être annulé, ni à un régulateur si l’organisation a compris son objectif.

Le camouflage apparaît souvent dans le langage des appels d’offres. On montre à un acheteur une taille de modèle, un chiffre de latence et un coût d’inférence. Le contrat précise que le fournisseur fournit un outil d’aide à la décision. Personne n’écrit quelles décisions, quelles données, quelles populations, quelle voie humaine ou quels changements déclenchent un examen. Plus tard, une équipe interne découvre que l’outil est devenu une barrière parce que la file d’attente, le délai ou le tableau de bord ont rendu la recommandation pratique à suivre. Le modèle était petit. La gouvernance l’était encore plus.

Un autre camouflage est l’expression « humain dans la boucle ». Une personne peut techniquement toucher chaque cas sans avoir pour autant un temps, une information ou une autorité significatifs. La boucle fonctionne alors comme un rituel d’approbation. Un petit modèle peut rendre cela particulièrement tentant, car la sortie semble simple. Trois catégories arrivent, une personne clique sur l’une d’elles et l’organisation appelle le résultat « examiné ». L’examen exige la capacité de comprendre, de contester et de modifier le résultat. Un clic n’est pas une protection en soi.

Un troisième camouflage est l’affirmation selon laquelle le local signifie souverain. Le traitement local peut aider en matière de résidence, de latence et de contrôle opérationnel, mais la souveraineté concerne aussi qui peut modifier le logiciel, détenir les clés, accéder aux enregistrements et maintenir le service en fonctionnement lorsqu’un fournisseur ou un réseau est indisponible. Le petit modèle dans un appareil peut être local, tandis que ses mises à jour, son évaluation et son autorité restent ailleurs. La localisation est un fait sur la carte. Le contrôle est un fait dans la relation.

L’antidote n’est pas une forme plus grande. C’est une forme plus nette. Demandez l’objectif. Demandez ce qui change à cause de la sortie. Demandez qui peut être en désaccord. Demandez ce que la personne concernée peut faire. Demandez quelles preuves sont conservées. Demandez comment le système est mis en pause, remplacé et réévalué. Si les réponses sont claires, la taille du modèle peut retrouver sa juste place comme un choix d’ingénierie parmi d’autres.

Les questions d’un acheteur

Avant qu'un petit modèle n'entre dans un flux de travail à enjeux, un acheteur devrait pouvoir répondre à une série de questions simples. Quel est l'objectif visé en une phrase. Qu'est-ce qui est hors du périmètre. Quelles personnes peuvent être affectées, directement ou par une action en aval. Quelles données sont requises, et quelles données sont interdites. Qu'est-ce que chaque sortie permet à l'organisation de faire. Qu'est-ce qu'elle ne lui permet pas de faire.

Puis il faut s'interroger sur l'autorité. Qui possède la décision. Qui peut passer outre le modèle. Qui peut arrêter le flux de travail. Quelles informations cette personne voit-elle. De combien de temps dispose-t-elle. Que se passe-t-il en cas de désaccord. La personne affectée est-elle suffisamment informée pour demander un réexamen. L'organisation peut-elle corriger l'entrée aussi bien que la sortie. Ces questions ne sont pas une accusation contre le fournisseur. Elles constituent la description minimale de l'institution qui achète l'outil.

Il faut s'interroger sur les preuves. Quelle version a été exécutée. Quelle configuration de modèle et de politique était active. Quelles sources étaient disponibles. Quel seuil ou quelle règle a transformé la sortie en action suivante. Qu'est-ce qui est enregistré lorsqu'un humain modifie le résultat. L'organisation peut-elle rejouer un cas sans prétendre qu'une nouvelle exécution est l'ancienne. Peut-elle exporter les enregistrements dans un format qu'un autre système peut lire. La réponse n'a pas besoin d'être une grande plateforme. Elle doit être un véritable enregistrement.

Il faut s'interroger sur le changement. Ce qui compte comme une mise à jour du modèle. Ce qui compte comme une nouvelle source de données. Ce qui se passe lorsque l'objectif change. Quels changements exigent une nouvelle évaluation. Qui est notifié. Comment les personnes affectées sont-elles protégées pendant un retour arrière ou une migration. Si le fournisseur ne peut pas répondre, l'acheteur n'achète pas un petit risque. Il accepte une petite description d'une grande inconnue.

Enfin, il faut s'interroger sur la sortie. Le flux de travail peut-il fonctionner sans danger sans le modèle. L'organisation peut-elle récupérer les entrées, les sorties, les décisions et l'historique des corrections. Un autre composant peut-il répondre à la même interface sans nouvelle dépendance. Le système peut-il être retiré sans laisser les personnes dans l'incertitude. Un modèle n'est pas vraiment petit si son retrait oblige l'institution à oublier comment elle a pris ses décisions.

Une brève note de notre part

Chez Dweve, Loom est un exemple de la position de conception que nous apportons à cette question. Sa description publique de produit présente de petits composants linguistiques comme des moteurs de rendu autour d'un graphe de raisonnement typé, avec des traces, la relecture et des frontières de refus explicites. C'est une déclaration sur notre architecture et sur la manière dont nous voulons que la responsabilité d'un composant soit visible. Ce n'est ni une preuve indépendante, ni une classification réglementaire, ni un déploiement client, ni une promesse qu'un petit composant est automatiquement adapté à un usage à enjeux.

La partie utile de l'exemple est la frontière. Un composant peut être petit et mériter tout de même un contrat précis. Il peut être placé dans un graphe plus vaste sans devenir le propriétaire de chaque décision. Il peut porter une trace sans prétendre que la trace prouve que l'institution entière a agi légalement. Nous mentionnons Loom ici uniquement pour montrer comment notre propre travail tente de séparer la capacité du modèle, l'objectif du système, les preuves et l'autorité humaine. La question européenne reste la même pour nous que pour quiconque : que ce système peut-il changer, et les personnes responsables peuvent-elles encore l'inspecter et le corriger ?

L'obligation est portée par la relation

Un petit modèle peut être plus facile à exécuter, plus facile à tester et plus facile à remplacer. Ce sont de bonnes raisons d'en choisir un. Ce ne sont pas des raisons de réduire le devoir de diligence qui l'entoure. Les définitions et les règles de risque de l'AI Act, les orientations du GPAI de la Commission, l'approche au cas par cas de l'EDPB concernant les données et l'arrêt néerlandais SyRI pointent tous dans la même direction pratique sans constituer un seul test juridique : examiner l'objectif, le contexte, l'autorité, les preuves, les personnes affectées et la possibilité de réparation.

La bonne question n'est donc pas de savoir si le modèle est petit. C'est de savoir ce que le modèle est autorisé à modifier. S'il aide seulement une personne à rechercher ses propres notes, la réponse peut être modeste. S'il change qui reçoit l'attention, quel dossier est considéré comme fiable, ou si un service public ouvre une porte, la réponse est plus large. Si l'organisation ne peut pas expliquer la transmission, conserver les preuves, ou offrir à quelqu'un un moyen de contester le résultat, l'obligation a déjà dépassé le composant.

Une bonne gouvernance laisse place à la proportionnalité. Elle n'exige pas que chaque modèle devienne un comité. Elle demande à l'équipe de rendre visibles les relations importantes, de maintenir les affirmations liées aux preuves, et de donner aux personnes une réelle autorité lorsque le système est incertain ou erroné. Les petits modèles peuvent aider dans ce travail parce qu'un composant délimité peut être nommé et testé. Mais la délimitation est une réussite de conception, pas une propriété par défaut du fait d'être petit.

La taille appartient au dossier technique. La finalité appartient au dossier du système. Les conséquences appartiennent au dossier humain. Lorsque ces trois dossiers peuvent dialoguer entre eux, un petit modèle peut être utilisé avec précaution sans être considéré comme inoffensif. Lorsqu'ils sont tenus séparés, la modestie du modèle devient un théâtre, et les personnes qui portent le résultat paient pour le contexte manquant.

Sources