IA à poids ouverts : évaluer aussi l’application autour du modèle

Évaluer un modèle d’intelligence artificielle ne suffit pas à établir la sécurité de l’application qui l’utilise. Un agent relié à des données internes ou à des outils peut exposer des risques que les tests du modèle seul ne révèlent pas. C’est le point de départ du guide commun publié par Microsoft et NVIDIA sur les modèles à poids ouverts.

Un modèle n’agit jamais seul dans un déploiement

Le niveau de risque dépend de la tâche et de ce qui entoure le modèle : ses utilisateurs, les données auxquelles il accède, les services qu’il peut appeler et les règles appliquées à ses réponses. Un assistant de rédaction interne et un outil qui répond à des clients ne sont donc pas évalués dans les mêmes conditions. Microsoft recommande de tester une configuration proche de l’usage prévu, plutôt que de s’en tenir au nom du modèle ou à ses résultats isolés.

Cette distinction compte particulièrement pour les modèles à poids ouverts. L’accès à leurs paramètres appris permet à une organisation de les examiner, les modifier ou les exécuter dans son propre environnement. Cette latitude élargit les choix techniques, mais oblige aussi à décider où les protections s’appliquent et quelle équipe les entretient.

Répartir les contrôles selon qui exploite le système

Une plateforme gérée peut prendre en charge certains contrôles opérationnels. Quand l’organisation exploite elle-même le modèle, elle doit déterminer quelles protections restent à sa charge, notamment autour des accès, des outils connectés et du suivi. Le guide invite ainsi à relier chaque risque repéré à une mesure d’atténuation et à un responsable, au lieu de traiter la sécurité comme une propriété générale du modèle.

Cette répartition dépend du déploiement concret. Les équipes doivent notamment savoir qui peut utiliser le système, quelles ressources il peut atteindre et qui intervient lorsqu’un test révèle un problème. Microsoft et NVIDIA indiquent que leur premier document porte surtout sur les risques au niveau du modèle ; ils annoncent des ressources ultérieures sur les couches d’exécution et d’application.

Une taxonomie commune aide à formuler les questions

Pour organiser l’analyse, le guide classe les risques en cinq familles : cybersécurité, protection des données, contenu, interaction humain-IA et biais. Cette taxonomie donne un vocabulaire commun aux équipes techniques, de sécurité, juridiques et métiers. Elle peut servir à préciser les scénarios à tester, puis à associer les résultats à des mesures et à des personnes chargées du suivi.

Les auteurs la présentent comme un cadre à adapter, ni comme une politique à appliquer telle quelle ni comme une liste de contrôle prête à l’emploi. Une organisation doit la relier à ses systèmes, ses usages et ses critères de risque. Elle ne constitue pas une certification et ne valide pas automatiquement un modèle ou l’application construite autour de lui.

Les évaluations doivent couvrir l’application

Microsoft cite des évaluations intégrées ou personnalisées, des exercices automatisés de mise à l’épreuve et des contrôles de sécurité de contenu dans Microsoft Foundry, son environnement d’évaluation des applications d’IA. Leur disponibilité dépend du modèle et du déploiement. Microsoft précise que ces fonctions doivent être complétées par des essais propres à l’application, une surveillance du système et une supervision humaine.

Pour une équipe qui étudie un déploiement, la démarche se traduit par une vérification en contexte : le modèle a-t-il été évalué pour la tâche visée, les permissions correspondent-elles au besoin, et les responsabilités de suivi sont-elles attribuées ? Le guide de Microsoft et NVIDIA fournit une structure pour poser ces questions ; les réponses restent propres à chaque système.