Protection des invites contre les fuites de données de LLM

Opinion Une soumission IBM NeurIPS 2024 intéressante de fin 2024 réapparue sur Arxiv la semaine dernière. Elle propose un système capable d’intervenir automatiquement pour protéger les utilisateurs de soumettre des informations personnelles ou sensibles dans un message lorsqu’ils ont une conversation avec un grand modèle de langage (LLM) tel que ChatGPT.

Exemples de mock-up utilisés dans une étude d’utilisateurs pour déterminer les moyens par lesquels les personnes préfèrent interagir avec un service d’intervention de prompt. Source : https://arxiv.org/pdf/2502.18509

Les mock-ups ci-dessus ont été utilisés par les chercheurs d’IBM dans une étude pour tester les frictions potentielles des utilisateurs avec ce type d’« ingérence ».

Bien que peu de détails soient donnés sur la mise en œuvre de l’interface graphique utilisateur, on peut supposer que cette fonctionnalité pourrait être intégrée à un module complémentaire de navigateur communiquant avec un cadre LLM « pare-feu » local ; ou qu’une application pourrait être créée pour s’intégrer directement à (par exemple) l’API OpenAI, recréant efficacement le programme autonome téléchargeable d’OpenAI pour ChatGPT, mais avec des garanties supplémentaires.

Cela étant dit, ChatGPT lui-même censure automatiquement les réponses aux invites qu’il perçoit comme contenant des informations critiques, telles que des détails bancaires :

ChatGPT refuse de s’engager avec des invites qui contiennent des informations de sécurité critiques perçues, telles que des détails bancaires (les détails de l’invite ci-dessus sont fictifs et non fonctionnels). Source : https://chatgpt.com/

Cependant, ChatGPT est beaucoup plus tolérant en ce qui concerne les différents types d’informations personnelles – même si la diffusion de telles informations de quelque manière que ce soit ne peut pas être dans le meilleur intérêt de l’utilisateur (dans ce cas, peut-être pour diverses raisons liées au travail et à la divulgation) :

L’exemple ci-dessus est fictif, mais ChatGPT n’hésite pas à engager une conversation avec l’utilisateur sur un sujet sensible qui constitue un risque potentiel pour la réputation ou les gains (l’exemple ci-dessus est totalement fictif).

Dans ce cas, il aurait peut-être été préférable d’écrire : ‘Quelle est la signification d’un diagnostic de leucémie sur la capacité d’une personne à écrire et sur sa mobilité ?’

Le projet IBM identifie et réinterprète de telles demandes d’une posture « personnelle » à une posture « générique ».

Schéma du système IBM, qui utilise des LLM locaux ou des heuristiques basées sur le traitement automatique du langage naturel pour identifier les matériaux sensibles dans les invites potentielles.

Cela suppose que les matériaux recueillis par les LLM en ligne, à ce stade nascent de l’adoption enthousiaste du public de l’IA de conversation, ne seront jamais transmis à des modèles ultérieurs ou à des cadres publicitaires ultérieurs qui pourraient exploiter les requêtes de recherche basées sur l’utilisateur pour fournir une publicité ciblée potentielle.

Bien qu’aucun système ou disposition de ce type ne soit connu actuellement, il n’était pas non plus disponible au début de l’adoption d’Internet dans les années 90 ; depuis, le partage d’informations entre domaines pour alimenter la publicité personnalisée a conduit à divers scandales, ainsi qu’à paranoïa.

Par conséquent, l’histoire suggère qu’il serait préférable de nettoyer les invites LLM maintenant, avant que ces données ne s’accumulent en volume, et avant que nos soumissions LLM basées ne finissent par être dans des bases de données cycliques permanentes et/ou des modèles, ou d’autres structures et schémas basés sur l’information.

Rappelez-vous moi ?

Un facteur qui pèse contre l’utilisation d’invites LLM « génériques » ou nettoyées est que, franchement, la possibilité de personnaliser une API LLM coûteuse telle que ChatGPT est assez convaincante, au moins à l’état actuel de l’art – mais cela peut impliquer l’exposition à long terme d’informations privées.

