Modèles GPAI : ce que le code de bonnes pratiques change pour les entreprises.
Le code de bonnes pratiques GPAI vise d’abord les fournisseurs de modèles d’IA à usage général. Les entreprises qui achètent, intègrent ou adaptent ces modèles ont pourtant intérêt à comprendre les preuves qu’il organise.
Le code GPAI aide les fournisseurs signataires à démontrer leurs obligations de transparence, de droit d’auteur et, pour les modèles à risque systémique, de sûreté et sécurité. Les clients doivent vérifier le rôle du fournisseur, la version du modèle et les informations réellement disponibles.
Cluster éditorial : Modèles GPAI et chaîne de valeur · Intention : Comprendre le code GPAI et ses effets pour une entreprise
En bref
L’essentiel à retenir
01
Code volontaire, obligations légales applicables
02
Trois chapitres : transparence, droit d’auteur, sûreté et sécurité
03
Diligence fournisseur adaptée au rôle
04
Suivi des modèles, versions et changements
01
Distinguer modèle GPAI et système d’IA
Un modèle d’IA à usage général présente une généralité importante et peut accomplir un large éventail de tâches. Il peut être intégré dans de nombreux systèmes en aval. Le système final associe le modèle à une interface, des règles, des données, une finalité et un contexte d’utilisation. La qualification du modèle ne remplace donc pas celle du système utilisé par l’entreprise.
Cartographiez la chaîne. Identifiez le fournisseur du modèle, l’éditeur du produit, l’intégrateur, l’entreprise utilisatrice et les composants complémentaires. Notez la version, le mode d’accès, les adaptations et les données transmises. Cette carte montre quelles informations doivent circuler et où une modification peut changer le rôle ou le risque.
Le code de bonnes pratiques constitue un moyen volontaire pour les fournisseurs de modèles GPAI de démontrer le respect de certaines obligations. Il comporte des engagements de transparence et de droit d’auteur. Un chapitre supplémentaire traite la sûreté et la sécurité des modèles présentant un risque systémique. L’adhésion ne remplace pas les obligations du règlement et l’absence de signature ne signifie pas automatiquement non-conformité.
Demandez au fournisseur s’il a signé le code, quels chapitres couvrent le modèle et à partir de quelle date. Vérifiez les éventuelles réserves et la documentation publiée. Si le fournisseur choisit une autre méthode, demandez comment il démontre le respect des obligations applicables. L’objectif est de comprendre les preuves, pas de transformer un logo de signataire en réponse universelle.
Les fournisseurs de modèles GPAI doivent préparer et tenir à jour la documentation technique et fournir certaines informations aux fournisseurs de systèmes en aval. Ils doivent aussi mettre en place une politique visant à respecter le droit d’auteur de l’Union et publier un résumé suffisamment détaillé du contenu utilisé pour l’entraînement selon le modèle prévu. Ces éléments aident l’intégrateur à comprendre les capacités, les limites et les conditions d’utilisation.
Pour votre achat, demandez les documents utiles à l’usage prévu. Vérifiez les versions, les langues, les performances, les limites, les conditions de licence, les mécanismes de retrait ou d’opposition pertinents et la gestion des changements. Le niveau d’accès peut varier selon le rôle et la confidentialité. Consignez les informations manquantes et leur effet sur la décision.
Un modèle GPAI peut être classé comme présentant un risque systémique selon les critères du règlement. Son fournisseur porte alors des obligations renforcées, notamment en matière d’évaluation, d’analyse et d’atténuation des risques systémiques, de signalement des incidents graves et de cybersécurité. Le chapitre sûreté et sécurité du code propose un cadre de démonstration pour les signataires concernés.
Une entreprise en aval doit comprendre ce que cette qualification change pour son intégration. Demandez les limites d’utilisation, les mesures de sécurité, les canaux d’incident et les informations nécessaires à vos propres contrôles. Ne supposez pas qu’un modèle puissant rend automatiquement le système final haut risque. La finalité et le contexte du système restent à qualifier séparément.
Le contrat doit préciser le modèle et la version, les modalités d’accès, les documents fournis, les notifications de changement, les incidents, les restrictions, la sécurité et la réversibilité. Pour un service qui met à jour le modèle sans action du client, prévoyez un préavis et un droit de tester les changements significatifs. Une preuve évaluée au moment de l’achat peut devenir obsolète après une mise à jour silencieuse.
Organisez aussi la coopération entre l’éditeur du produit et le fournisseur du modèle. Votre interlocuteur commercial doit pouvoir expliquer quelles informations proviennent du modèle et lesquelles concernent le système final. Un renvoi général vers la documentation publique ne suffit pas si des paramètres locaux modifient le comportement ou les risques.
La fiche résume la chaîne de valeur, le modèle, le fournisseur, le statut du code, la documentation, les licences, les risques, les incidents et les changements. Elle contient une décision sur l’usage autorisé, les conditions, les tests et la date de revue. Les achats, la technique, la conformité, la sécurité et le métier la valident selon leur périmètre.
Mettez la fiche à jour lors d’une nouvelle version, d’un changement de fournisseur, d’une extension de finalité ou d’un incident. Elle devient le point d’entrée pour les équipes qui veulent réutiliser le modèle. Elles voient immédiatement ce qui a été vérifié, ce qui reste inconnu et quelles conditions respecter.
L’adhésion au code est volontaire. Les obligations du règlement restent applicables aux fournisseurs concernés, qui peuvent démontrer leur conformité par d’autres moyens.
Le code vise principalement les fournisseurs de modèles GPAI. Une entreprise utilisatrice doit surtout qualifier son rôle, son système et les informations nécessaires.
Non. La qualification du modèle et celle du système en aval sont distinctes. La finalité du système final reste déterminante.
La version, la documentation, les capacités et limites, le statut du code, la politique de changement, les incidents, la sécurité et les conditions de licence.
Après une nouvelle version, une modification de finalité, un changement de chaîne de valeur ou un incident.
