Modèles d’IA à usage général : le dossier fournisseur qu’un assureur doit exiger

Lorsqu’un assureur intègre un grand modèle généraliste, il achète rarement une vérité prête à l’emploi. Il reçoit une capacité technique, des conditions, une interface et un ensemble de documents. La qualité de ces documents détermine ce que l’équipe peut raisonnablement tester, surveiller et expliquer. Une brochure, un classement de benchmark et une promesse de sécurité ne suffisent pas à construire un système d’assurance gouvernable.

Le dossier fournisseur doit répondre à une question pratique : quelles affirmations pouvons-nous vérifier, quelles limites devons-nous compenser et quelles dépendances refusons-nous d’accepter ? Il ne s’agit ni de recopier les obligations du fournisseur, ni de transférer à ce dernier la responsabilité du processus de l’assureur.

Qualifier modèle, système et rôles

Le règlement (UE) 2024/1689, version consolidée au 27 juillet 2026, distingue le modèle d’IA à usage général du système d’IA qui l’intègre. Un modèle GPAI est capable d’accomplir de manière compétente une large gamme de tâches et peut être intégré dans divers systèmes ou applications, sous les conditions du texte. Le système aval ajoute une finalité, une interface, des données, des règles, des outils et des utilisateurs.

Le fournisseur du modèle développe ou fait développer le modèle et le met sur le marché sous son nom ou sa marque. Un fournisseur aval peut intégrer le modèle dans un système. Le déployeur utilise un système sous son autorité, sauf usage personnel non professionnel. Une même organisation peut cumuler des rôles si elle modifie substantiellement un système, change sa finalité ou met une solution sur le marché. Cette qualification doit être conduite sur les faits ; acheter une API ne transforme pas automatiquement l’assureur en fournisseur du modèle.

Créez une fiche par chaîne :

Objet	Question	Preuve
Modèle	Quel nom technique, quelle version et quel fournisseur ?	Documentation, réponse API, manifeste de version
Système	Quelle finalité, quelles données et quelles actions ?	Architecture, registre IA, procédure métier
Intégrateur	Qui ajoute le prompt, les outils, le corpus et les contrôles ?	Contrats, dépôt, configuration, responsabilités
Déployeur	Qui utilise la sortie et décide ?	Processus, habilitations, contrôle humain

Les comparatifs comme les frontier models pour l’assurance ou la comparaison de plusieurs familles de modèles aident à explorer les capacités. Ils ne remplacent pas la qualification juridique ni le dossier de preuve du fournisseur.

Comprendre le dossier GPAI prévu par le règlement

Le chapitre V du règlement IA prévoit des obligations pour les fournisseurs de modèles GPAI : établir et tenir à jour une documentation technique, mettre des informations et documents à disposition des fournisseurs de systèmes aval afin qu’ils comprennent les capacités et limites et respectent leurs obligations, mettre en place une politique de respect du 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 fourni par l’Office de l’IA. Des règles et exemptions spécifiques existent, notamment pour certains modèles publiés sous licence libre, tandis que les obligations liées au droit d’auteur et les régimes de risque systémique doivent être examinés séparément.

Les lignes directrices officielles de la Commission sur les fournisseurs de modèles GPAI expliquent la portée des définitions, obligations et responsabilités. La foire aux questions officielle GPAI précise le calendrier et l’articulation avec le Code. Ces ressources doivent être datées et relues à chaque achat, car les documents d’application évoluent.

Le Code de bonnes pratiques pour les modèles GPAI est un instrument volontaire destiné à aider les fournisseurs à démontrer le respect de certaines obligations. Une adhésion n’est ni une certification universelle, ni une garantie de performance pour l’assurance. Un fournisseur non signataire n’est pas automatiquement inutilisable ; l’acheteur doit alors apprécier autrement la preuve fournie et ses risques.

Le dossier de l’assureur contient donc deux colonnes : documents dus ou publiés par le fournisseur selon son rôle, et informations additionnelles nécessaires au cas d’usage. Les secondes peuvent relever du contrat, de la recette ou d’un choix d’architecture sans être exigées mot pour mot par le règlement.

Demander capacités, limites et modalités d’intégration

Une fiche de modèle utile ne dit pas seulement « raisonnement avancé » ou « multilingue ». Elle décrit les modalités acceptées, formats, limites de contexte, sorties structurées, outils, langues évaluées, conditions d’abstention, variabilité, filtres, latence, disponibilité et changements annoncés. Chaque capacité est accompagnée de la méthode utilisée pour l’établir.

