Que doit contenir une fiche de modèle pour la gouvernance de l'IA ?

Réponse succincte

Une « Model Card » dédiée à la gouvernance de l’IA ne doit pas seulement décrire le modèle d’IA utilisé, mais également documenter de manière structurée l’usage qui en est fait, la version déployée, l’identité du fournisseur ou de l’exploitant, les sources de données utilisées, les informations relatives aux performances, de biais et de risques, quelles sont les limitations connues, comment le modèle est lié à un cas d’utilisation concret de l’IA, quelles autorisations ont été accordées et quand le prochain contrôle est nécessaire.

Pour qu'une « Model Card » reste fiable même en cours d'exploitation, elle ne doit pas être considérée comme une simple pièce jointe PDF statique. Dès que la version du modèle, la source de données, le fournisseur, l'objectif, les indicateurs ou l'évaluation des risques changent, la « Model Card » doit également être mise à jour, vérifiée et versionnée.

Pourquoi il faut continuer à utiliser une « Model Card » après la mise en service

Dans de nombreuses organisations, les fiches de modèle sont encore considérées comme une annexe documentaire, créée une seule fois puis archivée. Souvent, ce type de document contient quelques informations techniques sur le modèle, des détails concernant les données d’entraînement, des indicateurs ou des limitations connues, ainsi qu’un lien vers la Documentation du fournisseur. Cependant, dès que le cas d'utilisation de l'IA est mis en production, ce sont précisément ces fondements sur lesquels reposait la Documentation repose sur.

• Le modèle est en cours de mise à jour.
• Le fournisseur lance une nouvelle version.
• Une source de données est ajoutée.
• Le département utilise les résultats d'une manière différente de celle décrite initialement.
• De nouveaux risques sont identifiés.
• Un indicateur de performance évolue.
• Une remarque relative au suivi reste en suspens.
• Une condition d'autorisation arrive à expiration.

Si la « Model Card » ne tient pas compte de ces modifications, elle ne reflète plus la réalité du modèle en production, mais uniquement un état antérieur. Ce qui importe donc, ce n’est pas de savoir si une Model Card a été créée à un moment donné, mais si son contenu correspond toujours à l’utilisation effective du modèle. En l’absence de cette concordance, un problème de gouvernance survient, car les contrôles, les validations et les responsabilités peuvent reposer sur des bases obsolètes.

Pourquoi il faut envisager les « Model Cards » sous un autre angle dans le cadre de la gouvernance de l'IA

La gouvernance de l'IA ne consiste pas seulement à décrire un modèle sur le plan technique, mais aussi à rendre son utilisation au sein de l'entreprise contrôlable, vérifiable et responsable. Un document statique ne suffit pas à cet effet, car un modèle peut être utilisé dans plusieurs cas d’utilisation, un même fournisseur peut proposer différentes versions d’un modèle, un outil d’IA peut utiliser plusieurs modèles, et l’évaluation des risques varie considérablement en fonction de l’objectif, de la source des données ou de l’influence sur la prise de décision.

Une « Model Card » doit donc être considérée, au sein d’une plateforme de gouvernance de l’IA, comme un objet opérationnel dynamique qui relie entre eux le modèle, le fournisseur, les données, le cas d’utilisation, le risque, la validation, la surveillance et la révision. Ce n’est qu’à travers cette interconnexion qu’une description technique devient un élément à part entière du processus de gouvernance en cours.

Le problème de la compréhension des fichiers PDF

Un fichier PDF peut s'avérer tout à fait utile pour une exportation, un contrôle, une justification auprès de clients, d'auditeurs ou d'instances internes, ou encore comme instantané. En tant que modèle opérationnel, il ne présente toutefois qu’un intérêt limité, car un document statique ne permet pas de déterminer automatiquement si la version documentée est toujours active, si un cas d’utilisation accède désormais à une autre source de données, si une révision est devenue nécessaire, si une validation correspond toujours à la version actuelle du modèle ou si des risques et des mesures restent en suspens.

