Quand les dark LLMs contournent les protections sans effort

Les LLM restent vulnérables aux piratages malveillants (jailbreaking)

Les grands modèles linguistiques (LLM) sont impressionnants. Ils peuvent enseigner, rédiger, traduire, coder. Mais ils restent étonnamment faciles à manipuler. Les recherches menées par Michael Fire, Yitzhak Elbazis, Adi Wasenstein et Lior Rokach à l’université Ben Gourion le montrent clairement. Ils ont démontré que même les modèles d’IA commerciaux dotés de systèmes de sécurité intégrés peuvent être amenés à produire des résultats nuisibles ou illégaux. Il peut s’agir d’instructions pour la fabrication de bombes, de tactiques de délit d’initié ou de la manière de mener une opération de blanchiment d’argent.

La méthode qui permet de contourner ces contraintes intégrées est connue sous le nom d « “attaque universelle d” évasion ». En gros, le modèle est alimenté par une invite très spécifique qui le pousse à sortir de son alignement prudent. Résultat : il réagit comme s’il n’y avait aucune protection. Ce n’est pas une théorie. Il fonctionne avec plusieurs systèmes d’IA bien connus dans des conditions réelles. Leur rapport de recherche, intitulé « Dark LLMs : The Growing Threat of Unaligned AI Models », explique en détail comment cela se produit.

Si votre entreprise dépend d’informations ou de décisions générées par l’IA, c’est important. L’hypothèse selon laquelle votre modèle est sûr, parce qu’il dispose de garde-fous, n’est plus valable. Ces garde-fous peuvent être corrigés, certes, mais le jailbreaking exploite quelque chose de plus profond. Il exploite la fonction principale du modèle : répondre aux modèles de langage. Avec le bon modèle, ces restrictions sont brisées.

Pour les dirigeants de C-suite, la conclusion est simple : Ne présumez pas que vos outils d’IA sont sûrs par défaut. Vérifiez-les. Testez-les sous contrainte. Décidez si le risque qu’ils introduisent est un risque que vous comprenez et que vous pouvez gérer. Nous avons dépassé le stade où l' »IA éthique » est un mot à la mode. Il s’agit désormais d’une question de continuité des activités et d’exposition à la réputation.

Les LLM à source ouverte présentent un risque unique et incontrôlable

Les LLM à code source ouvert offrent rapidité et flexibilité. Les développeurs les adorent. Mais ils sont aussi presque impossibles à contenir une fois qu’ils sont diffusés. Selon les mêmes chercheurs de Ben Gurion, ces modèles sont souvent non censurés, avec des contraintes de sécurité limitées ou inexistantes. Une fois diffusés, ils sont copiés, archivés et partagés sur des serveurs et des appareils dans le monde entier, échappant ainsi à tout contrôle.

Le plus gros problème est la façon dont les attaquants les exploitent. Un modèle peut être utilisé pour en casser un autre. Ainsi, même si vous pensez avoir sécurisé votre système d’IA commercial, il peut être interrogé par des structures construites à partir d’outils open-source compromis. Dans ce cas, vos mesures de protection internes peuvent être contournées à votre insu.

Contrairement aux modèles commerciaux, que les vendeurs peuvent mettre à jour ou corriger, les versions à code source ouvert ne font pas l’objet d’un contrôle centralisé. Une fois dans la nature, elles sont permanentes. Cela crée de nouvelles vulnérabilités pour les entreprises qui intègrent des outils d’IA open-source ou qui s’interfacent avec des modèles externes. Du point de vue de la sécurité, c’est une porte ouverte. Du point de vue de la conformité, il s’agit d’une responsabilité.

Les chefs d’entreprise devraient reconsidérer l’hypothèse selon laquelle les logiciels libres sont automatiquement associés à l’innovation et à la rentabilité. En matière de sécurité, l’absence de contrôle est synonyme de risque. Comprenez ce que votre équipe déploie. S’il s’agit d’un logiciel libre, traitez-le avec la même attention que n’importe quel système fournisseur non vérifié, car c’est exactement ce qu’il devient une fois adopté à grande échelle.

