RGPD et IA : traitement des données personnelles dans les systèmes d'IA en entreprise
RGPD et IA : tout système d'IA d'entreprise qui traite des données personnelles est soumis au Règlement général sur la protection des données (GDPR). Cela inclut les systèmes RAG qui indexent des documents contenant des noms, des emails, ou des informations sur des individus. Le DPO doit évaluer la base légale, les flux de données lors de l'inférence, la minimisation des données, et les droits des personnes concernées avant tout déploiement.
Le RGPD s'applique-t-il aux systèmes d'IA d'entreprise ?
La question est tranchée : oui. Le RGPD s'applique à tout traitement de données à caractère personnel, quelle que soit la technologie utilisée. Un système d'IA qui indexe des emails d'employés traite des données personnelles. Un système RAG qui accède à des contrats mentionnant des noms de clients traite des données personnelles. Un LLM qui génère des réponses à partir de documents RH contenant des informations individuelles traite des données personnelles.
La méconnaissance la plus fréquente en entreprise est de considérer que les données internes sont "hors périmètre RGPD" parce qu'elles ne concernent pas des clients. C'est inexact. Le RGPD s'applique aux données de toute personne physique identifiable, y compris les employés, les prospects, les fournisseurs, et les candidats. Un système d'IA qui indexe des données RH, des communications internes, ou des dossiers de partenaires traite des données personnelles soumises au RGPD.
La nature du traitement IA ajoute des complexités spécifiques. L'indexation crée des représentations sémantiques des documents. L'inférence envoie des extraits documentaires à un moteur de génération. Si ce moteur est externe, les données personnelles contenues dans ces extraits transitent vers un tiers. Chacune de ces étapes constitue un traitement au sens du RGPD, avec les obligations que cela implique.
Quelles sont les bases légales utilisables pour l'IA d'entreprise ?
Tout traitement de données personnelles requiert une base légale au sens de l'article 6 du RGPD. Pour les systèmes d'IA d'entreprise, trois bases légales sont principalement mobilisées, chacune avec ses limites.
L'intérêt légitime (article 6.1.f). C'est la base la plus souvent invoquée pour les traitements internes à visée d'efficacité opérationnelle. Pour être valide, elle nécessite une mise en balance des intérêts de l'entreprise avec les droits des personnes concernées. Pour un système d'IA de knowledge management qui accède à des emails ou des documents de travail, la mise en balance doit démontrer que le traitement est proportionné, que les personnes n'ont pas raisonnablement lieu de s'y opposer, et que des garanties appropriées sont en place.
L'exécution d'un contrat (article 6.1.b). Applicable uniquement si le traitement est nécessaire à l'exécution du contrat de travail ou du contrat liant l'entreprise à un client ou fournisseur concerné. Cette base est plus étroite qu'elle n'y paraît : elle ne couvre que les traitements strictement nécessaires, pas les traitements simplement utiles.
Le consentement (article 6.1.a). Techniquement valide mais pratiquement inadapté aux systèmes d'IA internes. Le consentement doit être libre, spécifique, éclairé, et univoque. Dans le contexte d'un contrat de travail, la liberté du consentement est structurellement questionnable. La CNIL a systématiquement rappelé que le consentement des employés ne peut pas constituer la base légale principale pour les traitements de données en entreprise.
Le choix de la base légale détermine les obligations qui s'ensuivent. L'intérêt légitime impose une DPIA (Data Protection Impact Assessment) si le traitement est susceptible d'engendrer un risque élevé pour les droits des personnes, ce qui est souvent le cas pour les systèmes d'IA à large couverture documentaire.
Quelles obligations spécifiques s'appliquent aux données personnelles dans un système RAG ?
Un système RAG d'entreprise traite des données personnelles à plusieurs niveaux : lors de l'indexation des documents source, lors de l'inférence qui récupère des extraits, et potentiellement dans les logs de requêtes qui enregistrent ce que les utilisateurs ont demandé. Chaque niveau implique des obligations distinctes.
| Étape du traitement | Données personnelles potentielles | Obligation RGPD principale |
|---|---|---|
| Indexation documentaire | Noms, emails, données RH dans les documents | Base légale, minimisation, durée de conservation |
| Inférence (requête + contexte) | Données personnelles dans les extraits récupérés | Limitation des transferts si fournisseur externe |
| Logs de requêtes | Questions de l'utilisateur, contexte récupéré | Durée de conservation, accès limité |
| Réponses générées | Données personnelles citées dans la réponse | Exactitude, droit de rectification |
| Représentations vectorielles | Encodage sémantique des documents personnels | Protection équivalente aux données source |
La minimisation des données est un principe fondamental du RGPD souvent négligé dans le design des systèmes d'IA. Les documents indexés ne devraient contenir que les données personnelles strictement nécessaires à la finalité du système. Si un système d'IA est déployé pour répondre à des questions sur les politiques internes, il n'est pas nécessaire d'indexer des données personnelles individuelles. Les documents doivent être filtrés ou anonymisés en amont si la finalité du système ne nécessite pas l'accès aux données individuelles.
La durée de conservation s'applique aux données indexées. Le principe de limitation de la conservation impose que les données ne soient conservées que le temps nécessaire à leur finalité. Pour un système RAG, cela signifie que les documents indexés contenant des données personnelles doivent être supprimés ou mis hors index quand la finalité du traitement est atteinte, ou quand la durée de conservation applicable expire. Ce point est souvent absent des projets IA d'entreprise qui traitent la base documentaire comme un actif permanent.
Les droits des personnes concernées s'appliquent intégralement. Le droit d'accès (article 15), le droit de rectification (article 16), et le droit à l'effacement (article 17) peuvent être exercés par toute personne dont les données sont traitées par le système. Pour un système RAG, cela implique la capacité technique de localiser les données d'une personne dans l'index, de les rectifier si elles sont inexactes, et de les supprimer à la demande. Cette capacité doit être implémentée dans le système, pas gérée manuellement après le fait.
Qu'est-ce qu'une DPIA et quand est-elle obligatoire pour un système d'IA ?
La Data Protection Impact Assessment (DPIA, ou analyse d'impact relative à la protection des données en français) est une évaluation préalable obligatoire pour les traitements susceptibles d'engendrer un risque élevé pour les droits et libertés des personnes. Pour les systèmes d'IA d'entreprise, la DPIA est très souvent obligatoire.
Les critères qui rendent la DPIA obligatoire pour un système IA incluent le traitement à grande échelle de données personnelles (un système qui indexe des milliers de documents contenant des données personnelles entre dans cette catégorie), le recoupement de données provenant de sources multiples (un système RAG qui interroge plusieurs sources documentaires croise des données), et l'utilisation de nouvelles technologies présentant des risques non encore identifiés (les systèmes RAG à base de LLM entrent dans cette catégorie).
En pratique, tout système d'IA d'entreprise qui indexe des données personnelles à large échelle devrait faire l'objet d'une DPIA. Cette évaluation doit couvrir la description du traitement et de ses finalités, l'évaluation de la nécessité et de la proportionnalité, l'identification des risques pour les personnes concernées, et les mesures envisagées pour traiter ces risques.
La DPIA n'est pas un exercice administratif. C'est une démarche qui force à s'interroger sur si le traitement est vraiment nécessaire sous cette forme, et ce qui peut être fait pour le rendre moins intrusif. Pour un système RAG, la DPIA peut conduire à des décisions d'anonymisation préalable de certains documents, de restriction du périmètre d'indexation, ou de mise en place de contrôles RBAC stricts limitant l'accès aux données personnelles.
Les transferts de données vers un fournisseur IA externe sont-ils problématiques ?
Oui, systématiquement. Quand un système d'IA envoie des requêtes et des extraits documentaires à une API externe pour l'inférence, il transfère potentiellement des données personnelles à un tiers. Ce transfert est un traitement au sens du RGPD et doit satisfaire aux exigences du chapitre V pour les transferts vers des pays tiers.
Pour les fournisseurs d'IA établis aux États-Unis, le cadre de transfert applicable dépend de la configuration du fournisseur. Certains fournisseurs peuvent se prévaloir du Data Privacy Framework EU-US, qui encadre les transferts vers les entreprises américaines certifiées. D'autres nécessitent la mise en place de Clauses contractuelles types (CCT) et d'une évaluation du droit local (Transfer Impact Assessment).
Le problème que soulèvent de nombreux DPO est la difficulté de documenter précisément quelles données personnelles transitent vers le fournisseur lors de l'inférence. Chaque requête peut potentiellement extraire des extraits documentaires contenant des données personnelles différentes. La documentation du transfert est donc dynamique et difficilement exhaustive. Comme le détaille l'analyse de la sécurité des IA d'entreprise, les protections contractuelles ne remplacent pas les garanties architecturales.
La solution architecturale qui élimine ce problème est le déploiement on-premise : quand l'inférence s'exécute dans l'infrastructure propre de l'organisation, il n'y a pas de transfert de données personnelles à un tiers lors de l'inférence. Les obligations RGPD restent applicables au traitement en tant que tel, mais la dimension "transfert vers un pays tiers" est éliminée. Pour les DPO qui cherchent à simplifier leur cartographie des traitements, c'est un argument architectural significatif. L'article sur l'IA en mode air-gap pour les industries régulées développe cette logique en détail.
Scabera est conçu pour fonctionner sans appel à des API externes lors de l'inférence, ce qui élimine structurellement le risque de transfert transfrontalier de données personnelles et simplifie considérablement la documentation RGPD du système.
Questions fréquentes sur le RGPD et les systèmes d'IA d'entreprise
Un système d'IA qui anonymise les réponses est-il exempt des obligations RGPD ?
Non. Le RGPD s'applique au traitement des données personnelles à toutes les étapes, pas seulement aux outputs. Même si le système d'IA ne produit pas de réponses contenant des données personnelles identifiables, il peut traiter des données personnelles lors de l'indexation ou de l'inférence. L'anonymisation des outputs ne suffit pas à exempter le traitement des données source des obligations RGPD.
Le DPO doit-il être impliqué avant tout déploiement d'IA en entreprise ?
Oui, dès lors que le système traite des données personnelles. La consultation du DPO est obligatoire pour la réalisation de la DPIA, qui est elle-même obligatoire pour les traitements à risque élevé. En pratique, associer le DPO dès la phase de conception permet d'éviter des révisions architecturales coûteuses après déploiement.
Les représentations vectorielles (embeddings) sont-elles des données personnelles au sens du RGPD ?
La CNIL et d'autres autorités de protection des données ont indiqué que les représentations vectorielles dérivées de données personnelles peuvent elles-mêmes constituer des données personnelles si elles permettent d'identifier directement ou indirectement les personnes concernées. Des recherches récentes montrent que la reconstruction partielle de données textuelles à partir d'embeddings est techniquement possible. Les responsables de traitement doivent donc appliquer les mêmes garanties de protection aux embeddings qu'aux données sources.
Comment gérer le droit à l'effacement pour un système RAG qui a indexé des données personnelles ?
Le droit à l'effacement impose de pouvoir retirer les données d'une personne de l'index documentaire et de régénérer les représentations vectorielles sans ces données. Techniquement, cela nécessite une capacité de suppression ciblée dans le pipeline d'indexation et un mécanisme de re-indexation des documents épurés. Cette capacité doit être intégrée dès la conception du système, pas ajoutée après déploiement.
Quelle est la durée de conservation recommandée pour les logs de requêtes d'un système IA ?
Le RGPD ne fixe pas de durée spécifique pour les logs de systèmes IA. La durée de conservation doit être proportionnée à la finalité : les logs nécessaires à la sécurité et à la détection des incidents peuvent justifier une conservation de 12 à 24 mois. Les logs contenant des données personnelles doivent faire l'objet d'une politique de purge automatique et documentée. La durée retenue doit figurer dans le registre des traitements et dans la DPIA.
Pour voir comment Scabera aborde la conformité RGPD dans les systèmes d'IA d'entreprise, demandez une démonstration.