Je demande souvent à ChatGPT de m’aider à formuler des scripts Windows PowerShell et des fichiers BAT pour automatiser les processus, ainsi que sur d’autres questions techniques. À cette fin, je trouve utile que le système se souvienne définitivement des détails sur le matériel que j’ai disponible ; mes compétences techniques existantes (ou leur absence) ; et divers autres facteurs environnementaux et règles personnalisées :

ChatGPT permet à un utilisateur de développer un « cache » de souvenirs qui seront appliqués lorsque le système considère les réponses aux invites futures.

Inévitablement, cela conserve des informations sur moi stockées sur des serveurs externes, soumises à des conditions et des termes qui peuvent évoluer avec le temps, sans aucune garantie que OpenAI (bien que cela puisse être tout autre fournisseur LLM majeur) respecte les termes qu’il établit.

En général, cependant, la capacité de construire un cache de souvenirs dans ChatGPT est la plus utile en raison de la fenêtre d’attention limitée des LLM en général ; sans embeddings personnalisés à long terme, l’utilisateur se sent, frustrant, qu’il converse avec une entité souffrant d’amnésie antérograde.

Il est difficile de dire si les nouveaux modèles seront éventuellement suffisamment performants pour fournir des réponses utiles sans avoir besoin de mettre en cache des souvenirs, ou de créer des GPT personnalisés stockés en ligne.

Amnésie temporaire

Bien qu’il soit possible de rendre les conversations ChatGPT « temporaires », il est utile d’avoir l’historique de la conversation comme référence qui peut être distillée, lorsque le temps le permet, dans un enregistrement local plus cohérent, peut-être sur une plate-forme de prise de notes ; mais dans tous les cas, nous ne pouvons pas savoir exactement ce qui arrive à ces « conversations jetables » (bien que OpenAI déclare qu’elles ne seront pas utilisées pour la formation, il ne déclare pas qu’elles sont détruites), sur la base de l’infrastructure ChatGPT.

Toutes les informations que nous possédons, c’est que les conversations ne figurent plus dans notre historique lorsque « Temporary chats » est activé dans ChatGPT.

Diverses controverses récentes indiquent que les fournisseurs d’API tels qu’OpenAI ne devraient pas nécessairement être laissés en charge de la protection de la vie privée de l’utilisateur, y compris la découverte de l’émergence de la mémorisation, indiquant que les LLM plus grands sont plus susceptibles de mémoriser certains exemples de formation en entier, et augmentant le risque de divulgation de données spécifiques à l’utilisateur – parmi d’autres incidents publics qui ont persuadé une multitude de grandes entreprises, telles que Samsung, à interdire les LLM pour une utilisation interne.

Pensez différemment

Cette tension entre l’utilité extrême et le risque potentiel manifeste des LLM nécessitera des solutions ingénieuses – et la proposition d’IBM semble être un modèle de base intéressant dans cette ligne.

Trois reformulations basées sur IBM qui équilibrent l’utilité contre la confidentialité des données. Dans la bande la plus basse (rose), nous voyons une invite qui est au-delà de la capacité du système à la nettoyer de manière significative.

L’approche d’IBM intercepte les paquets sortants vers un LLM au niveau du réseau et les réécrit au besoin avant que l’original ne puisse être soumis. Les intégrations GUI plus élaborées présentées au début de l’article ne sont que des illustrations de l’endroit où une telle approche pourrait aller, si elle était développée.

Bien sûr, sans une agence suffisante, l’utilisateur peut ne pas comprendre qu’il reçoit une réponse à une reformulation légèrement modifiée de sa soumission d’origine. Ce manque de transparence est équivalent à un pare-feu du système d’exploitation qui bloque l’accès à un site Web ou à un service sans informer l’utilisateur, qui peut alors à tort chercher d’autres causes du problème.

Invites en tant que passifs de sécurité

La perspective de « l’intervention d’invite » se compare bien à la sécurité de Windows OS, qui a évolué d’un patchwork de produits commerciaux (optionnellement installés) dans les années 90 à un ensemble non optionnel et rigoureusement appliqué d’outils de défense réseau qui viennent avec une installation Windows, et qui nécessitent certains efforts pour les désactiver ou les atténuer.

Si la sanitisation des invites évolue comme les pare-feu réseau l’ont fait au cours des 30 dernières années, la proposition du document d’IBM pourrait servir de plan directeur pour l’avenir : déployer un LLM entièrement local sur la machine de l’utilisateur pour filtrer les invites sortantes dirigées vers des API LLM connues. Ce système devrait naturellement intégrer des cadres GUI et des notifications, donnant aux utilisateurs le contrôle – à moins que les politiques administratives ne le contrecarrent, comme c’est souvent le cas dans les environnements d’entreprise.