Une stratégie défensive à plusieurs niveaux est essentielle

La sécurisation des systèmes d’IA ne se fera pas à l’aide d’une seule solution technique. Elle nécessite une défense par couches, au niveau de la conception, du déploiement et des opérations. Les recherches menées par l’université Ben Gurion sont claires : les modèles de protection ne permettent pas, à eux seuls, de gérer efficacement les jailbreaks. La solution n’est donc pas simplement d’améliorer les garde-fous. Il s’agit d’une architecture à l’échelle du système qui anticipe l’exploitation.

Commencez par données de formation. Si un modèle est exposé pendant la formation à des contenus liés à la fabrication de bombes, au blanchiment d’argent ou à la manipulation de deepfake, il conserve des schémas qui peuvent être déclenchés ultérieurement. La curation des données d’entraînement doit être délibérée, spécifiquement conçue pour exclure ces risques dès le départ.

Le niveau suivant est l’intergiciel. Des outils tels que Granite Guardian d’IBM et Llama Guard de Meta prouvent que c’est possible. Ils s’interposent entre les utilisateurs et le modèle, examinant les invites et les réponses en temps réel. Il s’agit d’un pare-feu, non pas pour les ordinateurs, mais pour le langage. Lorsqu’il est bien déployé, ce type d’interception réduit considérablement l’exposition.

Une autre approche est le désapprentissage de la machine. Contrairement au recyclage à partir de zéro, cette méthode permet à un modèle d' »oublier » des informations ciblées. Vous corrigez les problèmes sans perdre l’intégralité de votre investissement dans la formation. Enfin, il y a le red teaming. Invitez des tests contradictoires. Payez des primes. Publiez les résultats. Ouvrez votre système à un examen constant, et pas seulement à un examen périodique.

Les dirigeants désireux de déployer des LLM à grande échelle doivent considérer la sécurité comme une caractéristique du produit, et non comme une case à cocher. L’architecture du système, et pas seulement l’alignement du modèle, détermine la résilience. Et rien de tout cela n’est spéculatif. Il existe déjà des exploits connus et des outils disponibles pour les arrêter. Investissez là où les menaces sont réelles.

La nature fondamentale de l’apprentissage tout au long de la vie remet en question la sécurité totale.

Les LLM ne fonctionnent pas comme des logiciels traditionnels. Ils ne suivent pas de règles fixes. Cela les rend utiles, mais aussi imprévisibles. Comme le dit Justin St-Maurice du groupe de recherche Info-Tech, les LLM sont probabilistes. Ils ne savent pas ce qu’ils font, ils calculent simplement ce qu’il faut dire ensuite sur la base de modèles.

Cela signifie que les jailbreaks ne sont pas des piratages de code. Ce sont des changements de contexte. Une invite modifie la façon dont le modèle interprète une demande et, soudain, les garanties éthiques tombent. Il n’y a pas de système isolé à corriger, mais un moteur de raisonnement ouvert conçu pour produire un texte plausible.

Le problème n’est pas seulement technique. Il est conceptuel. Si votre entreprise attend d’un LLM un résultat sûr à 100 %, vous jouez contre la conception du système. Tout ce qui concerne ces modèles, l’échelle, la portée, la flexibilité, vient de leur manque de contraintes déterministes. Dès que vous donnez la priorité à l’adaptabilité créative, vous renoncez au contrôle absolu.

Pour les cadres de haut niveau, la bonne décision est la clarté. Connaissez les limites. Choisissez où et comment déployer les LLM en fonction du niveau de préjudice potentiel en cas de défaillance. Utilisez des logiciels intermédiaires. Surveillez l’utilisation. Interdisez l’accès direct en cas de risque. Et surtout, ne supposez jamais que l’outil sait ce qu’il fait. Car ce n’est pas le cas.

L’urgence de la gouvernance réglementaire et technique est cruciale

Les capacités des grands modèles linguistiques progressent rapidement. Les avantages sont réels : recherche plus rapide, opérations plus efficaces, nouvelles possibilités de produits. Mais les risques le sont tout autant. Selon l’équipe de l’université Ben Gurion, les outils utilisés pour accélérer les progrès peuvent également servir à produire des instructions détaillées pour des activités criminelles ou des campagnes de désinformation.