Demandez notamment :

• l’identité exacte de la version et la politique de dépréciation ;
• les modalités et formats acceptés, y compris les restrictions de fichiers ;
• les langues et tâches évaluées, avec jeux, dates et limites ;
• les paramètres configurables et ceux imposés ;
• le comportement des filtres, refus et sorties non conformes ;
• les outils ou appels de fonction disponibles et leurs permissions ;
• les limites connues : hallucination, calcul, documents longs, citations, actualité ;
• les conditions de disponibilité, quotas et modes dégradés ;
• les données conservées, leur durée et les options de non-réutilisation ;
• les moyens de journaliser modèle, version, paramètres et route.

Une limite doit devenir un contrôle. Si le modèle n’assure pas la fidélité d’une citation, l’architecture récupère et affiche la source. Si une langue est peu testée, elle est exclue ou soumise à une revue renforcée. Si la version peut changer silencieusement, le système exécute des sondes et peut geler ou couper la route.

Le guide sur les petits modèles de langage en assurance rappelle qu’un modèle plus petit et spécialisé peut être préférable selon confidentialité, coût, latence et maîtrise. La taille ou le caractère généraliste ne doit pas devenir un critère d’achat isolé.

Examiner données, droit d’auteur et provenance

Le résumé des contenus d’entraînement prévu par le règlement sert la transparence en amont. Il ne fournit pas nécessairement une liste exhaustive de chaque élément ni la preuve que le modèle est adapté au vocabulaire de l’assureur. L’acheteur examine le document, la politique de droit d’auteur et les réponses contractuelles, puis définit ses propres restrictions d’usage.

Le dossier distingue quatre flux souvent confondus :

1. les données ayant servi au préentraînement du modèle ;
2. les données de fine-tuning ou d’adaptation ajoutées ensuite ;
3. les entrées et pièces envoyées par l’assureur lors de l’inférence ;
4. les journaux, retours ou corrections susceptibles d’être réutilisés.

Pour chacun : fournisseur responsable, finalité, provenance connue, durée, lieu, droits, accès et possibilité de retrait. Une clause « vos données ne servent pas à entraîner » ne répond pas à la conservation pour sécurité, au support humain, aux sous-traitants ou aux journaux de la passerelle.

Un contenu généré peut reproduire, transformer ou inventer une référence. Le système aval vérifie les sources avant toute utilisation contractuelle ou conseil. Le dossier fournisseur renseigne les mécanismes et politiques ; il ne garantit pas la licéité de chaque sortie.

Lorsque l’assureur adapte le modèle avec ses données, il documente les droits, la minimisation, la séparation des environnements et les effets sur le rôle juridique. Une modification importante peut modifier la qualification des responsabilités. Cette analyse doit être renouvelée à chaque nouvelle méthode d’adaptation.

Relier sécurité et risque systémique au contexte assurance

Les fournisseurs de modèles GPAI présentant un risque systémique sont soumis à des obligations renforcées, notamment évaluation, gestion des risques systémiques, suivi et notification des incidents graves concernés, ainsi que cybersécurité adéquate selon le règlement. L’assureur ne doit pas conclure qu’un modèle absent de cette catégorie est sûr, ni appliquer indistinctement ces obligations à tous les fournisseurs.

Le dossier sécurité demande les menaces pertinentes pour l’intégration : extraction de données, injection, contournement de filtre, empoisonnement, exfiltration par outil, usage abusif, dépendance et indisponibilité. Il demande les évaluations, leur périmètre, les correctifs et les limites de divulgation. Une attestation générique ne remplace pas un test du système aval.

Les contrôles se répartissent :

Niveau	Contrôle fournisseur	Contrôle assureur
Modèle	Évaluations, filtres, sécurité et gestion de version	Vérifier documentation et tester les scénarios propres
Passerelle	Authentification, isolation, disponibilité	Limiter les routes, données, quotas et destinations
Application	Sans objet si fournisseur distinct	Permissions, sources, validation et journalisation
Processus	Informations sur les limites	Contrôle humain, mode dégradé et incident

Le dossier sur la réversibilité d’un fournisseur IA complète la sécurité : une dépendance sûre aujourd’hui peut devenir incontrôlable si la sortie est impossible ou si les preuves disparaissent.

Transformer chaque pièce en preuve exploitable

