Vous avez demandé à votre assistant IA de résumer un contrat confidentiel ou d'analyser des données clients sensibles. La réponse est instantanée, utile, mais une question reste en suspens : que se passe-t-il ensuite avec ces mots ? Dans le monde des grands modèles de langage (LLM), chaque prompt et chaque log ne disparaissent pas dans le vide. Ils sont capturés, stockés, parfois analysés pour améliorer le modèle, puis... enfin supprimés ? Ou pas.
C'est ici que la réalité technique heurte les exigences légales. Les politiques de conservation et de suppression des prompts LLM sont devenues le nerf de la guerre entre l'innovation rapide et la conformité stricte. Si vous pensez qu'un clic sur « supprimer » efface immédiatement vos données, détrompez-vous. Le processus est bien plus complexe, souvent retardé par des mécanismes de sécurité et juridiques qui peuvent laisser vos données traîner pendant des semaines, voire plus.
Le paradoxe de la suppression immédiate
Dans une application classique, quand vous supprimez un fichier, il va à la corbeille, puis est écrasé. Avec les LLMs, surtout ceux intégrés dans des écosystèmes professionnels comme Microsoft 365 Copilot, la logique est différente. Prenons l'exemple concret de Microsoft. Leur système ne supprime pas les messages dès que l'utilisateur clique sur « supprimer ». Au lieu de cela, les messages sont déplacés vers un dossier intermédiaire appelé SubstrateHolds, un espace de stockage temporaire conçu pour garantir la conformité légale avant la destruction finale.
Pourquoi cette étape supplémentaire ? Parce que les entreprises doivent respecter des obligations légales. Un message peut être soumis à une mise en place judiciaire (Litigation Hold), à une rétention réglementaire ou à une demande de découverte électronique (eDiscovery). Si le système supprimait tout instantanément, une entreprise pourrait perdre des preuves cruciales pour un procès. Ainsi, même après expiration de la période de rétention standard, le message reste dans SubstrateHolds pendant 1 à 7 jours supplémentaires avant qu'une tâche planifiée ne l'efface définitivement.
Les chiffres sont surprenants. Une politique de « supprimer après 1 jour » peut en réalité prendre jusqu'à 16 jours pour être totalement effective. Pourquoi ?
- Jour 1 : L'utilisateur supprime le message.
- Jours 2-8 : Le message est déplacé dans SubstrateHolds (délai technique de 1 à 7 jours).
- Jours 9-16 : Le message attend dans ce dossier au moins 1 jour supplémentaire avant suppression physique (encore 1 à 7 jours).
Conformité RGPD et principes fondamentaux
En Europe, le Règlement Général sur la Protection des Données (RGPD) impose des règles strictes. Le principe de limitation de la finalité signifie que vous ne pouvez garder des données que le temps nécessaire à leur utilisation prévue. Pour les LLMs, cela pose un problème majeur : comment prouver que les prompts contenant des données personnelles ont été supprimés du modèle lui-même, et pas juste de l'historique utilisateur ?
La Commission Nationale de l'Informatique et des Libertés (CNIL) et le Conseil Européen de la Protection des Données insistent sur plusieurs points :
- Minimisation des données : Ne collectez que ce qui est strictement nécessaire.
- Chiffrement : Les données doivent être chiffrées en transit et au repos. Le chiffrement préservant le format (Format-Preserving Encryption) est recommandé pour les champs nécessitant une validation sans exposer le contenu brut.
- Traces auditables : Vous devez pouvoir prouver qui a accédé à quelles données, quand et pourquoi. Ces journaux d'audit doivent eux-mêmes être immuables.
Le piège courant consiste à croire que supprimer le log de conversation suffit. Or, si le modèle a « mémorisé » une information sensible (un numéro de carte bancaire, un diagnostic médical) lors de son entraînement ou de ses mises à jour continues, cette donnée persiste dans les poids du modèle. La suppression du log n'efface pas la mémoire du modèle.
Gestion des données mémorisées par le modèle
C'est le point le plus technique et le plus risqué. Les LLMs ont tendance à mémoriser des informations présentes dans leurs jeux d'entraînement. Si un prompt contenant des données personnellement identifiables (PII) a influencé le modèle, la simple suppression du log ne garantit pas la disparition de l'information.
Pour répondre aux demandes de droit à l'oubli, les organisations doivent mettre en œuvre des techniques avancées :
- Édition de modèle : Modifier localement les poids du réseau neuronal pour réduire l'association entre une requête spécifique et une sortie sensible.
- Oubli de connaissances (Knowledge Unlearning) : Des algorithmes spécifiques visant à retirer l'influence d'un sous-ensemble de données d'entraînement sans retreindre tout le modèle, ce qui serait trop coûteux.
- Retraiment avec jeu nettoyé : Dans les cas graves, il faut retrainir le modèle avec un dataset où les données sensibles ont été purgées.
Architecture de sécurité et contrôle d'accès
Avoir une politique de rétention ne sert à rien si n'importe qui peut lire les logs avant leur suppression. L'OWASP (Open Web Application Security Project) met en garde contre les failles courantes dans les architectures d'agents IA. Voici les piliers d'une architecture sécurisée pour la gestion des prompts :
| Mesure | Objectif | Implémentation Technique |
|---|---|---|
| Contrôle d'accès basé sur les rôles (RBAC) | Limiter l'accès aux seuls responsables conformité | Intégration avec Active Directory / Azure AD, moindre privilège |
| Journalisation immuable | Preuve d'audit non falsifiable | Stockage WORM (Write Once Read Many), hachage blockchain optionnel |
| Anonymisation automatique | Réduire le risque PII dans les logs | Filtres NLP en temps réel avant stockage |
| Chiffrement de bout en bout | Protéger les données en transit et au repos | TLS 1.3, AES-256, clés gérées par le client (BYOK) |
Une bonne pratique essentielle est de séparer les environnements. Les logs de production contenant des vraies données utilisateurs ne doivent jamais servir directement à l'entraînement public sans un cycle de nettoyage rigoureux. Utilisez des environnements sandbox pour tester les nouvelles politiques de rétention avant de les appliquer à grande échelle.
Complexité des environnements multi-cloud
Si votre organisation utilise plusieurs fournisseurs de cloud (AWS Bedrock, Google Vertex AI, Azure OpenAI), la gestion devient un casse-tête. Chaque région géographique a ses propres lois. Les données stockées en Allemagne ne peuvent pas toujours être traitées aux États-Unis, et vice-versa.
Les défis incluent :
- Synchronisation des politiques : Assurer qu'une suppression demandée dans l'interface principale se propage à tous les backends cloud.
- Suppression sécurisée : S'assurer que la suppression n'est pas juste un marquage logique (« flag deleted ») mais une destruction physique irréversible des bits.
- Artificiels de modèle : Lors de la retraite d'un modèle, il faut supprimer non seulement les logs, mais aussi les checkpoints, les snapshots et les métadonnées associées stockés dans différents buckets S3 ou Blob Storage.
Mise en œuvre opérationnelle : Checklist
Pour transformer ces concepts en actions concrètes, voici une approche structurée pour les équipes IT et Juridiques :
- Inventaire des flux de données : Cartographiez exactement où vont les prompts. Sortent-ils de votre VPC ? Passent-ils par un fournisseur tiers ?
- Définition des durées de rétention : Fixez des délais précis (ex: 30 jours pour les logs de debug, 7 ans pour les logs financiers). Impliquez le service juridique dès le début.
- Automatisation de la classification : Utilisez des outils pour étiqueter automatiquement les prompts contenant des PII. Appliquez des politiques de rétention plus strictes à ces données sensibles.
- Tests de suppression : Vérifiez régulièrement que les scripts de suppression fonctionnent. Est-ce que les données disparaissent vraiment de SubstrateHolds ? Y a-t-il des sauvegardes obsolètes qui conservent encore les anciennes versions ?
- Documentation des preuves : Gardez une trace cryptographique de chaque action de suppression. En cas d'inspection par l'autorité de contrôle, vous devrez prouver que la donnée n'existe plus.
N'oubliez pas que la technologie évolue vite. Ce qui est vrai aujourd'hui pour les politiques de Microsoft ou d'OpenAI peut changer demain. Restez agile, surveillez les mises à jour des fournisseurs et maintenez un dialogue constant avec vos parties prenantes internes.
Combien de temps faut-il pour supprimer définitivement un prompt LLM ?
Cela dépend du fournisseur et de la configuration. Chez Microsoft, par exemple, même une suppression immédiate peut prendre jusqu'à 16 jours en raison des étapes intermédiaires de vérification légale (dossier SubstrateHolds). Il ne faut pas compter sur une suppression instantanée pour la conformité RGPD ; prévoyez une marge de sécurité dans vos politiques internes.
La suppression du log utilisateur efface-t-elle les données du modèle IA ?
Non. Supprimer le log de conversation retire l'historique visible, mais n'efface pas nécessairement les informations que le modèle a apprises ou mémorisées lors de l'entraînement. Pour un véritable droit à l'oubli, il faut utiliser des techniques d'« oubli de connaissances » ou retreiner le modèle avec des données nettoyées.
Qu'est-ce que le dossier SubstrateHolds chez Microsoft ?
C'est un espace de stockage temporaire utilisé par Microsoft 365 Copilot pour conserver les messages supprimés pendant 1 à 7 jours après l'expiration de leur période de rétention. Cela permet de s'assurer qu'aucune donnée n'est perdue prématurément si elle fait l'objet d'une enquête légale ou d'une retenue judiciaire.
Comment assurer la conformité RGPD avec les LLMs ?
Il faut limiter la collecte aux données nécessaires, chiffrer les données en transit et au repos, définir des périodes de rétention claires, automatiser la suppression, et garder des traces d'audit immuables. De plus, il est crucial de vérifier que les données sensibles ne persistent pas dans les poids du modèle via des techniques d'anonymisation et d'oubli ciblé.
Quelle est la différence entre rétention et suppression dans les politiques LLM ?
La rétention définit combien de temps les données sont conservées activement pour usage business ou légal. La suppression est le processus technique de destruction irréversible de ces données après la fin de la période de rétention. Dans les systèmes LLM, la suppression est souvent différée et multi-étapes pour garantir qu'aucune obligation légale n'est violée.