Il ne s’agit pas d’une préoccupation future. Les abus se produisent aujourd’hui. Et plus ces systèmes deviendront puissants, plus il sera difficile d’en contenir les résultats sans une application et une surveillance externes. Les technologues peuvent fournir des outils, mais cela ne suffit pas. La réglementation, les normes et les politiques publiques doivent évoluer en parallèle, et rapidement.

Leur recommandation est claire : traitez les MLD non alignés comme des actifs à haut risque. Contrôlez l’accès. Appliquez des restrictions d’âge. Auditez les déploiements. Veillez à ce que la responsabilité soit clairement établie en cas d’utilisation abusive, intentionnelle ou non. Il ne s’agit pas de réactions excessives. Il s’agit de cadres de sécurité normalisés dans presque tous les autres secteurs technologiques à fort impact.

Pour les gouvernements, il est temps de classer et de traiter les modèles non filtrés avec le même sérieux que les contenus restreints. Pour les dirigeants d’entreprise, cela signifie qu’ils doivent jouer un rôle actif. N’attendez pas que la réglementation arrive à maturité, prenez les devants en établissant vos garde-fous en interne. Mettez en place des comités de gouvernance. Associez-vous à des experts techniques. Définissez la conformité autour du risque LLM.

Les chercheurs avertissent que la fenêtre pour un leadership proactif est en train de se refermer. Les modèles s’améliorent rapidement, tandis que les stratégies d’utilisation abusive s « étendent à l » échelle mondiale. En l’absence d’alignement entre les constructeurs, les régulateurs et les utilisateurs, l’impact à long terme pourrait être préjudiciable sur les plans économique, politique et social.

Dans toute technologie à forte incidence, le leadership est synonyme d’action en avant. L’action responsable consiste maintenant à guider la manière dont ces outils sont contrôlés, appliqués et rendus sûrs pour une utilisation généralisée. Ce qui est en jeu, ce ne sont pas seulement les perturbations techniques. Il s’agit de la confiance institutionnelle. Et une fois que la confiance est rompue, il est difficile de se défaire de l’impact.

Faits marquants

• Les LLM sont faciles à pirater malgré les mesures de protection : La plupart des systèmes d’IA peuvent encore être manipulés pour produire des contenus nuisibles ou illégaux par le biais de jailbreaks basés sur des invites. Les dirigeants ne doivent pas supposer que les filtres intégrés offrent une protection suffisante et doivent évaluer régulièrement la vulnérabilité des modèles.
• Les LLM à code source ouvert amplifient les risques incontrôlés : Une fois que les LLM non censurés sont publiés, ils ne peuvent plus être corrigés et peuvent être partagés librement, ce qui accroît les risques d’utilisation abusive. Les dirigeants doivent traiter les déploiements de logiciels libres avec une attention particulière et appliquer des politiques de confinement avant l’adoption.
• Une défense à plusieurs niveaux est essentielle pour l’entreprise : S’appuyer uniquement sur des contrôles de sécurité au niveau du modèle est insuffisant. Les dirigeants doivent mettre en œuvre des défenses à plusieurs niveaux, y compris des données d’entraînement, des pare-feu intermédiaires, le désapprentissage automatique, le red teaming et des cadres de gouvernance interne.
• La conception de l’IA limite l’application complète de la sécurité : Parce que les LLM sont probabilistes et non basés sur des règles, ils ne peuvent pas distinguer de manière fiable les contextes nuisibles des contextes acceptables. Les dirigeants doivent prévoir un contrôle et une surveillance continus plutôt que de s’attendre à un confinement permanent.
• La gouvernance de l’IA nécessite une action immédiate : En l’absence d’orientations réglementaires et politiques rapides, l’utilisation abusive des MLD risque de s’intensifier rapidement. Les dirigeants doivent mettre en place des structures internes de responsabilité en matière d’IA et se préparer à s’aligner sur les exigences réglementaires à venir.