Oui, une entreprise peut utiliser l’IA générative sans exposer les données personnelles de ses clients et de ses salariés, à condition de traiter le sujet comme n’importe quel traitement de données au sens du RGPD. Concrètement : définir les usages autorisés, choisir un mode de déploiement qui ne réutilise pas les données, ne transmettre au modèle que ce qui est nécessaire (idéalement pseudonymisé), encadrer le fournisseur par contrat et documenter le traitement. La CNIL a publié des recommandations en ce sens, qui tiennent en une idée : partir d’un besoin précis, pas de l’outil.
Quand le RGPD s’applique-t-il à l’IA générative ?
Le RGPD s’applique dès qu’une donnée permettant d’identifier une personne est traitée. Avec l’IA générative, cela arrive bien plus souvent qu’on ne le pense :
- dans le prompt : « Rédige une réponse à M. Martin qui conteste sa facture du 12 mars » ;
- dans les documents fournis au modèle : un contrat, un compte rendu d’entretien, un export du CRM ;
- dans la réponse générée, qui peut contenir des informations sur une personne, exactes ou non ;
- dans les journaux conservés par l’application ou par le fournisseur.
Le modèle lui-même peut être concerné. Dans un avis de décembre 2024, le Comité européen de la protection des données a rappelé que le RGPD s’applique, dans de nombreux cas, aux modèles entraînés sur des données personnelles, en raison de leurs capacités de mémorisation ; la CNIL en a tiré des recommandations finalisées en juillet 2025. Pour une entreprise qui utilise un modèle existant sans l’entraîner, le sujet principal reste toutefois ce qu’elle lui envoie.
Deux situations doivent être distinguées : l’usage par les salariés d’assistants du marché, et l’IA intégrée dans vos propres applications. Les règles sont les mêmes, mais les moyens de contrôle diffèrent.
Que recommande la CNIL pour déployer une IA générative ?
En juillet 2024, la CNIL a publié de premières précisions sur le déploiement de l’IA générative en entreprise. Ses recommandations se résument en six points :
- Partir d’un besoin concret plutôt que d’adopter un outil sans objectif précis.
- Encadrer les usages : dresser une liste des usages autorisés et interdits selon les risques, par exemple ne pas fournir de données personnelles au système ou ne pas lui confier de prise de décision.
- Choisir un système robuste et un mode de déploiement sécurisé, en privilégiant les systèmes locaux, sécurisés et spécialisés, et en vérifiant si un prestataire pourrait réutiliser les données fournies.
- Ne pas occulter les limites de ces systèmes, qui peuvent produire des résultats inexacts mais plausibles.
- Former et sensibiliser les utilisateurs aux usages interdits et aux risques des usages autorisés.
- Mettre en place une gouvernance adaptée, en associant dès le départ le délégué à la protection des données (DPO), le responsable de la sécurité (RSSI), la DSI et les responsables métier.
Pour la phase de conception d’un système d’IA, la CNIL a aussi publié une série de fiches pratiques : finalité, base légale, analyse d’impact, information des personnes, exercice des droits, sécurité. Elles servent de référence dès qu’un projet va au-delà de l’usage d’un outil du marché.
Quel mode de déploiement choisir ?
C’est la décision qui conditionne tout le reste : elle détermine qui voit les données, où elles sont traitées et ce qu’il en advient.
| Mode de déploiement | Contrôle sur les données | Points à vérifier | Adapté pour |
|---|---|---|---|
| Assistant grand public, compte personnel | Très faible | Réutilisation pour l’entraînement, absence de contrat | Usages sans aucune donnée personnelle ni confidentielle |
| Offre entreprise d’un assistant | Moyen | Contrat, non-réutilisation, localisation, durée de conservation, administration des comptes | Productivité individuelle encadrée |
| API intégrée dans votre application | Élevé | Contrat de sous-traitance, région de traitement, conservation des requêtes, filtrage en amont | Fonctionnalités métier, données clients |
| Modèle hébergé en propre ou chez un hébergeur européen | Très élevé | Exploitation, sécurité, mises à jour, coût d’infrastructure | Données sensibles, contraintes de souveraineté |
Le troisième mode est souvent le meilleur compromis pour une PME ou une ETI : l’application contrôle exactement ce qui est envoyé, peut filtrer et pseudonymiser avant l’appel, et s’appuie sur un fournisseur encadré par contrat. Le quatrième s’impose pour certaines données, notamment de santé, ou lorsque l’entreprise exige un hébergement souverain.
Comment minimiser les données envoyées au modèle ?
La donnée la mieux protégée est celle que l’on n’envoie pas. Dans une application conçue avec la protection des données dès la conception, plusieurs techniques se combinent :
- Transmettre les seuls champs utiles. Pour classer une réclamation, le modèle a besoin du texte de la réclamation, pas du nom, de l’adresse et de l’historique d’achat du client.
- Pseudonymiser avant l’appel. Un filtre automatique remplace les noms, e-mails, numéros de téléphone ou IBAN par des jetons (« CLIENT_1 », « EMAIL_1 »), puis l’application réinjecte les vraies valeurs dans la réponse. Une donnée pseudonymisée reste une donnée personnelle au sens du RGPD, mais le fournisseur ne voit plus d’identité en clair.
- Filtrer en sortie. La CNIL suggère des filtres robustes au niveau du système qui encapsule le modèle pour éviter qu’il ne restitue des données personnelles.
- Respecter les droits d’accès dans la recherche documentaire. Un assistant branché sur les documents internes ne doit retrouver que ceux que l’utilisateur a le droit de consulter. C’est un point clé de toute architecture RAG.
- Limiter la conservation. Les requêtes et réponses journalisées ont une durée de conservation définie, et l’historique des conversations n’est pas gardé indéfiniment par défaut.
Ces mesures relèvent aussi de la sécurité : l’ANSSI consacre un guide aux recommandations de sécurité pour un système d’IA générative, de la conception à la mise en production, et les attaques propres à ces systèmes sont détaillées dans notre article sur les risques de l’IA générative.
Quel cadre contractuel et quelle documentation prévoir ?
Un fournisseur qui traite des données personnelles pour votre compte est un sous-traitant au sens du RGPD. Plusieurs obligations en découlent.
- Un contrat conforme à l’article 28 : objet et durée du traitement, instructions, confidentialité, sécurité, sort des données en fin de contrat, recours à des sous-traitants ultérieurs.
- L’encadrement des transferts si les données quittent l’Union européenne : décision d’adéquation, clauses contractuelles types, ou choix d’une région de traitement européenne.
- L’inscription au registre des traitements, avec la finalité, les catégories de données et les destinataires.
- L’information des personnes concernées : clients, salariés, candidats doivent savoir que leurs données sont traitées par un système d’IA, et dans quel but.
- Une analyse d’impact (AIPD) lorsque le traitement est susceptible d’engendrer un risque élevé : évaluation de salariés, données de santé, grand nombre de personnes, usage innovant.
L’IA générative croise aussi le règlement européen sur l’IA, qui ajoute ses propres obligations de transparence et, pour certains usages comme le recrutement, des exigences renforcées. Le calendrier est détaillé dans notre article sur l’AI Act pour les PME et ETI.
Trois cas pratiques, trois niveaux de vigilance
Prenons trois projets hypothétiques dans une même entreprise de services.
| Projet | Données en jeu | Mesures clés |
|---|---|---|
| Résumer les tickets de support pour le reporting mensuel | Noms et coordonnées des clients dans les tickets | Pseudonymisation avant envoi, traitement par API encadrée, aucun stockage chez le fournisseur au-delà du traitement |
| Assistant interne qui répond aux questions RH à partir des procédures | Procédures (peu de données personnelles), questions des salariés | Recherche limitée aux documents publics en interne, journaux conservés peu de temps, information des salariés |
| Tri automatique des candidatures | CV, données de candidats | Usage à haut risque : AIPD, validation humaine de chaque décision, information des candidats, vérification des obligations du règlement sur l’IA |
Le même outil technique peut donc relever de régimes très différents selon la finalité. C’est la finalité, pas la technologie, qui fixe le niveau d’exigence.
La checklist avant de lancer un projet
- Le besoin et la finalité sont écrits, avec les usages exclus.
- Le DPO et le RSSI ont été associés dès le cadrage.
- Le mode de déploiement est choisi, et le contrat exclut la réutilisation des données pour l’entraînement.
- La localisation des traitements et les éventuels transferts hors UE sont identifiés et encadrés.
- Seuls les champs nécessaires sont transmis ; les identifiants directs sont pseudonymisés.
- Les droits d’accès de l’utilisateur s’appliquent à tout ce que l’IA consulte.
- Aucune décision produisant des effets importants sur une personne n’est prise sans intervention humaine.
- Les durées de conservation des requêtes, réponses et journaux sont fixées.
- Le registre est à jour ; la nécessité d’une AIPD a été évaluée.
- Les utilisateurs sont formés, et les personnes concernées sont informées.
Ce que prépare la CNIL
Le programme de travail 2026 de la CNIL, publié en avril 2026, prévoit de finaliser ses travaux sur l’usage de l’IA dans les secteurs du travail et de la santé, de clarifier les responsabilités des différents acteurs de la chaîne de valeur (concepteurs de modèles, intégrateurs, déployeurs) et de préparer son rôle d’autorité de surveillance du marché au titre du règlement européen sur l’IA. Les entreprises qui documentent dès maintenant leurs choix seront prêtes lorsque ces précisions arriveront.
Vous voulez intégrer l’IA générative dans une application métier en gardant la maîtrise des données personnelles ? Nous concevons ces fonctionnalités avec filtrage, pseudonymisation et traçabilité intégrés dès le départ : décrivez votre projet dans notre diagnostic en ligne.