De même, un fichier PDF ne permet pas de distinguer de manière fiable une version historique d’une version productive, ni d’indiquer qui a vérifié la dernière modification. La question centrale n’est donc pas : „ Disposons-nous d’une Model Card sous forme de document ? “, mais : „ La Model Card est-elle mise à jour dans le cadre du processus continu de gouvernance de l’IA ? “

Ce qu'une « Model Card » doit pouvoir faire

Dans le cadre de la gouvernance de l'IA, une « Model Card » devrait remplir au moins cinq fonctions qui vont au-delà d'une simple description du modèle.

1. Description structurée du modèle : Elle répertorie le nom, la version, le fournisseur, le type de modèle, la finalité, les limites d'utilisation et les informations techniques de base.
2. Lien avec des cas d'utilisation concrets de l'IA : Elle établit un lien avec l'utilisation réelle, car un risque lié au modèle ne peut être évalué de manière pertinente que dans le contexte concret de son utilisation.
3. Documentation Nombre d'avis : Elle évalue notamment les performances, les biais, l'explicabilité, la robustesse, Protection des données, sécurité de l'information et restrictions connues.
4. Aide à la prise de décision : Elle permet d'associer les validations à une version spécifique du modèle et à un cas d'utilisation précis.
5. Actualités de l'entreprise : Elle permet de retracer les modifications apportées à la version, à la source de données, au fournisseur, à l'objectif, aux indicateurs ou au risque.

Ces fonctionnalités font d'une Model Card une documentation opérationnelle qui non seulement décrit l'état actuel, mais peut également être intégrée dans les processus de vérification, de validation et de révision.

Quels sont les champs réellement nécessaires ?

Une bonne « Model Card » ne doit pas être composée principalement de texte libre, mais comporter des champs structurés afin que les informations puissent être vérifiées, filtrées, intégrées dans des rapports et mises à jour. Les champs requis dépendent du modèle de gouvernance concerné ; toutefois, les domaines suivants en font généralement partie.

Identité du modèle

• Nom du modèle
• ID interne du modèle
• Version du modèle
• Type de modèle
• Fournisseur
• exploitant
• Modèle d'hébergement ou de mise à disposition
• Statut
• Valable à partir du
• dernière modification
• Prochaine critique

Contexte d'utilisation

• cas d'utilisation de l'IA connexes
• Objectif de la mission
• concernés Processus métier
• Groupes d'utilisateurs
• Type de sortie
• influence sur la décision
• contrôle humain
• Limites d'utilisation
• utilisations non autorisées

Données et sources des données

• Données d'entraînement, dans la mesure où elles sont connues
• Données d'entrée dans le cas d'utilisation concret
• sources de données connectées
• données à caractère personnel
• catégories particulières de données à caractère personnel
• données confidentielles de l'entreprise
• Origine des données
• Qualité des données
• Actualité des données
• Flux de données et emplacements de stockage

Performances et indicateurs

• indicateurs de performance pertinents
• Date du test
• Environnement de test
• ensemble de données de test
• écarts connus
• Taux d'erreur
• Seuils
• Résultats du suivi
• Comparaison avec la version précédente

Biais, impartialité et explicabilité

• risques de biais connus
• groupes ou scénarios testés
• Évaluations de l'équité
• approche de l'explicabilité
• Les limites de l'explicabilité
• modèles d'erreurs courants
• évaluation humaine nécessaire

Risques et contrôles

• Classification des risques
• Risques liés à la protection des données
• Risques liés à la sécurité
• risques juridiques
• risques opérationnels
• Risques de réputation
• Mesures de contrôle
• mesures en cours
• risque résiduel
• Acceptation des risques

Fournisseurs et achats auprès de tiers

• fournisseur
• Base contractuelle
• Documentation du fournisseur
• Sous-traitants ou tiers concernés
• Lieux de stockage et de traitement
• Informations relatives à l'assistance et aux modifications
• SLA ou informations opérationnelles
• Obligations d'information en cas de modifications apportées au modèle

Validation et gouvernance