Les chercheurs ont effectué une analyse d’une version open source du jeu de données ShareGPT pour comprendre à quelle fréquence la confidentialité contextuelle est violée dans des scénarios du monde réel.

Llama-3.1-405B-Instruct a été utilisé comme modèle « juge » pour détecter les violations de l’intégrité contextuelle. À partir d’un grand ensemble de conversations, un sous-ensemble de conversations à tour unique a été analysé en fonction de la longueur. Le modèle juge a ensuite évalué le contexte, les informations sensibles et la nécessité d’accomplir la tâche, conduisant à l’identification des conversations contenant des violations potentielles d’intégrité contextuelle.

Un sous-ensemble plus petit de ces conversations, qui ont démontré des violations définitives de la confidentialité contextuelle, a été analysé plus en détail.

Le cadre lui-même a été mis en œuvre à l’aide de modèles plus petits que les agents de conversation typiques tels que ChatGPT, pour permettre le déploiement local via Ollama.

Schéma du système d’intervention d’invite.

Les trois LLM évalués étaient Mixtral-8x7B-Instruct-v0.1 ; Llama-3.1-8B-Instruct ; et DeepSeek-R1-Distill-Llama-8B.

Les invites des utilisateurs sont traitées par le cadre en trois étapes : identification du contexte ; classification des informations sensibles ; et reformulation.

Deux approches ont été mises en œuvre pour la classification des informations sensibles : dyna et structurée : la classification dynamique détermine les détails essentiels en fonction de leur utilisation dans une conversation spécifique ; la classification structurée permet de spécifier une liste pré définie d’attributs sensibles qui sont toujours considérés comme non essentiels. Le modèle reformule l’invite si elle détecte des détails sensibles non essentiels en les supprimant ou en les reformulant pour minimiser les risques de confidentialité tout en maintenant l’utilité.

Règles de la maison

Bien que la classification structurée en tant que concept ne soit pas bien illustrée dans le document d’IBM, elle est la plus proche de la méthode « Définitions de données privées » dans l’initiative Private Prompts, qui fournit un programme autonome téléchargeable qui peut réécrire les invites – bien qu’il n’ait pas la capacité d’intervenir directement au niveau du réseau, comme l’approche d’IBM le fait (au lieu de cela, l’utilisateur doit copier et coller les invites modifiées).

L’exécutable Private Prompts permet une liste de substitutions alternatives pour le texte saisi par l’utilisateur.

Dans l’image ci-dessus, nous pouvons voir que l’utilisateur Private Prompts peut programmer des substitutions automatisées pour les instances d’informations sensibles. Dans les deux cas, pour Private Prompts et la méthode d’IBM, il semble peu probable qu’un utilisateur avec suffisamment de présence d’esprit et d’insight personnel pour établir une telle liste ait réellement besoin de ce produit – bien qu’il puisse être construit au fil du temps à mesure que les incidents se produisent.

Dans un rôle d’administrateur, la classification structurée pourrait fonctionner comme un pare-feu ou un filet de censure pour les employés ; et dans un réseau domestique, il pourrait, avec certaines ajustements difficiles, devenir un filtre de réseau domestique pour tous les utilisateurs du réseau ; mais en fin de compte, cette méthode est sans doute redondante, puisqu’un utilisateur qui pourrait configurer cela correctement pourrait également s’autocensurer efficacement dès le départ.

L’opinion de ChatGPT

Puisque ChatGPT a récemment lancé son outil de recherche approfondie pour les utilisateurs payants, j’ai utilisé cette fonctionnalité pour demander à ChatGPT d’examiner la littérature connexe et de me donner un « cynique » sur le document d’IBM. J’ai reçu la réponse la plus défensive et dérisoire que le système ait jamais donnée lorsqu’on lui a demandé d’évaluer ou d’analyser une nouvelle publication :

ChatGPT-4o a une faible opinion du projet IBM.

