La plupart des gens ne prendraient pas un médicament sans notice. En tout cas, pas de leur plein gré. On veut savoir à quoi il sert, dans quels cas il vaut mieux ne pas le prendre, quels sont ses effets secondaires connus, quelle est la posologie à respecter et quand il faut consulter un médecin.
En matière de modèles d'IA, les entreprises se montrent étonnamment généreuses.
On intègre un modèle, un fournisseur présente de bons résultats de tests de performance, un service métier constate une amélioration de la productivité, le service informatique vérifie l'intégration, et quelque part dans le projet, on trouve alors une phrase du genre : „ Le modèle a déjà été validé. “
Très bien. Par qui ? Dans quel but ? Avec quelles données ? Dans quelles conditions ? Avec quelles limites ? Pour quels utilisateurs ? Avec quel risque ? Et qui s'en rendra compte si, en fonctionnement, le modèle se comporte différemment de ce qui était prévu ?
C'est précisément là que la « Model Card » entre en jeu.
En bref : Une « Model Card » est une description structurée d’un modèle d’IA. Elle documente l’objectif, la version du modèle, le fournisseur, l’utilisation prévue, la provenance des données, les limites de performance, les risques, l’évaluation, le propriétaire, les autorisations et les conditions de révision. Pour la gouvernance de l’IA, elle ne prend toute sa valeur que lorsqu’elle est associée à l’inventaire des IA, aux cas d’utilisation, à la classification des risques, à l’audit de protection des données, à l’autorisation, au suivi et à la révision. Ailance AI Governance reproduit précisément cette interconnexion sous la forme d’un flux de travail.
Une « Model Card » est, en substance, la notice d'un modèle d'IA. Il ne s'agit pas d'un document marketing. Ce n’est pas non plus une jolie pièce jointe au format PDF destinée au dossier d’audit. Il s’agit plutôt d’une description structurée qui explique à quoi sert un modèle, à quoi il n’est pas adapté, sur quelles données et évaluations il repose, quelles sont ses limites de performance connues, quels sont les risques associés et dans quelles conditions il peut être utilisé.
Le concept initial des « Model Cards » a été proposé dans le cadre de travaux de recherche comme format permettant un rapport transparent sur les modèles. Les « Model Cards » sont destinées à accompagner les modèles et à présenter, entre autres, leur utilisation prévue, leurs caractéristiques de performance, leur évaluation, les contextes d'utilisation pertinents et leurs limites. C'est notamment dans le cas d'applications susceptibles d'avoir un impact sur les personnes que cette Transparence C'est déterminant, car un modèle peut très bien fonctionner dans un contexte donné et poser de sérieux problèmes dans un autre. (arXiv)
Pourquoi les « Model Cards » sont souvent mal comprises dans les entreprises
Dans de nombreuses entreprises, les « Model Cards » sont utilisées comme Documentation traité. Ce n'est pas tout à fait faux. Bien sûr, une « Model Card » sert à documenter. Mais si elle sert uniquement à Documentation Si on ne la comprend pas, on passe à côté de son principal intérêt.
Je constate souvent ce schéma précis dans les projets : il y a un document, tout le monde est soulagé, et pourtant, plus tard, personne ne peut expliquer pourquoi le modèle a été validé exactement sous cette forme. Le problème n’est alors pas que rien n’ait été documenté. Le problème, c’est que le Documentation n'entraîne aucune décision.
On obtient alors un document statique qui, une fois créé, est enregistré dans un dossier de projet et utilisé ultérieurement dans le Audit est mis en avant. On y trouve le modèle utilisé, peut-être le nom du fournisseur, peut-être quelques caractéristiques techniques, peut-être un test de performance. Cela a l'air soigné. Mais cela n'est d'une aide que limitée lorsque les questions cruciales se posent en situation réelle.
En effet, la gouvernance de l'IA n'a pas besoin de Documentation afin de Documentation veut. Elle a besoin d'un contexte exploitable.
Le service juridique doit déterminer si les engagements contractuels, Responsabilité civile, les conditions d'utilisation et les rôles réglementaires adaptés à l'utilisation prévue. Protection des données doit déterminer si données à caractère personnel sont concernés, si Affectation des fonds, Transparence et que les risques pour les personnes concernées aient été correctement évalués. Les services informatiques et de sécurité doivent connaître les dépendances techniques, les interfaces, les flux de données et les mesures de protection pertinents. Le service concerné doit comprendre ce que le modèle permet de faire et dans quels cas il ne doit pas être utilisé à l'aveuglette. En fin de compte, la direction a besoin d'une base décisionnelle, et non d'un mode d'emploi technique.
Une bonne « Model Card » combine ces différents points de vue.
Il ne s'agit donc pas simplement d'une fiche technique. C'est un travail de traduction entre le modèle, le cas d'utilisation, le risque et l'exploitation.
Le nom de l'outil ne veut pas dire grand-chose. C'est le cas d'utilisation qui est déterminant.
Une erreur courante en matière de gouvernance de l'IA consiste à parler des outils comme s'ils constituaient déjà le cas d'utilisation proprement dit.
„ Nous utilisons ChatGPT. “
„ Nous utilisons un modèle de traduction. “
„ Nous utilisons une fonctionnalité d'IA dans notre CRM. “
„ Nous utilisons un modèle de classification. “
C'est un début. Mais ce n'est pas suffisant.
Un même modèle peut s'avérer totalement inoffensif dans un contexte donné et présenter un risque considérable dans un autre. Un modèle qui résume des textes internes ne doit pas être évalué de la même manière qu’un modèle qui présélectionne des candidatures, évalue les interactions avec les clients, structure des informations médicales, calcule les probabilités de fraude ou prépare des avis juridiques.
La différence ne réside pas seulement dans le modèle, mais aussi dans son utilisation, dans les données et dans son impact. Mais aussi dans la question de savoir si c'est vraiment un être humain qui prend la décision ou s'il se contente simplement d'approuver.
C'est pourquoi une « Model Card » doit toujours être associée à un cas d'utilisation. Elle ne se contente pas de décrire les aspects techniques du modèle ; elle doit également expliquer comment celui-ci est utilisé au sein de l'entreprise.
C'est seulement de cette alliance que naît la gouvernance.
Un profil de mannequin isolé indique : „ Ce mannequin sait faire quelque chose. “
Une bonne „ Model Card “ dans le cadre du processus de gouvernance indique : « Ce modèle peut être utilisé dans ce contexte précis et dans ces conditions. »
C'est là toute la différence entre l'espoir et la maîtrise.
Ce qu'une « Model Card » doit pouvoir faire
Modèle de fiche de présentation : les informations minimales à inclure
Une « Model Card » ne doit pas se limiter au nom du modèle et à son fournisseur. Pour qu'elle puisse être exploitée par les services chargés de la gouvernance de l'IA, de la protection des données, des affaires juridiques, de l'informatique, de la sécurité et de la gestion, elle doit respecter une structure minimale claire.
- Nom du modèle, version, fabricant et type de modèle
- cas d'utilisation concret au sein de l'entreprise
- utilisation prévue et utilisations exclues
- responsable technique et responsable Postes
- Sources de données, données d'entrée et données de sortie
- Informations relatives à l'entraînement, aux tests, à l'évaluation ou aux performances connues
- limites connues, types d'erreurs et incertitudes
- Conséquences en matière de protection des données et de sécurité
- Classification des risques et incidence éventuelle de la loi européenne sur l'IA (EU AI Act)
- Exigences en matière de surveillance humaine
- Statut d'autorisation et conditions d'autorisation
- Cycles de révision et éléments déclencheurs d'une nouvelle révision
- Surveillance, incidents et gestion des changements
Cette structure fait d'une « Model Card » bien plus qu'une simple description technique. Elle met en évidence les conditions dans lesquelles un modèle d'IA peut être utilisé de manière responsable au sein de l'entreprise.
Une « Model Card » doit avant tout clarifier l'objectif. Pourquoi ce modèle est-il utilisé ? Quelle tâche remplit-il ? Sert-il à aider une personne, ou influence-t-il concrètement une décision ? Son résultat sert-il uniquement de suggestion, ou donne-t-il lieu à une étape opérationnelle du processus ? Cette distinction est cruciale, car un modèle n’est pas intrinsèquement risqué ou inoffensif. C’est son utilisation concrète qui fait toute la différence.
Il faut ensuite une description claire du modèle et de ses limites. De quel type de modèle s'agit-il ? S'agit-il d'un modèle linguistique génératif, d'un modèle de classification, d'un modèle de scoring, d'un modèle de reconnaissance d'images ou d'une fonctionnalité intégrée du fournisseur ? Quelle version est concernée ? Quelles sont les limitations connues ? Quels types d’erreurs peut-on raisonnablement attendre ? Dans quels cas le modèle produit-il des résultats qui semblent convaincants mais qui sont erronés ? Dans quels cas une vérification humaine est-elle indispensable ?
C'est là que les choses deviennent concrètes : quelles données sont intégrées, lesquelles ont été utilisées pour l'entraînement, l'adaptation, les tests ou l'évaluation, et lesquelles sont générées en cours d'exploitation ? C'est précisément là que la technologie, la protection des données et la sécurité se rejoignent. Une « Model Card » qui ne dit rien sur les données est comme une notice sans indication de principe actif.
La loi européenne sur l'IA montre très clairement pourquoi ces informations ne relèvent pas du domaine académique. Pour les systèmes d'IA à haut risque, elle exige notamment une gestion des risques, une gouvernance des données, des mesures techniques Documentation, obligations de consignation, Transparence, les informations destinées aux opérateurs, la supervision humaine, ainsi que la robustesse, la précision et la cybersécurité. Ces exigences montrent que la gouvernance de l’IA ne peut se limiter à la simple désignation d’un modèle. Elle doit mettre à disposition des informations sur la finalité, le fonctionnement, les risques et le contrôle. (EUR-Lex)
Une fiche technique doit en outre décrire les performances du modèle de manière à ce qu'elles soient exploitables pour l'application concrète. Les valeurs moyennes n'ont qu'une utilité limitée. Un benchmark élevé peut paraître impressionnant tout en étant peu significatif pour votre cas d'utilisation spécifique. Ce qui est déterminant, c'est de savoir si le modèle fonctionne de manière suffisamment fiable dans les conditions dans lesquelles il est destiné à être utilisé au sein de l'entreprise.
C'est précisément là que la « Model Card » pose problème. Elle oblige à décrire non seulement les points forts du modèle, mais aussi ses limites, et c'est une bonne chose.
Car la gouvernance commence là où les frontières deviennent visibles.
Pourquoi les « Model Cards » allient droit, technologie et exploitation
Je pense que de nombreux débats sur l'IA restent insatisfaisants parce que les parties prenantes parlent des langages différents.
La rubrique « Technique » demande : « Comment fonctionne ce modèle ? »
Legal pose la question suivante : qui est responsable et quelles sont les obligations applicables ?
La protection des données pose les questions suivantes : quelles données, à quelles fins, quels risques pour les personnes concernées ?
Security pose la question suivante : quelles sont les vulnérabilités, quels sont les flux de données, quelles sont les mesures de protection ?
Le département pose la question suivante : est-ce utile au quotidien ?
La direction demande : « Pouvons-nous en assumer la responsabilité ? »
Toutes les questions sont légitimes. Mais elles sont toutes incomplètes si elles restent isolées.
La « Model Card » permet de traduire ces différents points de vue dans un langage commun. Elle n’oblige pas tous les intervenants à devenir développeurs. Elle n’oblige pas non plus le service métier à rédiger des avis juridiques. Elle crée un espace où les informations pertinentes sont rassemblées.
C'est là sa véritable valeur.
Une « Model Card » doit donc être rédigée de manière à ce qu'un interlocuteur technique la prenne au sérieux, que le service juridique puisse s'en servir, que le service chargé de la protection des données puisse y repérer les points pertinents et que le service concerné comprenne ce qui est autorisé, risqué ou interdit au quotidien.
Si seuls les data scientists la comprennent, c'est qu'elle est trop technique.
Si seuls les juristes la comprennent, c'est qu'elle est trop abstraite.
Si personne ne s'en sert au travail, ça ne sert qu'à faire joli.
La notice doit être lisible
La métaphore de la notice n'a pas été choisie par hasard.
Une notice n'est pas un travail de recherche pharmaceutique. Elle ne remplace pas l'autorisation de mise sur le marché. Elle ne constitue pas non plus un mode d'emploi destiné au pharmacien. Elle présente les informations pertinentes pour une utilisation en toute sécurité.
C'est exactement ce qu'une « Model Card » est censée faire.
Elle ne doit pas nécessairement contenir tous les détails techniques. Elle doit contenir les informations nécessaires pour responsable Quelles sont les utilisations requises ? En quoi consiste l'utilisation conforme ? Quelles utilisations sont exclues ou présentent un risque ? Quelles sont les données concernées ? Quelles sont les limites connues ? Quel contrôle humain est nécessaire ? Quelles sont les conditions applicables à la validation, au suivi et à la révision ?
La loi européenne sur l'IA (EU AI Act) mentionne expressément, dans le cas des systèmes à haut risque, les informations destinées à permettre aux opérateurs d'utiliser un système de manière correcte et appropriée. Cela inclut notamment les informations relatives à la finalité prévue, aux limitations, aux utilisations abusives prévisibles et à la supervision humaine. Le règlement souligne que ces informations doivent être compréhensibles, exhaustives, accessibles et adaptées aux utilisateurs cibles. (EUR-Lex)
C'est exactement ça.
Une « Model Card » ne doit pas seulement être complète sur le plan formel. Elle doit être comprise au sein de l'entreprise. Sinon, ce n'est pas de la gouvernance, mais de l'archivage.
Les « Model Cards » ne remplacent pas la gouvernance de l'IA
Une « Model Card » ne suffit pas à elle seule à garantir la gouvernance. Tout comme une notice d'utilisation ne suffit pas à elle seule à garantir l'efficacité d'un médicament.
C'est un élément constitutif.
La valeur n'apparaît que lorsque la « Model Card » est intégrée dans un workflow de gouvernance de l'IA. Un cas d'utilisation est décrit. Le concernés Le modèle est identifié. La fiche de modèle fournit le contexte technique, métier et réglementaire. Les services chargés de la protection des données, des affaires juridiques, de la sécurité et du métier procèdent à une vérification sur cette même base. La validation est documentée. Le suivi et la révision sont planifiés. En cas de modification du modèle, du fournisseur, des sources de données, de la finalité ou des conditions d'utilisation, l'évaluation est mise à jour.
On obtient alors Documentation un outil de pilotage.
Fiche de modèle, inventaire IA et DSFA : pourquoi ces éléments vont de pair
Une « Model Card » décrit le modèle. L'« AI Inventory » répertorie les systèmes d'IA, les fonctions d'IA et les cas d'utilisation existant au sein de l'entreprise. Une DSFA, ou évaluation de la protection des données, permet de déterminer si et comment données à caractère personnel sont concernés. Pris isolément, chacun de ces éléments reste incomplet.
C'est cette connexion qui rend la gouvernance de l'IA résiliente.
L'inventaire IA répond à la question suivante : quelles sont les applications d'IA utilisées dans l'entreprise ? La fiche de modèle répond à la question suivante : que savons-nous du modèle, de ses limites, des données, des risques et des conditions d'utilisation ? L'évaluation de la protection des données répond à la question suivante : quelles sont les répercussions de cette utilisation concrète sur données à caractère personnel et Personnes concernées? Le processus de gouvernance répond à la question suivante : qui vérifie, qui décide, qui consigne et quand une nouvelle évaluation a-t-elle lieu ?
Ailance AI Governance rassemble ces éléments au sein d'une structure commune. Les « Model Cards » n'y figurent pas isolément aux côtés des cas d'utilisation, des risques et des validations, mais s'inscrivent dans un processus décisionnel traçable.
| Élément | Question principale | Implications pour la gouvernance de l'IA |
|---|---|---|
| Inventaire IA | Quels sont les systèmes d'IA, les fonctionnalités d'IA et les cas d'utilisation existants ? | Permet d'avoir une vue d'ensemble de l'utilisation de l'IA au sein de l'entreprise. |
| Carte modèle | Quelles sont les capacités de ce modèle, quelles sont ses limites, quelles sont ses sources de données et quels sont les risques ? | Fournit un contexte de modélisation pour l'évaluation et la validation. |
| DSFA/DPIA | Sont données à caractère personnel ou exposés à des risques liés à cette situation ? | Évalue les risques liés à la protection des données et les mesures à prendre. |
| Classification des risques | Quel est le niveau de risque réglementaire et opérationnel ? | Gère les tâches de contrôle, les validations et la remontée des problèmes. |
| processus de validation | Qui est habilité à autoriser l'intervention et dans quelles conditions ? | Permet de rendre les décisions compréhensibles. |
| Évaluation et suivi | Quand faut-il mettre à jour l'évaluation ? | Évite les autorisations obsolètes et le faux sentiment de sécurité. |
Le cadre de gestion des risques liés à l'IA du NIST est utile à cet égard, car il ne considère pas les risques liés à l'IA comme un simple point de contrôle ponctuel, mais comme un enjeu qui doit être pris en compte dès la conception, le développement, l'utilisation et l'évaluation des systèmes d'IA. Le NIST décrit ce cadre comme un outil facultatif destiné à aider les organisations à intégrer des aspects liés à la fiabilité dans leurs produits, services et systèmes d’IA. (NIST)
La norme ISO/IEC 42001 va également dans ce sens. Elle décrit un système de gestion de l'IA comme un ensemble d'éléments interdépendants permettant à une organisation de définir des politiques, des objectifs et des processus pour responsable Le développement, le déploiement ou l'utilisation de systèmes d'IA sont définis, mis en œuvre, maintenus et améliorés. Il en ressort clairement que la gouvernance de l'IA nécessite des processus. Une « Model Card » prend toute sa valeur lorsqu'elle s'intègre à ce système de gestion. (ISO)
Une mauvaise « Model Card » est dangereusement rassurante
Il y a un problème que je constate régulièrement dans le domaine de la gouvernance : une mauvaise Documentation rassuré.
On a quelque chose. Du coup, on se sent mieux.
Une « Model Card » peut renforcer cet effet. Si elle ne contient que des affirmations générales, si les risques sont formulés de manière vague, s'il manque un cas d'utilisation concret, si les sources de données restent floues, si l'évaluation n'est pas adaptée à l'utilisation prévue ou si les autorisations ne sont pas assorties de conditions, cela crée un faux sentiment de sécurité.
C'est plus dangereux que de ne pas avoir de « Model Card » du tout.
Car sans « Model Card », on se rend tout de même compte qu'il manque quelque chose. Avec une mauvaise « Model Card », on a l'impression que le sujet est réglé.
Une fiche de modèle utile doit donc être suffisamment précise pour permettre de prendre des décisions. Elle ne doit pas se contenter d'indiquer qu'un modèle est „ adapté au traitement de texte “. Elle doit préciser pour quel traitement de texte, par quels utilisateurs, avec quelles données, dans quelles conditions et avec quelles obligations de contrôle. Elle ne doit pas se contenter d’indiquer que les risques sont „ faibles “. Elle doit expliquer pourquoi, en se référant à quel cas d’utilisation et avec quelles incertitudes résiduelles.
La gouvernance ne repose pas sur des formules agréables. Elle repose sur des distinctions solides.
Ce qu'une fiche de mannequin doit absolument contenir
Une bonne fiche technique commence par le modèle lui-même : nom, version, fournisseur, type de modèle et contexte technique. Il faut ensuite décrire clairement l'utilisation prévue. Non pas sous la forme d'une description marketing, mais en termes de logique d'utilisation concrète au sein de l'entreprise.
Viennent ensuite les données et l'évaluation. Quelles données le modèle utilise-t-il ? Quelles données ont été utilisées pour l'entraînement, l'ajustement, les tests ou l'évaluation, dans la mesure où cela est connu ou pertinent ? Quelles données l'entreprise traite-t-elle dans ce cas d'utilisation concret ? S'agit-il de données à caractère personnel concernés ? Existe-t-il des catégories particulières, Données sur l'emploi, des données clients ou des données relatives à des groupes particulièrement vulnérables ?
Il faut ensuite fournir des informations sur les performances et les limites du modèle. Dans quels cas le modèle fonctionne-t-il de manière fiable ? Dans quels cas ne fonctionne-t-il pas ? Quels sont les types d'erreurs connus ? Quel contrôle humain est nécessaire ? Quelles utilisations sont exclues ? Quelles hypothèses ont été retenues lors de l'évaluation ?
Vient ensuite la partie consacrée à la gouvernance. Qui en est le responsable technique ? Qui a procédé à la vérification ? Quels risques ont été évalués ? Quelle autorisation a été accordée ? Sous quelles conditions le modèle peut-il être utilisé ? Quand doit-il faire l'objet d'une nouvelle vérification ? Quels indicateurs, incidents ou changements déclenchent une révision ?
Cela semble très complet. Mais c'est précisément le contexte dont on aura besoin plus tard, lorsqu'un auditeur, un client, un Autorité de surveillance, lorsqu'un membre du comité de direction ou d'un service demande : « Pourquoi avons-nous le droit d'utiliser ce modèle de cette manière ? »
Une bonne « Model Card » ne répond pas à elle seule de manière exhaustive à cette question. Mais elle évite d'avoir à reconstituer la réponse à partir de dix e-mails, de trois réunions et d'un rappel.
| Une « Model Card » comme décoration | La « Model Card » comme outil de gouvernance |
|---|---|
| Il est créé une seule fois, puis archivé. | Sera intégré au workflow de gouvernance de l'IA. |
| Décrit le modèle de manière générale. | Relie le modèle, le cas d'utilisation et les conditions d'utilisation. |
| Contient des informations techniques sans incidence sur la prise de décision. | Fournit un contexte pour la protection des données, les aspects juridiques, la sécurité, les services spécialisés et la direction. |
| Les risques sont formulés en termes généraux. | Les risques sont évalués en fonction des cas d'utilisation. |
| La validation et la révision ne font pas partie du document. | La validation, les conditions, le responsable et la révision font partie du processus de contrôle. |
| Aide à Audit de manière limitée. | Fournit des bases décisionnelles transparentes. |
Comment Ailance intègre les fiches de modèles dans la gouvernance de l'IA
C'est précisément là qu'intervient Ailance AI Governance. Une « Model Card » ne se situe pas isolément par rapport à l'« AI Inventory », ni par rapport au « Use Case ». Elle s'inscrit dans une structure de gouvernance commune.
L'inventaire de l'IA permet de visualiser les systèmes d'IA, les fonctionnalités d'IA et les cas d'utilisation existant au sein de l'entreprise. Le cas d'utilisation décrit l'application concrète. La « Model Card » fournit le contexte métier, technique et réglementaire du modèle. Les sources de données, les fournisseurs, les risques, les autorisations, les rôles, les règles et les cycles de révision sont regroupés au sein d'un même système.
Cela permet de créer un « point unique de vérité » fiable pour la gouvernance de l'IA.
C'est là la logique fondamentale d'Ailance : les exigences réglementaires sont traduites en processus, rôles, responsabilités, validations, justificatifs et flux de travail. Pour la gouvernance de l'IA, cela signifie qu'un modèle n'est pas simplement documenté : il est intégré dans un processus décisionnel.
Ailance permet de relier les « Model Cards » à des cas d'utilisation, de les associer à une classification des risques, de déclencher des contrôles de protection des données et de sécurité, de documenter les validations et de modéliser les cycles de révision. La « Model Card » ne devient ainsi pas une simple annexe, mais un véritable outil de travail.
C'est particulièrement important, car les entreprises ne font pas faillite à cause d'un nombre trop important de documents isolés. Elles échouent parce que les informations ne sont pas regroupées. Le modèle relève du domaine technique, les sources de données sont gérées par le service informatique ou les services métier, le service de protection des données procède à une évaluation séparée, le service juridique examine le prestataire, le service de sécurité s'occupe des interfaces, et la direction reçoit finalement un dossier de décision.
Une « Model Card » dans Ailance a pour but de rassembler ces différentes perspectives. Non pas comme une formalité administrative, mais comme une base de décision.
Pourquoi les « Model Cards » gagnent également en importance pour les LLM
Avec les modèles classiques d'apprentissage automatique, les applications étaient souvent plus restreintes. Un modèle classe, reconnaît, évalue ou prédit dans le cadre d'un processus spécifique. Avec les LLM, cela devient plus complexe, car les applications sont plus variées. Un modèle linguistique peut résumer des textes, rédiger des e-mails, analyser des contrats, préparer des réponses d'assistance, extraire des données, écrire du code ou influencer indirectement les décisions au sein d'un processus métier.
Le modèle reste le même, mais le cas d'utilisation modifie le risque.
C'est précisément pour cette raison que les LLM ont besoin non pas de moins, mais de plus de contexte. Quel est le contexte de la requête utilisée ? Quelles données sont saisies ? Quels résultats sont utilisés ? Y a-t-il un contrôle humain ? Les résultats font-ils l'objet d'un traitement automatisé ? Est-ce que données à caractère personnel traitées ? Des informations confidentielles peuvent-elles se retrouver dans les environnements des prestataires ? Les résultats constituent-ils uniquement un soutien ou une base factuelle pour la prise de décision ?
Une « Model Card » destinée aux applications basées sur des LLM ne doit donc pas se contenter de décrire le modèle. Elle doit être associée au cas d'utilisation, à la source de données et au flux de travail.
Sinon, on décrit le médicament, mais pas la posologie.
Quand faut-il mettre à jour une « Model Card » ?
Une « Model Card » n'est pas un produit à usage unique. Elle doit rester vivante.
Elle doit être mise à jour en cas de modification de la version du modèle, du fournisseur, de l'objectif, des sources de données, du groupe d'utilisateurs, du mode d'intégration, de l'évaluation des risques ou des conditions d'autorisation. Elle doit également être réexaminée en cas d’incidents, lorsque les performances en exploitation diminuent, lorsque de nouvelles exigences réglementaires deviennent applicables ou lorsque le cas d’utilisation passe d’une phase de test à une utilisation en production.
La loi européenne sur l'IA (EU AI Act) considère expressément la gestion des risques liés aux systèmes à haut risque comme un processus continu et itératif s'étendant sur l'ensemble du cycle de vie du système. Cela inclut l'examen, la mise à jour ainsi que Documentation des décisions et mesures essentielles. (EUR-Lex)
C'est là que de nombreuses entreprises doivent redoubler d'efforts.
La gouvernance de l'IA n'est pas un instantané. Une autorisation est une décision prise dans des conditions données. Si ces conditions changent, la base de décision doit également être adaptée.
Conclusion
Les « Model Cards » ne sont pas de simples éléments décoratifs. Ce sont les notices d'utilisation de votre IA.
Quiconque utilise un modèle d'IA sans en décrire clairement l'objectif, les limites, les données, les risques, les autorisations et les conditions de révision ne dispose pas d'une gouvernance solide. Il se fie aux bonnes intentions. Cela peut bien se passer. Mais ce n'est tout simplement pas un système.
Une bonne « Model Card » ne garantit pas automatiquement la sécurité de l'IA. Mais elle met en évidence les points sur lesquels il faut prendre des décisions. Elle fait le lien entre les services techniques, juridiques, de protection des données, de sécurité, les services métier et les opérations. Elle traduit les informations relatives aux modèles sous une forme exploitable par les entreprises.
C'est précisément là que réside leur valeur.
Ni au format PDF. Ni comme simple élément décoratif pour un audit. Ni comme fiche technique.
Mais dans le cadre d'un processus de gouvernance de l'IA qui fait de l'utilisation de l'IA un processus d'entreprise responsable.
Ou, pour le dire plus simplement : existe-t-il une notice d'utilisation compréhensible pour vos principaux modèles d'IA ?
Questions et réponses
Qu'est-ce qu'une « Model Card » ?
Une « Model Card » est une description structurée d'un modèle d'IA ou d'apprentissage automatique. Elle précise notamment l'objectif, l'usage prévu, les performances, les sources de données, les limites, les risques, l'évaluation et les conditions d'utilisation. À l'origine, ce concept a été proposé comme format permettant un rapport transparent sur les modèles. (arXiv)
Pourquoi une « Model Card » est-elle importante pour la gouvernance de l'IA ?
Une « Model Card » fournit le contexte dont les services juridiques, de protection des données, informatiques, de sécurité, les services métier et la direction ont besoin pour utiliser un modèle d'IA de manière responsable. Elle met en évidence l'usage prévu d'un modèle, ses limites, les données concernées, les risques encourus et les conditions dans lesquelles il peut être validé.
Une « Model Card » est-elle uniquement une documentation technique ?
Non. Une « Model Card » contient des informations techniques, mais ne doit pas être considérée uniquement comme un document destiné aux développeurs. Son intérêt réside dans le fait qu’elle rassemble des informations techniques, juridiques, relatives à la protection des données et opérationnelles de manière à constituer une base décisionnelle solide.
Que doit contenir une fiche de mannequin ?
Une « Model Card » doit contenir le nom du modèle, sa version, son fournisseur, son type, l'usage prévu, les utilisations exclues, les sources de données, l'évaluation, les limites de performance, les risques connus, le contrôle humain, le responsable technique, le statut de validation et les conditions de révision. Son contenu précis dépend du cas d'utilisation concret et des risques associés.
Quel rôle joue la « Model Card » dans la loi européenne sur l'IA ?
La loi européenne sur l'IA (EU AI Act) exige, pour certains systèmes d'IA, en particulier les systèmes à haut risque, des informations détaillées sur la gestion des risques, les aspects techniques Documentation, Transparence, contrôle humain, journalisation, qualité des données, précision, robustesse et cybersécurité. Une « Model Card » peut aider à présenter les informations pertinentes de manière structurée, mais ne remplace pas automatiquement l'ensemble des exigences légales Documentation. (EUR-Lex)
Quelle est la différence entre « AI Inventory » et « Model Card » ?
L'inventaire de l'IA répertorie les systèmes d'IA, les fonctionnalités d'IA et les cas d'utilisation présents dans l'entreprise. La « Model Card » décrit le modèle ou le composant de modèle sous-jacent : objectif, caractéristiques, limites, risques, données et conditions d'utilisation. Pour assurer la gouvernance de l'IA, ces deux éléments doivent être reliés entre eux.
Pourquoi une « Model Card » ne suffit-elle pas à elle seule ?
Une « Model Card » n'est qu'un élément parmi d'autres. Sans workflow, validation, évaluation des risques, contrôle de la protection des données, suivi et révision, elle reste Documentation. Ce n'est qu'une fois intégrée dans un processus de gouvernance de l'IA qu'elle devient un outil de pilotage.
Comment Ailance prend-elle en charge les Model Cards ?
Ailance relie les « Model Cards » à l'inventaire des IA, aux cas d'utilisation, aux sources de données, aux fournisseurs, aux évaluations des risques, aux autorisations, aux rôles et aux processus de révision. Il en résulte un cadre de gouvernance centralisé permettant une utilisation contrôlée et traçable de l'IA au sein de l'entreprise.
Quel logiciel prend en charge les « Model Cards » dans le cadre de la gouvernance de l'IA ?
Un logiciel dédié aux fiches de modèle doit offrir davantage qu’un simple formulaire statique. Il est essentiel que ces fiches soient reliées à l’inventaire IA, aux cas d’utilisation, aux sources de données, aux risques, aux validations, aux rôles, aux justificatifs et aux processus de révision. Ailance AI Governance prend précisément en charge cette interconnexion et intègre les fiches de modèle au flux de travail opérationnel de gouvernance.
Comment Ailance relie-t-il les fiches de modèle à l'inventaire IA et aux processus liés à la loi européenne sur l'IA ?
Ailance relie les fiches de modèles à l'inventaire des IA, aux cas d'utilisation, à la classification des risques, aux contrôles de protection des données et de sécurité, aux autorisations, aux rôles et aux cycles de révision. Cela permet aux entreprises de documenter quel modèle d'IA est utilisé dans quel contexte, quels sont les risques encourus, qui a pris la décision et quand un nouvel examen est nécessaire.
Chaque modèle d'IA a-t-il besoin d'une « Model Card » ?
Tous les modèles d'IA ne nécessitent pas le même niveau de Documentation. Un processus interne aux risques faibles nécessite moins de détails qu’un système d’IA impliquant des personnes, ayant un impact sur la prise de décision ou susceptible d’être concerné par la loi européenne sur l’IA. Néanmoins, chaque modèle d’IA pertinent au sein de l’entreprise devrait au moins être décrit de manière à ce que sa finalité, les données utilisées, ses limites, la responsabilité et ses conditions d’utilisation soient compréhensibles.
Quand faut-il mettre à jour une « Model Card » ?
Une « Model Card » doit être mise à jour en cas de modification de la version du modèle, du fournisseur, de l'objectif, des sources de données, du groupe d'utilisateurs, de l'intégration, des risques, des autorisations ou des conditions d'utilisation. Des incidents, des changements de performances ou de nouvelles exigences réglementaires peuvent également nécessiter une mise à jour.
Comment reconnaître une mauvaise « Model Card » ?
Une mauvaise « Model Card » reste générale. Elle mentionne le nom du modèle, mais passe sous silence ses limites d'utilisation, les sources des données, les risques, l'évaluation, les responsabilités et les conditions de révision. Elle rassure sur le plan formel, mais n'aide guère à la prise de décision. Une bonne « Model Card » met en évidence les incertitudes et jette les bases d'une utilisation responsable.
German 
English 
Italian 
French