• Propriétaire
• Propriétaire du modèle
• Responsable du cas d'utilisation
• Rédacteur
• DPO / Audit de protection des données
• Vérification juridique
• Revue de la sécurité informatique
• Validation par le département
• Validation par la direction, si nécessaire
• Date de sortie
• Conditions d'autorisation
• Fréquence de révision

Modifications et gestion des versions

• Historique des modifications
• Valeurs « avant » et « après »
• Motif de la modification
• personne ou fonction à l'origine de l'événement
• concernés Cas d'utilisation
• nouvelles validations requises
• versions antérieures
• état actuel de la production

La liste est exhaustive, mais ce n'est pas une fin en soi. Une « Model Card » n'est pas une simple page de garde, mais un objet opérationnel qui rassemble les informations pertinentes pour la gouvernance de manière à ce qu'elles restent traçables et exploitables dans le cadre de l'exploitation courante.

Pourquoi le cas d'utilisation est déterminant

Un modèle en soi ne donne que peu d'indications sur le risque réel, car ce même modèle linguistique peut, par exemple, être utilisé pour des projets de textes internes ou pour l'évaluation préliminaire de réclamations, de candidatures, de demandes de clients ou de cas à risque. Bien que le modèle technique soit identique ou similaire, les exigences en matière de gouvernance varient considérablement selon l'utilisation qui en est faite.

C'est pourquoi une « Model Card » doit toujours être associée au cas d'utilisation concret pour lequel il est pertinent de savoir avec quelles données le modèle fonctionne, quel résultat il génère, quelle influence ce résultat a sur les décisions et qui en est responsable. Sans ce lien, la « Model Card » reste purement technique ; ce n'est qu'à travers son contexte d'utilisation qu'elle devient apte à la gouvernance.

Les versions des modèles ne sont pas une simple note en marge

De nombreuses organisations sous-estiment l'importance des versions bêta, alors qu'une nouvelle version peut déjà avoir des répercussions techniques significatives. Elle peut améliorer la qualité des réponses, mais aussi générer de nouveaux types d'erreurs, interpréter différemment les invites existantes, nécessiter d'autres seuils ou comporter de nouveaux mécanismes de sécurité. Même les fournisseurs—Documentation, les autorisations, les informations clients ou les directives internes peuvent être concernées.

Une fiche de modèle fiable doit donc non seulement mentionner le nom du modèle, mais aussi documenter la version en production et son historique des modifications. En cas d’audits, d’incidents ou de décisions de gestion ultérieures, il doit être possible de retracer quelle version a été vérifiée et validée, quelle version était en production, quels cas d’utilisation en dépendaient et quelle modification a déclenché une nouvelle révision.

Les sources de données modifient le risque

Une « Model Card » doit non seulement décrire le modèle, mais aussi refléter la réalité des données propres à chaque cas d'utilisation concret, car un même type de modèle peut être évalué de manière totalement différente selon les données traitées. Il est donc notamment important de déterminer s'il s'agit d'informations publiques sur les produits, de données clients, Données relatives aux salariés, si des catégories particulières de données à caractère personnel ou des informations confidentielles de l'entreprise sont traitées, si la « Retrieval-Augmented Generation » est utilisée, quels systèmes internes sont connectés et si les données sont utilisées à des fins d'entraînement ou de réglage fin, ou si elles sont stockées chez le prestataire.

Si une source de données change, l'évaluation des risques peut également s'en trouver modifiée. C'est pourquoi il convient de déterminer qui est chargé de mettre à jour la « Model Card » dans ce cas et qui vérifie si cette modification nécessite un nouvel examen ou une nouvelle validation.

Les informations relatives aux fournisseurs doivent être mises à jour

De nombreux systèmes d'IA s'appuient sur des modèles externes, des plateformes, des API ou des fonctionnalités d'IA intégrées ; c'est pourquoi les informations relatives au fournisseur doivent également figurer dans la « Model Card ». Il s'agit notamment du fournisseur, de la base contractuelle, des spécifications techniques Documentation, version utilisée, informations sur les modifications, Transmission de données, les lieux de stockage, les informations relatives à la sécurité et à la protection des données, les sous-traitants concernés, ainsi que les informations relatives à l'exploitation et à la disponibilité.

