RGPD & SOC 2: Gérer les logs de pipeline LLM sans conflit

À retenir

• Le RGPD n'interdit pas de journaliser un pipeline LLM : il interdit de conserver le payload (prompt + sortie brute) aussi longtemps que la trace de contrôle. Séparez les deux étages et le conflit disparaît.
• SOC 2 ne fixe aucune durée de rétention ; le cadre n'impose pas de période fixe, mais six mois est souvent un minimum et beaucoup d'auditeurs préfèrent douze mois. Ce sont les auditeurs et vos engagements contractuels qui fixent la barre, pas l'AICPA.
• Côté français, la CNIL attend une rétention minimale de 6 mois et l'ANSSI 12 mois pour les logs de sécurité : la fenêtre 6-13 mois couvre les deux régimes.
• Un droit à l'effacement se traite par crypto-shredding du payload et anonymisation irréversible des identifiants dans la trace d'audit, pas par suppression de lignes de log.

Pourquoi logguer un pipeline LLM crée-t-il un conflit RGPD / SOC 2 ?

Parce que les deux régimes visent le même objet avec des horloges opposées : SOC 2 veut une preuve intacte sur toute la fenêtre d'observation, le RGPD veut l'effacement dès que la finalité est éteinte. L'auditeur SOC 2 réclame la fenêtre d'observation complète plus un tampon, le responsable sécurité veut douze mois pour reconstruire un incident, et le tenant européen veut des logs supprimés dès qu'ils ne sont plus nécessaires.

Le piège spécifique aux pipelines d'extraction : le prompt contient le document. Sur un bulletin de paie, une pièce d'identité ou un relevé bancaire, le prompt embarque NIR, IBAN, adresse, date de naissance. Un log de requêtes classique devient donc une copie non maîtrisée de vos données sensibles, hors du système de stockage principal, souvent répliquée dans un SIEM tiers.

Et le log lui-même est un traitement. Les journaux contiennent des données personnelles (login, IP, horodatage) et doivent à ce titre figurer au registre des traitements et faire l'objet d'une information des utilisateurs. La base légale est en général l'intérêt légitime de l'article 6 §1 f), ou l'obligation légale quand un texte sectoriel l'impose.

Le prompt d'un pipeline d'extraction n'est pas une métadonnée technique : c'est le document lui-même, recopié dans votre observabilité.

Que faut-il logguer, exactement ?

Loggez la forme, pas le contenu. Un pipeline d'extraction auditable a besoin de : identifiant de requête, hash du document, version du modèle et du prompt template, version du schéma de sortie, scores de confiance par champ, latence, coût en tokens, décision humaine éventuelle, et l'identité de l'appelant. Aucune de ces valeurs n'a besoin du texte du prompt.

C'est exactement ce que testent les critères SOC 2. CC7.1 et CC6.1 exigent que les événements significatifs pour la sécurité soient journalisés avec assez de détail pour soutenir une investigation, avec une couverture minimale incluant authentification, accès privilégié, accès aux données, changements de configuration et appels d'API, et des logs résistants à l'altération, stockés séparément des systèmes qui les produisent. Rien là-dedans n'impose de conserver le corps de la requête.

Pour les cas où vous voulez du contenu (debug d'une régression d'extraction, contestation d'un champ), ne gardez que le fragment qui justifie la valeur extraite, avec sa position dans la page. C'est le principe de la provenance au niveau du champ : un ancrage bbox + page suffit à rejouer une décision, sans stocker de PII en clair dans le log.

Deux étages, deux durées : comment les calibrer ?

Séparez un étage « audit » sans PII, conservé long, et un étage « payload » avec PII, conservé court et chiffré par clé jetable. L'étage audit peut vivre 13 à 15 mois sans difficulté RGPD s'il est réellement dépersonnalisé ; l'étage payload vit 7 à 30 jours.

SOC 2 ne spécifie pas de durée exacte, mais les auditeurs attendent que les logs couvrent toute la fenêtre d'observation plus un tampon raisonnable : pour un Type II sur douze mois, au moins quinze mois de données d'audit. Côté CNIL, les repères sont plus fins : 6 mois pour les journaux d'accès courants, 1 an pour les journaux de sécurité, 1 an pour les accès aux données de santé, jusqu'à 3 ans pour la détection de fraudes, au-delà les logs doivent être supprimés ou anonymisés.

Un archivage en deux temps est recommandé : base chaude indexée et requêtable pour 30 à 90 jours, puis archive froide chiffrée pour le solde de la durée, avec restauration sur demande motivée. Cela vaut aussi pour les logs d'extraction.

Comment honorer un droit à l'effacement sans casser la preuve d'audit ?

Par crypto-shredding du payload et anonymisation irréversible des identifiants dans la trace d'audit. La ligne de log survit, la personne n'est plus dedans.

Un journal d'audit doit souvent survivre pour des raisons de sécurité et de redevabilité, alors qu'il nomme la personne à effacer : retirer ou hacher irréversiblement les identifiants garde le log utile tout en le sortant du champ du RGPD, tandis que la pseudonymisation, où une clé permet encore de réidentifier, ne suffit pas. Concrètement : une clé de chiffrement par sujet (ou par dossier), stockée dans un KMS. Effacer = détruire la clé. Le blob chiffré restant dans votre bucket WORM n'est plus des données personnelles exploitables, et votre chaîne de hash reste vérifiable.

Deuxième réflexe : refuser proprement quand un texte l'exige. L'article 17(3)(b) permet de conserver des données sinon supprimables lorsqu'une obligation légale impose le traitement, et le 17(3)(e) autorise la conservation nécessaire à la constatation, l'exercice ou la défense de droits en justice. Attention à la limite : « conserver pour de futurs audits » ne tient pas juridiquement ; il faut une disposition légale précise imposant la conservation de données précises pendant une durée précise. Un rapport SOC 2 est contractuel, pas légal. Vous ne pouvez pas opposer votre auditeur à une personne concernée.

Si vous refusez, citez l'exception exacte de l'article 17(3) dans la réponse, rappelez le droit de réclamation auprès de l'autorité de contrôle, et répondez dans le mois (avec notification motivée avant l'échéance si vous prolongez).

