Introduction
Les fiches de modèle (model cards) sont devenues une pratique courante pour de bonnes raisons : elles obligent les équipes à consigner par écrit à quoi sert un modèle, sur quelles données il a été entraîné, quelles sont ses limites connues et comment il a été évalué. Cette discipline a de la valeur. Elle est aussi, à elle seule, invérifiable. Une fiche de modèle est un document rédigé par l’organisation même à qui l’on demande de rendre compte du modèle - et, comme tout document autodéclaratif, elle peut être incomplète, obsolète ou tout simplement erronée, sans que le lecteur dispose d’un moyen indépendant de savoir ce qu’il en est.
Ce qu’une fiche de modèle établit réellement
Dans le meilleur des cas, une fiche de modèle est une affirmation bien organisée : voici ce que nous pensons des données d’entraînement, de l’usage prévu et des limites de ce modèle, à la date de rédaction de ce document. Ce n’est pas un justificatif. Elle ne prouve pas que les données d’entraînement décrites sont celles réellement utilisées, que les données n’ont pas changé depuis, ni que les résultats d’évaluation présentés reflètent la version du modèle actuellement en production plutôt qu’une version antérieure, la fiche n’ayant jamais été mise à jour pour en tenir compte. Face à un examen réglementaire de plus en plus poussé - au premier rang duquel les exigences de documentation des articles 10 et 11 de l’AI Act de l’UE - l’écart entre une affirmation bien rédigée et une affirmation démontrable est précisément l’endroit où se concentre le risque de sanction.
Les trois lacunes sur lesquelles les régulateurs apprennent à poser des questions
Premièrement, la mise à jour : cette fiche de modèle a-t-elle été actualisée lorsque le modèle a été réentraîné ou affiné, ou décrit-elle une version antérieure ? Deuxièmement, la vérification de la source : existe-t-il un moyen de confirmer que les données d’entraînement décrites sont bien celles qui ont été utilisées, indépendamment de ce qu’affirme le document lui-même ? Troisièmement, la détection des modifications : si les données d’entraînement sous-jacentes étaient modifiées après la rédaction de la fiche de modèle, quelqu’un - y compris l’équipe qui l’a rédigée - le saurait-il nécessairement ?
La provenance est une couche distincte, pas une meilleure fiche de modèle
Combler ces lacunes ne consiste pas à rédiger des fiches de modèle plus détaillées. Il s’agit d’ajouter, sous la documentation, une couche capable de vérifier de manière indépendante ce que la documentation affirme : l’ancrage cryptographique du jeu de données d’entraînement réellement utilisé, au moment où il est utilisé, afin que l’origine des données et toute modification ultérieure soient démontrables plutôt que simplement décrites. Une fiche de modèle associée à ce type d’enregistrement vérifiable cesse d’être une affirmation à laquelle un auditeur doit faire confiance pour devenir une affirmation qu’un auditeur peut vérifier.
- Les fiches de modèle documentent l’intention et les choix de conception - elles ne sont pas conçues pour prouver quoi que ce soit de manière indépendante
- La valeur probante d’une fiche de modèle se dégrade dès qu’un modèle est réentraîné sans mise à jour correspondante
- L’ancrage cryptographique des données d’entraînement comble l’écart entre ce qu’affirme une fiche de modèle et ce qui peut réellement être vérifié
- Les régulateurs distinguent de plus en plus la documentation de la preuve - les entreprises devraient se préparer à cette distinction dès maintenant, et non après qu’un audit l’a mise au jour
La documentation décrit ce qu’un modèle devrait être. Seule une provenance vérifiable peut prouver ce qu’il est réellement. Découvrez comment ROOTKey ancre les données d’entraînement de l’IA afin que les affirmations de la documentation puissent être vérifiées de manière indépendante.