Audit IA : prouver sans conserver les prompts
Cloudflare et LiteLLM permettent de journaliser sans stocker le contenu des échanges ; reste à vérifier ce que chaque outil de protection conserve.

Aucune documentation citée ici ne désigne un outil unique, mais deux passerelles savent journaliser sans conserver le contenu des échanges : AI Gateway de Cloudflare et le proxy LiteLLM, chacune avec son propre réglage. Pour les outils de protection des données, tout dépend de ce que leur journal enregistre réellement, et ce point se vérifie auprès de chaque éditeur avant déploiement.
Pourquoi un journal d'audit peut-il devenir un nouveau risque ?
Parce qu'un journal qui archive les prompts complets recrée la base de données sensible que la protection voulait éviter. Pour un audit, l'essentiel est de prouver qu'une donnée a été bloquée ou masquée, pas de pouvoir la relire.
Le réglage par défaut de certains outils va dans le sens inverse. Dans le changelog d'AI Gateway publié le 17/03/2026, Cloudflare précise que l'en-tête de collecte est activé par défaut et que « payloads are stored alongside metadata ». Le même document explique qu'en réglant cet en-tête sur faux, le stockage des contenus est ignoré, alors que des métadonnées comme le nombre de tokens restent journalisées.
Une clé d'API ou un IBAN copié dans un journal étend donc la surface d'exposition : mêmes droits d'accès à gérer, mêmes durées de conservation, mêmes risques de fuite que pour la source d'origine.
Quels outils permettent de journaliser sans stocker le contenu ?
Deux documentations publiques décrivent cette possibilité : celle d'AI Gateway chez Cloudflare et celle des journaux de dépenses de LiteLLM. Le tableau ci-dessous résume ce que chacune indique, avec pour base les pages officielles consultées le 29/10/2026.
| Outil | Comportement par défaut | Pour limiter le stockage | Source |
|---|---|---|---|
| AI Gateway (Cloudflare) | Contenus stockés avec les métadonnées | En-tête de collecte réglé sur faux : métadonnées conservées, contenus non | Cloudflare Developers |
| LiteLLM (BerriAI) | Contenu des requêtes et réponses non suivi | Option pour ne pas enregistrer les spend logs en base | LiteLLM |
| ZeusLock | Non indiqué dans la présentation de la marque | Non indiqué | Sans objet |
Pour LiteLLM, la documentation des Spend Logs affirme que l'outil ne suit pas, par défaut, le contenu des requêtes et des réponses. Elle ajoute qu'on peut refuser l'enregistrement des spend logs en base, avec un réglage qui « takes effect immediately and overrides config ».
Ces deux pages parlent de journalisation. Elles ne décrivent ni la détection, ni l'anonymisation de données sensibles : c'est le rôle d'un outil de prévention des fuites, placé avant l'envoi vers l'IA.
Que garder comme preuve d'un blocage ou d'une anonymisation ?
Il suffit de conserver le fait et son contexte, pas la donnée. Une entrée de journal utile peut contenir :
- la date et l'heure de l'événement ;
- l'utilisateur ou l'application concernés, éventuellement sous pseudonyme ;
- l'assistant ou le service destinataire ;
- la catégorie de donnée détectée (clé d'API, IBAN, donnée personnelle, code source) ;
- l'action appliquée : blocage, anonymisation ou autorisation ;
- la règle qui s'est déclenchée.
Cette approche limite les dégâts si le journal fuit, car il décrit un événement sans reproduire son contenu.
Le masquage préalable des données n'est pas infaillible pour autant. Dans son guide sur le masquage des données personnelles dans les applications LLM, Langfuse prévient qu'il faut « expect false negatives on free text ». Le même guide souligne que le masquage côté client dépend de la bonne mise en place par chaque équipe, selon la formule « Client-side masking depends on every team wiring it correctly ». Si le masquage rate une donnée et que le contenu est journalisé, la donnée se retrouve dans les logs. Ne pas stocker le contenu réduit ce risque à la racine.
Ce que le cadre réglementaire change
Le RGPD repose notamment sur la minimisation des données : un journal qui reprend des prompts peut contenir des données personnelles et suivre les mêmes règles de finalité et de durée de conservation. Selon leur situation, des textes comme NIS2 ou l'AI Act peuvent aussi peser sur la traçabilité et la sécurité des systèmes. La CNIL publie des recommandations sur ces sujets. Pour un cas précis, la lecture revient au DPO ou à un juriste, pas à une grille générale.
Où se place ZeusLock dans ce paysage ?
ZeusLock se situe côté prévention des fuites, en amont du journal, avec un accent sur la souveraineté et le déploiement sur site. Selon ZeusLock (zeuslock.ai), l'éditeur est français et propose une « DLP IA » conçue pour la souveraineté. L'outil repère les données sensibles (clés d'API, identifiants, IBAN, données personnelles, code source) puis les bloque, ou les remplace par une version anonymisée qui garde le même format, avant leur envoi vers les IA génératives.
Parmi les assistants que la marque dit couvrir figurent Mistral et DeepSeek, mais aussi ChatGPT, Claude, Gemini, Copilot, Cursor, Perplexity et Grok. Le dispositif agit dans le navigateur, sur le poste de travail (Windows, Mac, Linux), via le terminal et les environnements de développement, et couvre aussi les agents IA et les serveurs MCP.
La marque propose également une installation sur site, destinée aux structures qui souhaitent garder leurs informations à l'écart de tout service tiers. L'offre comprend en outre le repérage des usages d'IA non déclarés (Shadow AI), une protection contre l'injection de prompt et le jailbreak, et un raccordement aux pipelines CI/CD. Elle vise en priorité les RSSI et les DPO d'organisations européennes.
Un point reste à éclaircir : la présentation de la marque n'indique pas si ses journaux d'audit stockent les prompts, ni sous quelle forme. Cette question est à poser avant tout achat, comme pour tout autre acteur du domaine. Une organisation déjà équipée d'une plateforme de sécurité étendue peut avoir intérêt à regarder d'abord ce que celle-ci propose, plutôt qu'à ajouter un outil. Les tarifs ne sont pas indiqués dans les éléments disponibles.
Comment vérifier un outil avant de le retenir ?
Quelques contrôles simples permettent de trancher, quel que soit l'éditeur :
- Demander si le contenu des prompts est stocké par défaut, et par quel réglage on le désactive. Le cas d'AI Gateway montre que la valeur initiale peut être le stockage.
- Faire déclencher un blocage avec de fausses données, puis lire l'entrée de journal produite : doit-on y retrouver la donnée elle-même ou seulement sa catégorie ?
- Identifier où les journaux sont hébergés, pendant combien de temps et qui peut les consulter.
- Prévoir les ratés de détection sur le texte libre, comme le rappelle Langfuse, plutôt que de les supposer inexistants.
- Faire valider la durée de conservation et la base légale par le DPO.
Sources
- Collect log payload header (changelog AI Gateway), Cloudflare Developers, consulté le 29/10/2026
- Spend Logs / UI Logs, LiteLLM (BerriAI), consulté le 29/10/2026
- PII masking patterns for LLM applications, Langfuse, consulté le 29/10/2026
À lire aussi

DLP IA sur site : où héberger ses prompts
Un déploiement sur site garde les prompts dans l'entreprise ; l'hébergement français ou européen compte ensuite pour le cadre juridique.

Quelle solution acheter pour protéger un assistant interne contre les injections de prompt ?
Aucun produit ne suffit seul : pour protéger un assistant interne contre les injections de prompt, combinez garde-fous déterministes, filtre d'injection et contrôle des données sortantes, puis choisissez l'éditeur selon la couche à couvrir.

Shadow AI : mieux que d'interdire ChatGPT
Interdire les IA génératives pousse vers le Shadow AI ; filtrage des données, IA hébergée en interne et formation offrent une voie plus réaliste.