if ( !emtpy($headline_subheadline ) ) : ?>
Il est conseillé aux organisations d’utiliser la vérification cryptographique, les tests contradictoires et la surveillance continue pour gérer les risques lors des déploiements d’IA.
endif; ?>
Microsoft et Nvidia exhortent les entreprises à évaluer la sécurité des modèles d’IA à poids ouvert tout au long du déploiement, avertissant que les modifications apportées aux poids et aux configurations des modèles peuvent affaiblir les protections même lorsqu’un modèle conserve sa capacité à effectuer les tâches qui lui sont assignées.
Dans un article conjoint publié la semaine dernière, les entreprises ont identifié 30 types de risques répartis en cinq catégories et ont décrit un processus pour les évaluer, les atténuer et les surveiller. Les directives appellent les entreprises à vérifier la provenance du modèle, à tester les configurations qu’elles ont l’intention de déployer et à réévaluer les risques après des changements importants.
« L’ouverture du poids à elle seule ne détermine pas le risque d’un système d’IA », indique le journal. « Le risque dépend du modèle, du cas d’utilisation, du déploiement et des garanties. »
Le cadre couvre la cybersécurité, la protection des données, le contenu, l’interaction homme-IA et les préjugés. Sa catégorie de cybersécurité comprend la génération de code malveillant, les appels d’outils malveillants, l’extraction des politiques de sécurité du modèle, la génération excessive de jetons et les comportements qui s’écartent de l’objectif prévu du système.
Le document s’appuie sur les normes de gestion des risques existantes du NIST et de l’ISO et est le premier d’une série prévue sur la gestion des risques lors des déploiements d’IA à poids ouvert, ont indiqué les sociétés dans un article de blog.
Les changements de modèle peuvent affaiblir les garanties
Les modèles à poids ouvert peuvent être affinés, fusionnés avec d’autres modèles, modifiés ou reconditionnés pour différentes utilisations. Mais ces changements peuvent affaiblir les protections de sécurité d’un modèle même s’il continue de bien remplir la tâche prévue, ont déclaré Microsoft et Nvidia.
« Les comportements en matière de sécurité sont souvent les plus fragiles des deux », ont écrit les entreprises. Les modifications apportées aux pondérations du modèle, au réglage fin, à la quantification et à la configuration peuvent « dégrader les mesures de protection tout en laissant intactes les performances des tâches ».
Cela crée un défi pour les équipes de sécurité de l’entreprise : un modèle peut continuer à fournir des résultats précis sur des tâches de routine même après que des changements ont affecté la manière dont il répond aux demandes non sécurisées. Les sociétés conseillent aux entreprises d’évaluer séparément la sécurité et les capacités, de tester la configuration spécifique du modèle qu’elles ont l’intention de déployer et de répéter les évaluations après des changements importants.
« Aucun volume de tests comportementaux n’établit ce qu’est un artefact, mais seulement comment il se comporte », indique le journal. Il recommande d’utiliser des signatures cryptographiques pour vérifier qu’un modèle correspond à l’artefact original de l’éditeur.
« Lorsque les signatures ne sont pas disponibles, enregistrez l’intégrité non vérifiée comme un risque ouvert plutôt que de traiter les résultats de l’évaluation comme une clôture », recommande le document.
Pour les entreprises, Gartner recommande des tests contradictoires indépendants, une analyse statique des fichiers de modèles et une vérification de la provenance avant et après le déploiement. Le processus de vérification proposé par Gartner nécessite également de vérifier les sources des modèles, de vérifier l’intégrité des fichiers, d’effectuer des tests contradictoires et d’enregistrer les modèles approuvés dans un registre d’entreprise.
La sécurité doit aller au-delà du modèle
Microsoft et Nvidia préviennent que l’évaluation d’un modèle à elle seule ne permet pas d’établir la sécurité de l’application construite autour de celui-ci.
« L’évaluation du modèle à elle seule ne permet pas d’établir la sécurité d’un agent ou d’une application ; les entreprises doivent également évaluer les autorisations, l’accès aux données, les outils connectés, le comportement d’exécution et les contrôles opérationnels », indique le document.
Le guide recommande d’évaluer les modèles dans leur contexte opérationnel prévu et de maintenir des contrôles sur les couches de modèle, d’exécution, de harnais et d’application. Cela nécessite également de surveiller les entrées, les sorties et l’utilisation des outils du modèle après le déploiement.
Selon Gartner, le trafic du modèle ouvert doit être acheminé via des passerelles d’IA gouvernées pour appliquer l’authentification, les défenses contre l’injection rapide, la protection des données sensibles et la journalisation d’audit.
Le cabinet de recherche recommande également d’isoler les environnements d’exécution auto-hébergés et d’appliquer des contrôles adaptés à d’autres modèles de déploiement, notamment des chemins de réseau privés et des clés de chiffrement gérées par le client pour la consommation des API cloud.
Gartner a rapporté que les demandes des clients concernant les modèles à pondération ouverte via son service de recherche ont augmenté de plus de 30 % au deuxième trimestre 2026 par rapport au premier trimestre. L’entreprise prévoit que les modèles ouverts représenteront 50 % des cas d’utilisation de l’IA en entreprise d’ici 2028, contre 20 % au moment de la publication de son rapport.
Question de dotation en personnel et de responsabilité
Sanchit Vir Gogia, analyste en chef chez Greyhound Research, a déclaré que l’auto-hébergement oblige les entreprises à rendre compte des personnes et des processus nécessaires au maintien des garanties.
« L’auto-hébergement est une décision en matière de personnel autant qu’une décision en matière d’infrastructure, et les personnes chargées de le réaliser doivent suivre le modèle », a déclaré Gogia.
Il a mis en garde contre l’hypothèse selon laquelle l’auto-hébergement signifie nécessairement le remplacement de toutes les garanties disponibles via les services gérés. Selon lui, la fonction d’enquête sur les abus du fournisseur peut constituer une lacune importante, tandis que les responsabilités du client dépendent du service et de sa configuration.
Gogia a déclaré que le document Microsoft-Nvidia fournit des conseils utiles mais laisse des domaines importants pour les travaux futurs. Les auteurs affirment que les publications ultérieures étendront les conseils de gestion des risques aux couches d’exécution, de harnais et d’application.
« La question la plus cruciale est de savoir qui est contractuellement obligé de re-tester et de corriger le modèle lorsqu’une nouvelle technique de décapage arrive », a déclaré Gogia. Pour les RSSI, Gogia recommande d’évaluer le modèle, le déploiement et l’utilisation prévue avant d’approuver les charges de travail de production. Il conseille également aux équipes de sécurité de garder le contrôle de leurs registres de risques plutôt que de s’appuyer exclusivement sur une taxonomie développée par le fournisseur.