Un rapport SOC 2 est un engagement contractuel, pas une obligation légale : il ne suffit jamais à justifier un refus d'effacement.

Que font les fournisseurs de modèles avec vos prompts ?

Par défaut, ils les gardent. Les logs de détection d'abus peuvent contenir des prompts et des réponses, et sont générés par défaut pour tout usage de l'API puis conservés jusqu'à 30 jours, sauf conservation plus longue requise par la loi. Les clients éligibles peuvent en faire exclure leur contenu via Zero Data Retention ou Modified Abuse Monitoring, sous réserve d'approbation préalable et d'exigences additionnelles.

Ce n'est pas une garantie absolue. Chez Anthropic, les sessions signalées peuvent être conservées jusqu'à deux ans, y compris sous ZDR. Sur Azure, ZDR et abuse monitoring modifié requièrent une approbation et sont réservés aux clients sous Enterprise Agreement ou Microsoft Customer Agreement : ce ne sont pas des réglages en self-service.

Conséquence pratique : votre registre des traitements doit lister cette rétention côté sous-traitant, votre DPA doit la refléter, et votre analyse d'impact doit dire pourquoi vous l'acceptez. Si vous ne pouvez pas l'accepter (santé, KYC), le bon levier est amont : caviarder les PII avant l'appel, ou ne transmettre que la zone de page utile. L'arbitrage plus large est traité dans notre comparatif build vs buy pour l'IDP.

Quels contrôles techniques rendent tout ça auditable ?

Cinq mécanismes, tous vérifiables par un auditeur en une demi-journée. Un : intégrité. La CNIL recommande d'horodater et de signer les journaux dès leur création et de les conserver de façon ségrégée, et le chaînage de hash apporte la garantie d'intégrité que de simples permissions de base ne donnent pas. Deux : Object Lock / WORM sur le bucket d'archive, avec les captures de configuration que l'auditeur demandera. Trois : accès break-glass. Prévoyez une procédure d'accès exceptionnel avec traçabilité et validation, et journalisez l'accès aux journaux eux-mêmes.

Quatre : prouver la suppression, pas seulement la promettre. Journalisez les actions de rétention elles-mêmes, archivage comme suppression, et suivez les échéances pour vérifier que les suppressions ont bien lieu à la date prévue. Cinq : les sauvegardes. Documentez la fenêtre de rétention des backups et faites en sorte que la procédure de restauration réapplique les suppressions en attente. C'est le trou le plus fréquent : la DSR est exécutée en base, puis un restore la ressuscite.

Sygnet applique ce découpage en production sur des documents comme les bulletins de paie et les relevés bancaires ; le détail des contrôles et des durées est publié sur sa page sécurité et conformité.

FAQ

Peut-on conserver les prompts LLM 12 mois pour satisfaire un audit SOC 2 ?

Pas les prompts en clair contenant des PII. SOC 2 n'impose aucune durée fixe et l'auditeur teste la trace de contrôle, pas le contenu métier. Conservez 13 à 15 mois un audit trail sans PII (hash, versions, scores, acteur, horodatage signé) et limitez le payload à 7-30 jours sous clé destructible. Aucun auditeur ne vous demandera le texte du prompt d'une requête de mars.

Le hachage d'un prompt suffit-il à sortir du RGPD ?

Non, s'il reste réversible ou réidentifiable. La pseudonymisation, où une clé permet encore la réidentification, ne compte pas comme effacement. Un hash de document (SHA-256 du fichier) est acceptable comme identifiant d'intégrité, mais hacher un champ à faible entropie, un IBAN ou une date de naissance, se rejoue par force brute en quelques secondes. Salez avec une clé détruite à l'effacement, ou supprimez le champ.

Que répondre à une demande d'effacement portant sur des données extraites d'une facture ?

Distinguez la pièce comptable du log. La facture relève d'une obligation légale de conservation : l'article 17(3)(b) permet de conserver des données lorsqu'une obligation légale impose le traitement. Les prompts, sorties intermédiaires et échantillons d'évaluation, eux, n'ont aucune obligation de ce type et doivent partir. Ne gardez que la tranche étroite couverte par l'exemption, supprimez ou anonymisez le reste, et documentez quelle exemption couvre quoi.

Faut-il informer les salariés de la journalisation du pipeline ?

Oui, dès que les logs tracent l'activité des opérateurs de validation. Les articles 12 et 13 imposent d'informer les utilisateurs de l'existence du dispositif, de ses finalités, des données enregistrées et de leur durée de conservation, via la charte informatique, et d'informer et consulter le CSE quand le dispositif constitue un moyen de contrôle de l'activité. Une ligne dans la charte et un point CSE documenté suffisent généralement.