Étant donné que les fournisseurs peuvent modifier les modèles, les fonctionnalités, les conditions d'utilisation, les options de traitement des données, la documentation relative à la sécurité ou les interfaces, ces informations doivent également être mises à jour. Dans le cas contraire, la « Model Card » perd de sa pertinence, car les conditions générales documentées ne correspondent plus au service réellement utilisé.

Les performances n'ont d'importance que si elles correspondent au cas d'utilisation

Les fiches de modèle contiennent souvent des indicateurs tels que la précision, l'exactitude, le rappel, le score F1, le taux d'erreur, la robustesse, le taux d'hallucination, ainsi que les faux positifs ou les faux négatifs. Ces indicateurs ne sont toutefois pertinents que si l'on sait clairement à quoi ils se rapportent, car un benchmark global établi par le fabricant ne constitue pas automatiquement une preuve fiable de l'utilisation concrète au sein de l'entreprise.

Pour la gouvernance, il est donc essentiel de déterminer quel indicateur est pertinent pour chaque cas d'utilisation, sur quel ensemble de données de test et dans quel environnement la mesure a été effectuée, quelles sont les valeurs seuils applicables, quelles erreurs sont critiques, qui évalue les résultats et quelles mesures sont déclenchées lorsque la performance tombe en dessous d'un seuil défini. Il convient également de documenter si et comment les performances continuent d’être surveillées après la mise en service.

Les questions de partialité et d'impartialité n'ont pas leur place dans une note de bas de page

Dans de nombreuses applications d'IA, le biais n'est pas un sujet théorique, mais une question concrète de gouvernance, car certains groupes peuvent être systématiquement défavorisés, les données d'entraînement ou d'entrée peuvent être déséquilibrées, ou encore les résultats peuvent s'avérer moins bons pour certains groupes cibles. Une « Model Card » doit donc recenser les risques de biais connus, les groupes ou scénarios testés, les limites des tests, les mesures de protection prévues et les cas dans lesquels une vérification humaine reste nécessaire.

Cette évaluation n'est pas non plus valable à long terme. Si les sources de données, les versions du modèle, les seuils ou le contexte d'utilisation changent, il convient de vérifier si l'évaluation antérieure en matière de biais et d'équité reste valable.

L'explicabilité dépend du contexte

Tous les cas d’utilisation de l’IA ne nécessitent pas le même type d’explicabilité. Les exigences sont différentes selon qu’il s’agit d’un outil interne de synthèse ou d’un système qui hiérarchise les risques, prépare des décisions ou traite les personnes de manière différente. Une „ Model Card “ ne devrait donc pas se contenter d'indiquer si un modèle est « explicable », mais décrire le type d'explication disponible, à qui elle est destinée, comment la plausibilité des résultats est vérifiée, quelles sont ses limites et quel contrôle humain est prévu.

L'explicabilité n'est donc pas une simple case à cocher isolée, mais un élément du modèle opérationnel qui doit être adapté à l'utilisation concrète et à l'influence potentielle sur les décisions.

La validation doit être liée à une version spécifique

Une validation n'est fiable que si l'on peut déterminer clairement à quelle version elle se rapporte. Si un cas d'utilisation de l'IA est vérifié et validé sur la base d'une « Model Card » spécifique, la version du modèle, les sources de données, l'évaluation des risques et les conditions de validation doivent pouvoir être clairement associées à celle-ci.

En cas de modifications importantes, telles qu’une nouvelle version du modèle, un nouveau fournisseur, une source de données supplémentaire, un changement d’objectif, un autre groupe d’utilisateurs, une modification du résultat, de nouvelles mentions de biais ou des mesures de sécurité et de protection des données en cours d’élaboration, il convient ensuite de vérifier si l’autorisation existante reste valable ou si un nouvel examen est nécessaire. La « Model Card » doit donc être intégrée au processus de validation et ne pas servir uniquement d’annexe.

Révisions et resoumissions

