Tracker de conformité des modèles d'IA à usage général dans l'UE

Un score correspond au pourcentage de la partie vérifiable publiquement d'une exigence que les documents publiés par un fournisseur satisfont. Il mesure la divulgation au regard de notre ensemble d'indicateurs : quelle part de ce que le Code demande un fournisseur a effectivement rendu publique. Ce n'est pas une mesure de la sûreté d'un modèle, ni un constat de conformité juridique ; seul le Bureau de l'IA peut établir cette dernière. Un score faible signifie que nous n'avons pas pu vérifier un élément dans le domaine public, et non que le fournisseur ne le fait pas. Nous fondons simplement nos scores sur l'ensemble des informations accessibles publiquement.

Parce qu'il transforme la question « ce fournisseur fait-il ce que le Code demande ? » en quelque chose que chacun peut vérifier. Pour chaque exigence, nous renvoyons aux documents publics et aux citations exactes qui sous-tendent le score, de sorte qu'un journaliste, un chercheur ou le Bureau de l'IA puisse le reproduire et constater par lui-même où les preuves publiques sont solides et où elles sont insuffisantes. Il s'agit, à notre connaissance, du premier relevé public, clause par clause et sourcé, de ce que les fournisseurs de premier plan ont réellement divulgué au regard du Code, ce qui rend le débat sur la conformité concret plutôt qu'anecdotique et montre aux fournisseurs précisément où un peu plus de transparence comblerait une lacune visible.

Ce qu'il ne vous dit pas, c'est ce qu'un fournisseur a divulgué en privé au régulateur, ni ce qu'il fait en interne. Nous ne pouvons nous prononcer que sur ce qu'un fournisseur a, ou n'a pas, versé au dossier public pour chaque exigence, preuves et citations à l'appui. Ainsi, un score faible est un constat sur les preuves publiques dont nous disposons à une date donnée, et non un verdict définitif de sûreté ou de conformité concernant l'entreprise.

Non. Un score élevé mesure ce qu'un fournisseur a divulgué, et non si ses modèles sont sûrs, ni s'il est juridiquement conforme. Seul le Bureau de l'IA peut établir la conformité. Un score élevé signifie qu'une entreprise a à la fois publié et satisfait, dans l'esprit, ce que le Code demande ; un score faible signifie que nous n'avons pas pu le trouver dans le domaine public.

L'astérisque placé à côté du logo d'un fournisseur indique que celui-ci n'a pas formellement signé le Code de bonnes pratiques. Survolez-le pour afficher la même note.

Nous évaluons tous les fournisseurs que nous suivons au regard des mêmes exigences, qu'ils aient signé ou non. Nous sommes un observatoire indépendant, et non le régulateur du règlement sur l'IA : une signature n'est donc pas notre critère d'entrée. Le Code est l'énoncé public le plus détaillé de ce qu'une bonne pratique représente pour un modèle d'IA à usage général, et un lecteur est fondé à demander comment n'importe quel fournisseur majeur s'y situe. Traiter différemment signataires et non-signataires sur le tableau rendrait par ailleurs les scores incomparables, ce qui est précisément ce qu'un tableau comparatif ne peut pas se permettre.

Ce qui change, c'est l'usage que l'on peut faire du score. Pour un signataire, le Code est la référence qu'il a lui-même choisie, et un écart est un écart au regard de son propre engagement. Pour un non-signataire, le Code est notre référence et non la sienne : le même chiffre décrit la part des mêmes documents publics qu'il a divulguée, mais il ne constitue pas un manquement à un engagement qu'il n'a jamais pris, et il ne peut pas être lu comme une non-conformité à cet engagement. Dans les deux cas, un score n'est pas un constat de conformité juridique ; seul le Bureau de l'IA peut en établir un.

La signature se fait également chapitre par chapitre. Le Code en compte trois, et un fournisseur peut en signer certains et pas d'autres. xAI, par exemple, a signé le chapitre sur la sûreté et la sécurité, mais ni celui sur la transparence ni celui sur le droit d'auteur. Les fournisseurs n'ayant rien signé du tout portent le même astérisque. Le détail par chapitre ne figure pas sur le tableau, car il laisserait entendre que les scores n'ont pas le même sens selon les sections, ce qui n'est pas le cas. La Commission européenne publie la liste à jour des signataires, d'où nous tirons la nôtre.

Pour chaque fournisseur, nous constituons et tenons à jour une bibliothèque complète de ce qu'il a publié : billets de blog, annonces, pages web, cartes système et cartes de modèle, cadres de sûreté et de mise à l'échelle responsable, politiques d'utilisation acceptable, spécifications de modèle, rapports de transparence et documents similaires. Chaque document est collecté, daté et conservé dans un jeu de données ouvert, de sorte que les sources exactes derrière un score peuvent être consultées, téléchargées et reproduites. Pour chaque mesure, nous évaluons au regard du sous-ensemble de types de documents les plus pertinents. Pour 7. Safety and Security Model Reports, par exemple, il s'agit du rapport de modèle (la source principale), ainsi que de la spécification de modèle, du rapport sur les risques systémiques, des rapports d'évaluation internes et externes, des rapports sur les mesures d'atténuation en matière de sûreté et de sécurité, du journal des modifications du cadre et du rapport d'incident grave.

