Tech
Logs LLM et RGPD : quelles données conserver ?
Prompts, réponses, métriques : concevez une journalisation LLM utile au débogage, limitée aux données nécessaires et assortie de règles de conservation.
Pour observer une application LLM, commencez par les métriques nécessaires au fonctionnement : identifiant de requête, modèle utilisé, durée et statut. Conserver systématiquement les prompts et réponses crée un autre traitement de données, parfois très personnelles. Un outil de logging ne rend pas, à lui seul, une application conforme au RGPD.
Définir la finalité avant les champs du journal
Écrivez la question que chaque trace doit aider à résoudre : une erreur, une régression de latence ou une consommation inhabituelle. Le principe de minimisation rappelé par la CNIL demande de limiter les données personnelles à ce qui est nécessaire à la finalité. Le fait qu’un SDK puisse tout enregistrer ne justifie pas cette collecte.
La proposition ci-dessous est un point de départ d’ingénierie à adapter à votre contexte, avec la personne responsable de la protection des données lorsque cela s’applique.
| Besoin | Trace proposée | Vérification |
|---|---|---|
| Retrouver une erreur | Identifiant technique et code de statut. | Éviter un identifiant directement nominatif. |
| Suivre les performances | Durée et nom du modèle. | Ne pas confondre métrique et contenu du message. |
| Comprendre une consommation | Compteurs disponibles, par opération. | Limiter la précision et les identifiants au besoin réel. |
| Reproduire un problème de contenu | Cas synthétique ou extrait maîtrisé. | Justifier séparément tout enregistrement de texte réel. |
Protéger le contenu avant qu’il entre dans les logs
Évitez les clés d’API, mots de passe, pièces jointes et messages complets dans les traces ordinaires. Contrôlez aussi les exceptions, les outils de support et les exports : un message retiré d’un journal peut rester présent ailleurs. La fiche de sécurité de la CNIL recommande notamment de protéger les traces et d’éviter d’y dupliquer inutilement les données concernées.
Un filtre par expression régulière peut repérer certains formats ; il ne reconnaît pas tous les récits personnels. Et remplacer un nom par un identifiant ne suffit pas à rendre anonyme un texte dont le contexte permet encore de reconnaître une personne.
Accès, conservation et suppression
Définissez qui peut consulter les traces, comment ces accès sont contrôlés et quand les données sont supprimées. Testez la suppression sur les exports et sauvegardes concernés, pas seulement sur la vue principale de votre outil.
Les recommandations de la CNIL sur la journalisation portent sur des finalités et contextes précis. Leur durée indicative pour les traces de sécurité n’est pas une autorisation générale de garder toutes les conversations LLM. Documentez une durée adaptée et examinez les prestataires ou transferts éventuels.
Où HILT intervient-il ?
HILT est notre bibliothèque Python open source de journalisation des interactions humain-IA. Son dépôt officiel décrit l’instrumentation du SDK OpenAI et les sorties JSONL ou Google Sheets.
L’instrumentation peut enregistrer le contenu des échanges. Vérifiez donc les champs produits avant de la brancher sur des données réelles. Un fichier local nécessite des règles d’accès et de conservation ; Google Sheets implique aussi d’examiner le partage et le prestataire. HILT fournit un mécanisme de trace, pas une certification juridique.
Une vérification avant la mise en service
- Produisez une requête et une erreur avec des données fictives.
- Inspectez les fichiers, consoles et exports réellement générés.
- Vérifiez qu’aucun secret ou texte inattendu n’apparaît.
- Testez les accès prévus et le mécanisme de suppression.
- Conservez la justification des champs et des durées retenus.
Sources et documentation
Les références utilisées pour cette révision sont accessibles ci-dessous.