Une « Model Card » ne conserve sa fiabilité que si elle fait l'objet d'un contrôle régulier ; c'est pourquoi il doit être possible de retracer la date de la dernière vérification, l'identité de la personne qui l'a effectuée, les modifications constatées, les mesures qui en ont découlé et la date prévue pour la prochaine vérification. La logique du processus concernant les vérifications en retard, les rappels et les escalades revêt une importance tout aussi grande.

De nombreux processus de gouvernance de l'IA échouent dès la première étape Documentation, mais au fait qu'après la mise en production, aucune responsabilité claire n'est définie pour la maintenance courante. C'est pourquoi une « Model Card » doit avoir un responsable clairement désigné, une date de révision et une logique d'escalade bien définie.

Ce que les auditeurs et les appels d'offres veulent vraiment savoir

Les appels d'offres demandent souvent si les « Model Cards » sont prises en charge, bien que cette question, à elle seule, ne donne guère d'indication sur la solidité réelle du processus de gouvernance. Il est plus pertinent de savoir si les « Model Cards » sont des objets structurés, s’ils peuvent être associés à des cas d’utilisation concrets, s’ils prennent en charge la gestion des versions et les révisions, s’ils permettent de représenter les validations en fonction des versions et si les modifications apportées aux versions du modèle ou aux sources de données peuvent déclencher de nouveaux contrôles.

Il est tout aussi important de savoir si les informations relatives aux fournisseurs sont mises à jour, si les biais, les performances et les risques peuvent être documentés de manière structurée, si des délais de révision et des rappels sont prévus, si l'historique reste traçable à la date de l'audit et si les mesures en cours sont associées à la « Model Card ». Ce sont ces questions qui distinguent une gouvernance opérationnelle de l’IA d’un simple système d’archivage de documents.

La « Model Card » en tant qu'objet opérationnel dans Ailance AI Governance

Dans une plateforme de gouvernance de l'IA telle qu'Ailance, une « Model Card » ne doit pas être considérée isolément, mais doit être reliée aux objets et aux processus pertinents pour son fonctionnement réel. Il s'agit notamment des cas d'utilisation de l'IA, des outils d'IA, des fournisseurs, des sources de données, des risques, des mesures, des validations, des révisions, des directives, des rôles et responsabilités, des justificatifs, des versions et des résultats de surveillance.

Ces liens créent un contexte de gouvernance dans lequel les différents acteurs peuvent accéder aux informations qui les concernent : le propriétaire du modèle consulte l'état actuel du modèle, le service juridique les informations relatives aux prestataires et aux contrats, le service de protection des données les aspects liés à la protection des données, le service de sécurité informatique les exigences techniques et organisationnelles, et le service métier les limites d'utilisation et les conditions de validation en vigueur. Pour la direction, l’état d’avancement, les risques et les mesures en cours deviennent transparents, sans qu’il soit nécessaire de rassembler des informations provenant de différents documents.

Une simple comparaison

Cette comparaison montre qu'une « Model Card » ne peut être mise au service de la gouvernance que si elle est non seulement documentée, mais aussi mise à jour au fur et à mesure de l'exploitation, reliée aux processus pertinents et réévaluée en cas de modifications.

La question la plus importante en matière de gestion

La question la plus importante concernant la « Model Card » n'est pas de savoir si une organisation dispose d'une telle Documentation mais celui qui est chargé de veiller à ce qu’elle reste à jour. Cette responsabilité comprend notamment la mise à jour en cas de nouvelles versions de modèles ou de sources de données, la réévaluation en cas de modification des indicateurs de performance, la vérification des validations existantes ainsi que la Documentation et l'aggravation des risques connus.

Si aucun rôle ni aucune procédure clairs ne sont définis à cet effet, la « Model Card » reste un document qui, certes, contient des informations, mais qui n'est pas intégré de manière fiable dans le processus de gouvernance de l'IA.

Conclusion