Chaque mesure du Code est décomposée en indicateurs granulaires : de petites vérifications concrètes et objectives qui, ensemble, rendent compte de ce que la mesure demande. Un indicateur vise à être atomique (une seule exigence), rattaché à la clause exacte du Code dont il provient, et assorti d'une indication précisant s'il s'agit d'une exigence vérifiable publiquement ou de quelque chose qui ne peut être évalué que par des canaux privés entre le Bureau de l'IA et le fournisseur. Les indicateurs sont élaborés selon un processus en plusieurs étapes : d'abord proposés au moyen d'un débat structuré de type protocole Delphi, mené sous forme longue entre de grands modèles de langage issus de six fournisseurs différents. Ensuite, chaque clause de chaque indicateur est lue, revue et corrigée manuellement par un expert humain de notre équipe avant d'être utilisée pour l'évaluation.

Nous ne les évaluons pas, et c'est délibéré. Chaque indicateur, et chaque clause qu'il contient, porte une propriété indiquant s'il s'agit de quelque chose que nous pouvons confirmer à partir du domaine public, ou de quelque chose qui ne peut être satisfait que par des canaux privés entre un fournisseur et le Bureau de l'IA. Les clauses de ce second groupe sont mises de côté et entièrement exclues du score. Nous faisons de même pour les clauses qui ne s'appliquent tout simplement pas à un fournisseur donné : de nombreuses exigences sont conditionnelles (par exemple, une clause qui ne s'applique qu'à un modèle que le fournisseur a lui-même classé comme présentant un risque systémique), et lorsque la condition n'est pas remplie, la clause n'est comptée ni en faveur ni en défaveur du fournisseur. Le score d'un fournisseur est donc une moyenne uniforme portant uniquement sur les exigences que nous pouvons réellement vérifier publiquement, de sorte que rien n'est retenu contre un fournisseur pour une exigence non vérifiable publiquement ou qui ne le concerne pas. C'est ainsi que nous restons équitables : nous n'évaluons que ce que nous pouvons voir.

Chaque clause vérifiable publiquement est évaluée par un panel de grands modèles de langage issus de six fournisseurs différents (à code source ouvert comme fermé), au moyen d'une élicitation structurée inspirée du protocole IDEA (Investigate, Discuss, Estimate, Aggregate). Lorsque nous évaluons un fournisseur donné, le modèle de ce fournisseur est exclu de son évaluation afin de tenir compte du biais d'auto-évaluation. Une clause n'est marquée comme satisfaite que lorsque le panel peut citer un extrait textuel des propres documents du fournisseur, vérifié par rapport à la source d'origine. Nous exécutons chaque déroulé du protocole IDEA plusieurs fois afin de tenir compte de la variance entre exécutions, et chaque score est accompagné d'un intervalle de confiance qui reflète la solidité et la cohérence des preuves sous-jacentes. La détermination selon laquelle une clause vérifiable publiquement est satisfaite ou non est ensuite contrôlée par un expert humain familier de l'indicateur : il lit les preuves produites par le protocole IDEA, consulte les cartes système d'origine pour confirmer si le verdict « satisfait » ou « non satisfait » tient, et ratifie le score. Ces verdicts granulaires au niveau des clauses sont agrégés en un score pour l'indicateur, les indicateurs en un score pour la mesure, et ainsi de suite jusqu'au sommet de l'arborescence.

Non. Nous n'appliquons aucune pondération d'importance ou de « matérialité » à des mesures ou à des indicateurs particuliers. Au sein d'une mesure, chaque clause compte de manière égale et le score de la mesure est une moyenne uniforme de ses clauses. Diviser ou fusionner des indicateurs ne peut pas modifier le score : celui-ci reflète ce que le fournisseur a divulgué, et non la manière dont nous avons regroupé les exigences.

Notre objectif est de rester neutres et équitables. Lorsque nous mobilisons une expertise du domaine, c'est pour déterminer ce qu'une divulgation complète devrait contenir, les éléments concrets à rechercher pour chaque exigence, et non pour juger si les pratiques divulguées par un fournisseur sont adéquates ou suffisantes.

Lorsque le Code lui-même rend une exigence non négociable, par son propre vocabulaire (« shall », « must », « before placing on the market »), cette insistance vient du Code, et non de nous. Nous développons une étape distincte, non compensatoire, pour en tenir compte, afin qu'un manquement sur un élément véritablement obligatoire ne puisse pas être simplement compensé par des réussites faciles ailleurs.