RGPD et IA générative : cartographier les données avant de connecter un modèle à l’entreprise

Lorsqu’une entreprise étudie un projet d’IA générative, la discussion se concentre souvent sur les prompts : peut-on envoyer ce texte au modèle ? En réalité, les données circulent dans une chaîne beaucoup plus large. Les documents sont importés, découpés, vectorisés, mis en cache, journalisés, cités, copiés dans des outils et parfois conservés pour améliorer le service.

Un agent ajoute encore d’autres flux : mémoire persistante, connexions à la messagerie, au CRM ou aux fichiers, appels de sous-agents et actions effectuées au nom de l’utilisateur. La conformité au RGPD ne peut donc pas être évaluée à partir de la seule interface du fournisseur.

Cet article propose une méthode technique de cartographie et ne constitue pas un avis juridique. Les choix doivent être validés avec le DPO et les conseils compétents.

Le modèle n’est qu’un composant du traitement

Une architecture générative peut comprendre :

• une interface web ou mobile ;
• un backend applicatif ;
• une passerelle de modèles ;
• un fournisseur de LLM ;
• un service d’embeddings ;
• une base vectorielle ;
• un OCR ;
• des sources documentaires ;
• des connecteurs métier ;
• une mémoire de conversation ;
• des logs, traces et analytics ;
• un outil de support ;
• des sauvegardes.

Chacun peut recevoir des données personnelles. Un composant auto-hébergé réduit certains transferts, mais ne supprime pas les obligations de finalité, minimisation, sécurité, durée et droits.

Commencer par la finalité

La question « pouvons-nous utiliser cette donnée ? » n’a pas de réponse abstraite. Il faut décrire le but précis : aider un conseiller à retrouver une procédure, rédiger une réponse, classer une demande, extraire une facture ou préparer une décision.

Une finalité vague comme « améliorer l’efficacité grâce à l’IA » ne permet pas de déterminer les données nécessaires. Une finalité précise aide à exclure :

• des colonnes inutiles ;
• des documents hors périmètre ;
• l’historique complet quand une période suffit ;
• les identités lorsque des références pseudonymes conviennent ;
• les logs de contenu lorsque des métriques agrégées suffisent.

La minimisation se conçoit avant l’ingestion, pas seulement après un incident.

Cartographier la chaîne complète

Pour chaque flux, documenter :

1. la source ;
2. les catégories de données ;
3. les personnes concernées ;
4. la finalité ;
5. le destinataire ;
6. le rôle de chaque acteur ;
7. le pays ou la région ;
8. le chiffrement ;
9. la durée ;
10. la suppression ;
11. l’usage éventuel pour l’entraînement ;
12. les accès humains et machines.

La cartographie doit couvrir les copies temporaires et indirectes. Un prompt peut apparaître dans une trace d’observabilité, une capture de support ou une sauvegarde plus longtemps que dans l’application principale.

Qualifier les données sans sous-estimer l’identification indirecte

Un nom ou une adresse est évidemment personnel. D’autres éléments peuvent identifier une personne par combinaison : numéro de dossier, poste, localisation, événement rare, verbatim, métadonnée ou historique.

La pseudonymisation remplace un identifiant par une référence contrôlée, mais la donnée reste personnelle si une réidentification est possible. L’anonymisation exige une analyse plus forte et contextuelle. Les lignes directrices du CEPD publiées en 2026 rappellent que l’évaluation dépend notamment des moyens raisonnablement susceptibles d’être utilisés par les acteurs pertinents.

Éviter donc d’étiqueter un corpus « anonyme » uniquement parce que les noms ont été supprimés.

Déterminer les rôles et responsabilités

L’entreprise peut être responsable de traitement pour la finalité métier et recourir à des sous-traitants. Le fournisseur peut également traiter certaines données pour ses propres finalités selon son offre et ses conditions. Les rôles doivent être analysés, pas déduits d’un slogan commercial.

Vérifier :

• instructions documentées ;
• sous-traitants ultérieurs ;
• régions de traitement ;
• transferts hors Espace économique européen ;
• sécurité ;
• notification d’incident ;
• assistance aux droits ;
• suppression et restitution ;
• audit ;
• changement de modèle ou de politique ;
• utilisation des contenus pour améliorer le service.

Un mode « données non utilisées pour entraîner » ne répond pas à toutes les questions : les contenus peuvent encore être conservés pour la sécurité, le support ou les logs.

Choisir et documenter la base juridique

La base juridique dépend de la finalité, de la relation et du contexte. Un outil interne, un service client, une recherche scientifique et un traitement de recrutement ne s’analysent pas de la même manière.

L’équipe technique ne doit pas sélectionner automatiquement « intérêt légitime ». Elle fournit au DPO les éléments factuels : nécessité, données, personnes, impact, alternatives et mesures. Le consentement ne doit pas être utilisé lorsqu’il n’est pas libre ou lorsque le service ne peut réellement fonctionner sans traitement.

Lorsque des catégories particulières de données sont concernées, des conditions supplémentaires s’appliquent.

Concevoir le RAG avec la protection des données