‘Si les utilisateurs ne font pas confiance à OpenAI, Google ou Anthropic pour gérer leurs données de manière responsable,’ ChatGPT soutient. ‘pourquoi feraient-ils confiance à une couche de logiciel tiers située entre eux et l’IA ? L’intermédiaire lui-même devient un nouveau point de défaillance – potentiellement enregistrant, traitant de manière incorrecte ou même faisant fuiter des données avant qu’elles n’atteignent même le LLM. Cela ne résout rien si cela crée simplement une nouvelle entité pour exploiter les données des utilisateurs.’

Cette objection semble intéressée et non pertinente, étant donné l’histoire de projets open source qui bénéficient réellement aux utilisateurs finaux grâce aux efforts concertés et à long terme des développeurs et des contributeurs de la communauté ; et étant donné le potentiel croissant des appareils mobiles pour exécuter – et même former – des LLM légers. Certainement dans ce cas, l’utilisation n’est pas terriblement exigeante.

Ensuite, ChatGPT manque confiantement le point d’avoir un LLM léger pour fournir une supervision de la saisie vers un LLM commercial qui ne pourrait pas être exécuté sur une machine locale (parce que le LLM est trop grand, et permettre l’accès local est trop risqué pour l’entreprise qui le fabrique) :

‘Un filtrage de confidentialité efficace nécessite de comprendre l’entrée avant de décider ce qui doit être supprimé. Si un intermédiaire est suffisamment intelligent pour reconnaître les données sensibles (noms, adresses, détails financiers), alors il traite et analyse déjà ces données – ce qui signifie qu’il doit stocker ou examiner la chose même qu’il est censé effacer.

‘Cela introduit une contradiction : a) Un filtre stupide (substitution de base de regex) sera inefficace et manquera les risques de confidentialité subtils. b) Un filtre intelligent (réécriveur alimenté par LLM) doit traiter l’entrée complète, ce qui le rend tout aussi dangereux que le LLM d’origine.

‘Si vous faites confiance à l’intermédiaire pour lire et réécrire vos entrées, pourquoi ne pas faire confiance au LLM lui-même ?’

La réponse à la dernière question ici est que le LLM local est destiné à être entièrement du côté de l’utilisateur, et inévitablement open source, avec un besoin minimal ou nul d’accès au réseau. Un équivalent commercial, cependant bien intentionné au départ, serait éventuellement vulnérable aux changements et modifications des conditions de service, alors qu’une licence open source appropriée empêcherait ce type de ‘corruption inévitable’.

ChatGPT soutient en outre que la proposition d’IBM « brise l’intention de l’utilisateur », puisqu’elle pourrait interpréter une invite dans une alternative qui affecte son utilité. Cependant, il s’agit d’un problème beaucoup plus large dans la sanitisation des invites, et non spécifique à ce cas d’utilisation particulier.

En fin de compte (en ignorant sa suggestion d’utiliser des LLM locaux « à la place », ce qui est exactement ce que le document d’IBM propose), ChatGPT a estimé que la méthode d’IBM représente un obstacle à l’adoption en raison du « frottement de l’utilisateur » de la mise en œuvre de méthodes d’édition et d’avertissement dans un chat.

Ici, ChatGPT peut avoir raison ; mais si une pression significative est exercée en raison d’incidents publics supplémentaires, ou si les profits dans une zone géographique sont menacés par une réglementation croissante (et que l’entreprise refuse de simplement abandonner la région touchée), l’histoire de la technologie grand public suggère que les garanties finiront par ne plus être optionnelles de toute façon.

Conclusion

Nous ne pouvons pas raisonnablement attendre qu’OpenAI mette en œuvre des garanties du type de celles proposées dans le document d’IBM, et dans le concept central qui se trouve derrière ; du moins pas efficacement.

Et certainement pas mondialement ; tout comme Apple bloque certaines fonctionnalités d’iPhone en Europe, et que LinkedIn a des règles différentes pour exploiter les données des utilisateurs dans différents pays, il est raisonnable de suggérer qu’une entreprise d’IA fera défaut pour les conditions et les termes les plus rentables qui sont tolérables pour une nation particulière dans laquelle elle opère – dans chaque cas, aux dépens du droit de l’utilisateur à la confidentialité des données, si nécessaire.

Publié pour la première fois jeudi 27 février 2025

Mis à jour jeudi 27 février 2025 15:47:11 en raison d’un lien incorrect lié à Apple – MA