L’agence de cybersécurité de l’UE et son service de recherche scientifique testent des modèles d’IA chinois à poids ouverts, qui peuvent être téléchargés et exécutés sur une infrastructure locale.
L’Agence de l’Union européenne pour la cybersécurité (ENISA) et le Centre commun de recherche (JRC) de la Commission européenne ont confirmé ces évaluations auprès de Politico. L’étude du JRC inclut également des modèles américains et européens, et exécute les systèmes sur sa propre infrastructure informatique sécurisée, selon The Next Web.
Pour les organisations qui envisagent des déploiements similaires, la question de la sécurité ne se limite pas à déterminer quel modèle est le plus performant, mais aussi à savoir à quelles données et à quels systèmes il peut accéder.
Ce que l’UE teste et ce qui reste inconnu
Le porte-parole de la Commission Maciej Berestecki a déclaré à Politico que le JRC exécute ces modèles sur sa propre infrastructure informatique sécurisée et que la Commission n’a pas l’intention de les utiliser dans ses activités quotidiennes. Cependant, ni les modèles précis évalués ni les résultats des tests n’ont été communiqués.
Un deuxième responsable de la Commission a déclaré à Politico que la sûreté et la sécurité ne constituaient pas l’objectif principal de l’étude du JRC. Les informations disponibles ne permettent pas d’établir si ses conclusions orienteront les décisions d’achat ou de déploiement.
L’IA à poids ouverts transfère les contrôles de sécurité vers l’organisation qui la déploie
Contrairement aux services d’IA hébergés, dont le fournisseur contrôle l’infrastructure et peut imposer des mesures de protection au niveau du service, les modèles à poids ouverts peuvent être téléchargés et modifiés, puis exécutés sur les propres systèmes d’une organisation. Le développeur d’origine ne peut donc pas contrôler de manière centralisée la configuration de chaque copie, les restrictions que les utilisateurs suppriment ou les systèmes auxquels le modèle se connecte.
Les organisations qui exécutent des modèles sur leur propre infrastructure assument la responsabilité de sécuriser ce déploiement. Elles doivent sécuriser l’environnement dans lequel le modèle s’exécute, limiter son accès aux données sensibles et aux outils externes, et vérifier que ses mesures de protection tiennent dans des conditions opérationnelles réelles.
Ces évaluations pourraient améliorer la compréhension des capacités et des limites des modèles. Les informations disponibles ne les présentent pas comme une procédure d’homologation pour un usage gouvernemental ou professionnel.
Malgré tout, le niveau de sécurité de ces modèles en pratique dépend également de la manière dont les organisations les configurent, les modifient et les intègrent à leurs activités. Les changements apportés au modèle, à ses autorisations ou à ses outils connectés peuvent modifier le profil de risque du système déployé.
Ce que les équipes de sécurité doivent vérifier avant le déploiement
Pour les organisations qui envisagent l’IA à poids ouverts, le déploiement local permet de contrôler l’endroit où le modèle s’exécute. Ce contrôle ne suffit pas à établir que le système ainsi obtenu est sécurisé. Les équipes doivent toujours évaluer le modèle, ses logiciels de support et son accès aux ressources de l’entreprise.
Commencez par définir la charge de travail visée. Identifiez les informations que le système traitera, déterminez s’il doit accéder à des dossiers confidentiels et vérifiez s’il peut appeler des outils externes ou exécuter des commandes. Un système qui résume des documents nécessite une évaluation différente de celle d’un agent autorisé à modifier des fichiers ou à interagir avec des systèmes de production.
Testez ces autorisations dans un environnement isolé avant d’accorder un accès réel. Utilisez des données représentatives et non sensibles pour vérifier si des instructions malveillantes présentes dans des documents ou des réponses d’outils peuvent détourner le système, divulguer des informations ou déclencher l’exécution de code non autorisée. Limitez l’accès à ce qui est nécessaire à la charge de travail et exigez une validation humaine pour les actions lourdes de conséquences.
Considérez toute modification comme une raison de réévaluer le déploiement. Un réglage fin, le remplacement d’un modèle, l’ajout d’un connecteur ou l’élargissement des autorisations peuvent changer le comportement du système. Les équipes doivent documenter la configuration testée, surveiller son fonctionnement et conserver un moyen de désactiver l’accès en cas de problème.
Les évaluations de l’UE fournissent un contexte pertinent, mais le fait qu’elles aient été rapportées ne permet pas d’établir qu’un modèle donné convient à un déploiement professionnel. Tant que les méthodes et les conclusions ne sont pas disponibles, les organisations ne peuvent pas déterminer quelles conclusions de sécurité ces tests permettent de tirer. En pratique, il faut évaluer l’ensemble du système dans les conditions opérationnelles prévues avant de le connecter à des données sensibles ou à des outils professionnels.
En savoir plus : découvrez comment l’injection de prompt dans Azure DevOps peut amener les agents de codage IA à accéder à des données sensibles via les autorisations existantes d’un développeur.