Un RAG peut réduire les hallucinations et limiter le besoin de fine-tuning, mais il crée un index dérivé des documents. Les embeddings ne doivent pas être considérés comme anonymes par défaut. Ils peuvent révéler des informations ou permettre des rapprochements selon le contexte.

Les contrôles utiles comprennent :

• filtrage des sources avant ingestion ;
• droits d’accès propagés à l’index ;
• séparation par tenant ou domaine ;
• métadonnées minimales ;
• chiffrement ;
• suppression synchronisée entre source, chunks et index ;
• citations avec contrôle d’autorisation ;
• tests de fuite entre utilisateurs ;
• réindexation versionnée.

Une base vectorielle unique accessible par tous est une erreur fréquente lorsque les documents d’origine possèdent des droits fins.

Encadrer prompts, sorties et feedback

L’utilisateur peut saisir plus de données que nécessaire. L’interface doit l’informer et, lorsque possible, détecter ou masquer certaines catégories avant l’envoi.

Les sorties peuvent répéter une donnée source, inférer une information ou combiner plusieurs éléments. Elles sont donc soumises aux mêmes contrôles d’accès et de conservation.

Le feedback « bonne/mauvaise réponse » peut contenir le texte complet et devenir un corpus d’amélioration. Définir qui peut le lire, combien de temps il est conservé et s’il est réutilisé pour entraîner ou évaluer.

Maîtriser les logs et l’observabilité

Sans traces, il est difficile d’expliquer une erreur. Avec des traces exhaustives, l’entreprise crée une nouvelle base sensible. Il faut séparer :

• métriques techniques sans contenu ;
• identifiants de corrélation ;
• prompts et sorties échantillonnés ;
• journaux d’actions ;
• erreurs ;
• données de sécurité.

Appliquer contrôle d’accès, chiffrement, masquage, durée courte et audit. Les traces détaillées peuvent être activées temporairement pour un incident avec une procédure définie.

Gérer la mémoire et les agents

Une mémoire persistante peut accumuler préférences, relations, santé, opinions ou habitudes. Elle doit être visible, modifiable et supprimable. Son périmètre est limité à ce qui améliore réellement le service.

Pour un agent, chaque connecteur étend le traitement. La CNIL et le CIANum ont souligné en juillet 2026 les risques liés à la circulation entre services, la mémoire persistante, l’hyperpersonnalisation et la difficulté d’attribuer les responsabilités.

Le principe du moindre privilège s’applique : accès à la demande, portée limitée, durée courte, confirmation pour les actions sensibles et journal compréhensible par l’utilisateur.

Préparer les droits des personnes

L’entreprise doit savoir retrouver, corriger, exporter ou supprimer les données pertinentes. Cela implique de relier l’identité aux différentes couches sans créer un index encore plus intrusif.

Tester le parcours :

• retrouver les prompts ;
• identifier les documents sources ;
• supprimer chunks et embeddings ;
• vider la mémoire ;
• traiter les sauvegardes selon la politique ;
• corriger une donnée source ;
• éviter sa réapparition lors de la prochaine indexation.

Un droit théorique sans procédure technique est difficile à exercer.

Déterminer si une AIPD est nécessaire

Une analyse d’impact relative à la protection des données peut être requise lorsque le traitement est susceptible d’engendrer un risque élevé. Les facteurs incluent notamment surveillance, données sensibles, personnes vulnérables, échelle, croisement, innovation et décisions importantes.

Même lorsqu’elle n’est pas obligatoire, une analyse structurée aide à comparer les variantes d’architecture et mesures. Elle doit être actualisée lors d’un changement de finalité, de modèle, de donnée ou d’autonomie.

Ne pas confondre entraînement, fine-tuning et utilisation

Un fournisseur peut ne pas utiliser les prompts pour l’entraînement tout en exécutant le traitement sur son infrastructure. Un fine-tuning peut mémoriser des exemples. Un RAG conserve les données dans un index. Chaque mécanisme produit des risques distincts.

Pour l’entraînement ou la personnalisation, documenter la provenance, les droits, la nécessité, la filtration, les tests d’extraction, les durées et la capacité de retrait. Le moissonnage de données personnelles à grande échelle fait l’objet de lignes directrices du CEPD publiées pour consultation en juillet 2026.

Une architecture de confidentialité par défaut

Une solution robuste combine :

• classification des données ;
• passerelle centralisée ;
• modèles autorisés par niveau ;
• masquage avant envoi ;
• accès propagés ;
• rétention minimale ;
• logs maîtrisés ;
• régions et contrats vérifiés ;
• tests de fuite ;
• procédure de droits et d’incident.

Partitech peut réaliser la cartographie technique, concevoir les contrôles d’accès, l’indexation, la passerelle et les mécanismes de suppression. Le DPO et les conseils de l’entreprise valident les bases juridiques, informations et analyses. Le résultat attendu est une architecture dont les flux sont connus et pilotables, pas une promesse abstraite de confidentialité.

Parlons de votre projet

Cartographier et sécuriser les flux de données de votre projet IA avec Partitech, votre DPO et vos conseils. Contactez Partitech.