Les journaux de prompts sont une faille en attente

Les journaux de prompts semblent inoffensifs jusqu’à ce qu’on les lise.

Du point de vue de l’ingénierie, consigner les prompts est tentant. Cela aide à déboguer les échecs. Cela aide à reproduire les plaintes. Cela aide à surveiller les abus. Cela aide à améliorer les prompts. Cela aide à répondre à la question éternelle : « Pourquoi le modèle a-t-il fait ressembler le produit à un grille-pain hanté ? »

Du point de vue de la confidentialité, les journaux de prompts sont une intention brute. Ils peuvent contenir des noms de clients, des idées de campagne, des fantasmes personnels, un contexte médical, des litiges juridiques, une stratégie produit, des noms de personnes réelles, des lieux et des instructions liées à des images téléversées. Dans la génération d’images, les prompts expliquent souvent la partie sensible que l’image finale ne fait qu’effleurer.

Une violation des journaux de prompts peut donc être pire qu’une violation des sorties. Les sorties peuvent être ambiguës. Les prompts sont souvent explicites. Ils montrent ce que l’utilisateur a demandé, ce qu’il cherchait à dissimuler, ce qu’il voulait modifier et ce qu’il a essayé avant de se contenter de la version acceptable.

C’est pourquoi « nous ne journalisons que du texte » n’est pas rassurant. Le texte peut être la carte vers l’image. Un prompt disant « supprimez le logo du concurrent de la maquette d’emballage non publiée » est sensible sur le plan commercial même si aucun fichier image ne fuit. Un prompt disant « faites en sorte que ma photo de profil ait l’air moins fatiguée » est personnel même si la sortie n’est jamais stockée.

L’approche la plus sûre consiste à séparer le débogage opérationnel de la conservation du contenu. Journalisez les identifiants de tâche, les horaires, les versions du modèle, les codes d’erreur, l’utilisation de jetons ou de crédits, les événements de file d’attente et les métadonnées ne portant pas sur le contenu. Lorsque la capture de contenu est réellement nécessaire pour lutter contre les abus ou pour le support, rendez-la étroite, autorisée, limitée dans le temps et visible dans la politique.

Les développeurs peuvent objecter que cela rend le débogage plus difficile. C’est vrai. La confidentialité rend souvent le débogage paresseux plus difficile. Ce n’est pas une tragédie ; c’est une contrainte de conception. Mettez en place une capture diagnostique explicite, consentie par l’utilisateur, pour les cas limites plutôt que de conserver indéfiniment l’historique privé des prompts de tout le monde.

Les équipes sécurité devraient modéliser les menaces liées aux journaux de prompts comme s’il s’agissait de données sensibles de clients. Qui peut les interroger ? Sont-ils copiés dans des analyses ? Sont-ils inclus dans des rapports de crash ? Sont-ils envoyés à des fournisseurs d’observabilité ? Sont-ils consultables par le support ? Sont-ils conservés plus longtemps que les images elles-mêmes ?

Si les prompts peuvent reconstituer un travail privé, ils ne sont pas des journaux inoffensifs. Ce sont des éléments de violation en attente d’un rendez-vous dans le calendrier.

Pour aller plus loin : L’historique des prompts est une donnée produit, que vous l’appeliez ainsi ou non, Le plaidoyer pour zéro historique de prompts, et Ce qu’une API d’images IA ne devrait jamais stocker.