Une pièce n’a de valeur que si elle soutient une affirmation et une décision. Créez un passeport fournisseur à quatre colonnes :

Document reçu	Affirmation soutenue	Vérification interne	Décision possible
Documentation technique	Capacités, limites, formats, architecture	Recette sur cas assurance et contrôles de version	Autoriser les tâches couvertes
Résumé d’entraînement	Catégories de contenus et démarche	Analyse juridique et restriction des usages	Accepter, demander un complément ou exclure
Rapport d’évaluation	Performance ou sécurité sur un périmètre	Reproduire des sondes et mesurer l’écart au contexte	Définir seuils et revue humaine
Politique de changement	Préavis, versions et dépréciation	Simuler mise à jour et retour arrière	Geler, tester ou changer de route
Plan de sortie	Exports et assistance	Exercice de migration partiel	Accepter la dépendance résiduelle

La preuve comporte une date et un périmètre. Un rapport sur une version précédente ou un autre mode d’hébergement ne prouve rien sur la route utilisée. Lorsque le fournisseur ne communique pas un élément pour des raisons légitimes de sécurité ou secret, l’équipe peut demander une preuve alternative, un audit tiers ou une clause. L’absence reste enregistrée dans le risque résiduel.

Relier la documentation à une recette assurance

La documentation reçue permet de concevoir la recette, elle n’en fournit pas le résultat. L’équipe sélectionne des cas qui représentent la finalité autorisée, les variations de documents, les langues, les refus attendus et les erreurs dont l’effet serait important. Elle mesure séparément extraction, fidélité aux sources, format, abstention, sécurité et usage des outils. Une moyenne unique mélangerait des qualités différentes.

Les critères sont fixés avant l’essai. Pour un résumé de souscription, une omission de mise en forme n’a pas le même poids qu’une exclusion oubliée ou une source inventée. Les cas critiques peuvent être bloquants même si le score global progresse. Les résultats sont rattachés à la version, aux paramètres, au corpus et à la couche de filtrage.

Une comparaison avec un autre modèle éclaire un choix mais ne transforme pas le meilleur score en autorisation. Le modèle le plus performant peut offrir moins de contrôle de version ou des conditions de données incompatibles. La décision combine capacité, maîtrise, coût, continuité et preuve. Elle déclare aussi les scénarios non testés et la quantité limitée de cas lorsque c’est le cas.

Enfin, la recette vérifie les affirmations négatives : données non conservées, outil non appelé, route interdite non utilisée, refus déclenché au bon moment. Ces propriétés exigent des traces ou un test d’architecture ; une sortie apparemment correcte ne les démontre pas. Toute impossibilité d’observer une propriété critique devient une lacune du dossier.

Traiter versions, modèles ouverts et modifications

Un nom commercial peut désigner plusieurs instantanés. L’API peut router vers une nouvelle version tout en conservant le même alias. Exigez un identifiant observable et une politique de changement. À chaque appel critique, conservez lorsque disponible le fournisseur, le modèle, la version, les paramètres et la route, sans journaliser excessivement les données métier.

Pour un modèle ouvert, vérifiez la licence, la provenance du fichier, l’intégrité, la documentation, les dépendances et la capacité de maintenir les correctifs. « Ouvert » peut désigner des poids accessibles, une licence permissive ou du code public ; ces notions ne sont pas équivalentes. Certaines exemptions documentaires du règlement ont des conditions et ne couvrent pas nécessairement les modèles à risque systémique.

Une adaptation, quantification ou fusion peut changer le comportement. Le fournisseur de l’original ne garantit pas automatiquement la variante. Le dossier précise qui a modifié quoi, avec quel jeu, quelle recette et quelle responsabilité. Le choix entre hébergement et API est traité dans la grille acheter ou construire.

Les changements silencieux sont surveillés par des sondes stables : format, refus, fidélité aux sources, sécurité et cas critiques. Une dérive ne prouve pas une mise à jour du fournisseur, mais déclenche une qualification. Le contrat et la télémétrie doivent permettre l’enquête.

Construire une scorecard sans faux label

La scorecard indique la complétude et l’exploitabilité du dossier, pas une conformité absolue. Chaque ligne reçoit un statut : fourni et vérifié, fourni mais insuffisant, promis, non applicable justifié, absent, ou contradictoire. Un pourcentage unique est dangereux : dix documents administratifs ne compensent pas l’absence d’identité de version ou de plan d’incident.

