Tencent propose de combiner modèles d’IA ouverts et fermés pour renforcer la sécurité

Vous demandez à une IA d’expliquer une commande suspecte dans un journal de serveur, et elle refuse : la requête ressemble à une demande d’aide au piratage. Pour une équipe de sécurité, c’est un problème très concret. Avant de déployer un tel assistant, il est utile de vérifier s’il peut analyser de véritables incidents et à quels moments une intervention humaine sera nécessaire.

Selon The Decoder, qui cite le South China Morning Post, Yao Shunyu, responsable de la recherche en IA chez Tencent, propose de combiner modèles ouverts et fermés. Il met en garde contre les futurs risques biologiques liés à l’IA, mais estime que restreindre l’accès ne suffira pas à résoudre le problème. Les développeurs d’outils de défense ont eux aussi besoin de modèles suffisamment performants.

Il faut ici distinguer prévision et observation. L’avertissement sur la capacité de l’IA à concevoir des armes biologiques relève de l’évaluation du chercheur. Le cas d’analyse de journaux cité dans l’article illustre un autre problème, plus concret : les filtres de sécurité peuvent bloquer un travail utile.

Ce qui s’est passé lors de l’analyse de l’attaque

D’après l’article, Hugging Face a utilisé le modèle ouvert GLM-5.2 pour analyser des commandes retrouvées dans les traces d’une intrusion, alors que des modèles fermés refusaient de les examiner. Pour Yao, cet exemple montre pourquoi le secteur doit préserver l’accès aux modèles ouverts.

Imaginez un ingénieur qui découvre une commande inconnue dans un journal. Il doit comprendre quels fichiers elle touche, si elle contacte un serveur externe et quels événements rechercher à proximité. Dans ce scénario, le refus de l’assistant retarde l’enquête, alors même que la demande vise à protéger l’infrastructure.

L’article précise toutefois les limites de cet exemple. Le modèle a contribué à l’analyse des faits. Ce sont des spécialistes qui ont stoppé l’attaque : ils ont corrigé la vulnérabilité, reconstruit les serveurs touchés et remplacé les identifiants d’accès. Cet épisode ne permet pas de conclure qu’un modèle ouvert a protégé seul la plateforme, ni que les filtres de sécurité sont inutiles.

Pour la conception d’un produit, la distinction est essentielle. Expliquer une commande suspecte, proposer une vérification et obtenir l’autorisation de modifier un serveur correspondent à trois niveaux de responsabilité différents. Réussir au premier niveau ne dit rien de la capacité du système à assumer les suivants.

Pourquoi les poids ouverts compliquent la protection

Les modèles ouverts ont un revers : quiconque détient leurs poids peut modifier leur comportement. L’article évoque l’abliteration, une approche qui vise à atténuer le comportement de refus acquis pendant l’entraînement. Les restrictions d’un modèle ne peuvent donc pas être considérées comme une garantie immuable après sa publication.

Un service fermé conserve davantage de contrôle sur l’accès et le traitement des requêtes. Mais ce contrôle doit lui aussi être ajusté : des interdictions trop larges affectent des usages légitimes. Il en résulte un conflit pratique. L’équipe a besoin d’un outil qui l’aide à étudier des actions dangereuses, tandis que le fournisseur doit disposer d’un mécanisme limitant l’aide à leur exécution.

Transposer directement les conclusions de la cybersécurité à la biologie est particulièrement risqué. Comme le souligne l’article, il est plus difficile, dans ce domaine, de séparer les capacités offensives des capacités défensives. Une analyse réussie de journaux de serveur ne prouve pas que la mise à disposition sans restriction de toute autre capacité produira le même résultat.

Toujours selon l’article, Tencent prépare la sortie de Hy4 avec des poids ouverts et un rapport de sécurité. L’entreprise affirme que ses capacités en biologie sont limitées et que les capacités de piratage ont été supprimées grâce au filtrage des données d’entraînement. Pour l’heure, ces déclarations devront être évaluées à partir des méthodes et des résultats publiés, ainsi que de vérifications indépendantes. L’existence d’un rapport ne suffit pas à établir la sûreté du modèle.

Ce qu’il faut vérifier avant le déploiement

Pour les développeurs, la conséquence pratique est d’intégrer à l’évaluation du modèle des tâches réelles et autorisées susceptibles de provoquer des refus injustifiés. Par exemple : expliquer des commandes issues de journaux anonymisés, analyser leur propre code vulnérable ou préparer un compte rendu d’incident. Il convient d’évaluer simultanément l’utilité des réponses, l’exactitude des explications et la fréquence des blocages injustifiés.

L’équipe produit a intérêt à définir à l’avance ce qui se passe après un refus : la tâche est confiée à un spécialiste, l’utilisateur précise le contexte ou une procédure de vérification convenue est déclenchée. Le basculement automatique vers un modèle moins restrictif nécessite une justification spécifique et un contrôle des accès.

Lors du choix d’un fournisseur, il faut aussi déterminer quelles données quittent l’infrastructure, qui peut consulter les journaux et quelles actions l’assistant est autorisé à effectuer. L’ouverture des poids ne répond qu’à une partie de ces questions. Toute décision de déploiement exige de tester le cas d’usage concret et de définir clairement les responsabilités.