Dans le cadre de la gouvernance de l'IA, les fiches de modèle ne doivent pas être considérées comme de simples pièces jointes PDF statiques, mais comme une documentation opérationnelle qui continue d'être mise à jour après la mise en service. Pour qu’elles conservent leur valeur probante, elles doivent être structurées, mises à jour, versionnées et soumises à révision, et être associées à des cas d’utilisation, des sources de données, des fournisseurs, des risques, des validations et des mécanismes de surveillance.

Ce n'est que sur cette base qu'il sera possible, par la suite, de retracer quelle version du modèle a été utilisée, quelles sources de données ont été exploitées, quels indicateurs ont été appliqués, quels risques de biais ou de performance étaient connus, quelle autorisation a été accordée et quelles modifications ont donné lieu à une nouvelle révision. C'est précisément cette traçabilité qui caractérise une gouvernance solide—Documentation à partir d'une description de modèle enregistrée une seule fois.

Qui se charge de mettre à jour la fiche de modèle chez vous lorsque la source de données ou la version change ?

Questions et réponses

Que doit contenir une fiche de modèle pour la gouvernance de l'IA ?

Une fiche de modèle doit contenir le nom du modèle, sa version, son fournisseur, son objectif, le cas d'utilisation auquel il se rapporte, ses sources de données, ses indicateurs de performance, des informations sur les biais et l'explicabilité, les risques, les contrôles, les validations, le responsable, la date de révision et l'historique des modifications.

Pourquoi une « Model Card » au format PDF ne suffit-elle pas ?

Un fichier PDF peut constituer un instantané, mais il ne permet pas de piloter un processus en cours. Il ne déclenche pas de révisions, n'affiche pas automatiquement la version productive, ne relie pas les risques aux mesures à prendre et rend les modifications difficiles à retracer.

Pourquoi faut-il mettre à jour une « Model Card » après la mise en production ?

Car les versions des modèles, les sources de données, les informations sur les fournisseurs, les performances, les risques et le contexte d'utilisation peuvent évoluer. Sans mise à jour, la réalité du modèle telle qu'elle est documentée ne correspond plus à la réalité du modèle en production.

Qui devrait être responsable de la « Model Card » ?

En règle générale, il faut un « Model Owner » ou un poste équivalent responsable Rôle. Selon l'organisation, peuvent également intervenir le responsable des cas d'utilisation, le responsable de la protection des données, le service juridique, le service de sécurité informatique, le service de science des données et Conformité être impliqué.

Quel est le lien entre une « Model Card » et un cas d'utilisation de l'IA ?

Le risque lié au modèle apparaît dans le contexte d'utilisation. C'est pourquoi la « Model Card » doit être associée aux cas d'utilisation concrets dans lesquels le modèle est utilisé.

Quel rôle joue la gestion des versions dans les Model Cards ?

Le contrôle des versions permet de savoir quelle version du modèle a été testée, validée et mise en production. Il est essentiel pour pouvoir retracer ultérieurement les modifications et les validations.

Quelles sources de données faut-il documenter ?

Il convient notamment de documenter les données d'entrée, les systèmes internes connectés, ainsi que les données d'apprentissage ou de réglage fin, le cas échéant, données à caractère personnel, les données confidentielles, l'origine des données et la qualité des données.

Que signifie « possibilité de révision » dans une fiche de mannequin ?

La « révisabilité » signifie qu'une fiche de modèle est vérifiée régulièrement, qu'elle a un responsable, qu'elle comporte une date de révision, que les modifications sont traçables et que les actions en cours sont suivies.

Que devrait-on demander dans un appel d'offres concernant les fiches de modèle ?

Un appel d'offres devrait demander si les fiches de modèle sont des objets structurés, s'il est possible de les associer à des cas d'utilisation, si la gestion des versions et les révisions sont prises en charge, si les validations sont liées aux versions et si les modifications apportées à la version du modèle ou à la source de données peuvent déclencher de nouvelles vérifications.

Comment Ailance prend-il en charge les « AI Governance Model Cards » ?

Ailance AI Governance devrait traiter les « Model Cards » comme des objets opérationnels structurés et les relier à des cas d'utilisation, des outils, des fournisseurs, des sources de données, des risques, des validations, des révisions, des mesures et des justificatifs.