Domaine	Critère bloquant possible	Décision associée
Identité et version	Version exécutée impossible à déterminer	Refuser les actions à effet ou exiger une route figée
Capacités et limites	Finalité critique non évaluée	Limiter à un pilote ou retirer l’usage
Données	Rétention ou réutilisation incompatible	Changer configuration, données ou fournisseur
Sécurité	Incident et vulnérabilité sans canal exploitable	Refuser la mise en production
Changement	Aucun préavis ni test possible	Ajouter une passerelle, des sondes et un retour arrière
Sortie	Données ou traces non exportables	Réduire la dépendance ou négocier

La pondération est définie avant d’évaluer les offres. Les achats, l’architecture, la sécurité, le juridique et le métier la valident. Une exigence peut être bloquante indépendamment du score. La scorecard conserve les désaccords et les preuves, pas seulement une couleur.

Scénario : assistant de souscription

Scénario hypothétique : un assureur souhaite intégrer un modèle GPAI dans un assistant qui résume les pièces et propose les informations manquantes. Il ne doit pas décider de l’acceptation ni calculer la prime. Le fournisseur fournit une fiche de modèle, une politique de données et des résultats sur des tâches générales.

L’équipe constate que les évaluations ne couvrent ni les documents contractuels français ni les tableaux scannés. Elle classe ces capacités comme non établies. Le pilote est limité aux documents textuels, exige une provenance par extrait et s’abstient sur les scans. Un échantillon est revu par les souscripteurs.

Le fournisseur annonce un alias mis à jour périodiquement sans identifiant stable. L’assureur exige une route versionnée ou, à défaut, place la passerelle en mode silencieux lors d’un changement détecté. Le mécanisme est documenté dans le système de contrôle interne : sondes de régression sur les cas critiques, retour à la version connue et aucune action automatique pendant la recette. La décision précise qui peut geler la route, sur quel signal et avec quelle preuve de retour à un état maîtrisé.

Enfin, le fournisseur ne donne pas de preuve suffisante sur la rétention d’extraits dans un outil de support. Le pilote utilise des données synthétiques validées jusqu’à clarification. La décision n’est ni « modèle conforme » ni « fournisseur rejeté » : elle est conditionnelle, limitée et réversible.

Inscrire les preuves dans le contrat et la durée

La diligence initiale vieillit. Le contrat transforme les besoins critiques en obligations : information sur versions, sous-traitants et incidents ; coopération ; documentation ; droits de test ou preuve alternative ; disponibilité ; export ; suppression ; sortie. Les clauses doivent correspondre au pouvoir de négociation et aux textes applicables, sans recopier des listes impossibles à exercer.

Le propriétaire du fournisseur organise une revue événementielle et périodique. Les événements incluent nouvelle version, changement de conditions, incident, nouvelle région, modification de sous-traitance, extension de finalité et apparition d’une obligation. À chaque événement, les pièces, tests et décisions concernés sont identifiés.

Une veille commerciale n’est pas une preuve. Les notes de version publiques déclenchent une analyse mais la configuration et les tests confirment l’effet. Le fournisseur doit pouvoir recevoir une question contextualisée et répondre avec un responsable.

Décider : accepter, compléter, limiter ou refuser

Le comité reçoit le cas d’usage, le rôle, la scorecard, les essais, les lacunes et le risque résiduel. Il choisit parmi quatre décisions explicites :

1. accepter : pièces et contrôles suffisants pour le périmètre défini ;
2. compléter : informations manquantes avec délai, propriétaire et interdiction temporaire ;
3. limiter : données, tâches, utilisateurs, autonomie, volume ou durée réduits ;
4. refuser : dépendance ou manque de preuve incompatible avec le risque.

La décision cite les preuves et ses limites. Elle ne transfère pas au fournisseur la validation du système aval. Les tests de performance, de sécurité, de droits fondamentaux et de protection des données restent conduits selon le cas d’usage.

Le bon dossier ne promet pas de supprimer l’incertitude. Il la rend visible et gouvernable : ce que le fournisseur affirme, ce que l’assureur a vérifié, ce qui manque, ce qui est interdit et ce qui déclenchera une nouvelle décision.

Sources officielles

• EUR-Lex — règlement (UE) 2024/1689, version consolidée au 27 juillet 2026, notamment chapitre V.
• Commission européenne — Guidelines for providers of general-purpose AI models.
• Commission européenne — General-Purpose AI Code of Practice.
• Commission européenne — General-purpose AI models in the AI Act: questions and answers.