1.3 RGPD et IA générative : base légale, article 22, AIPD, transferts hors UE

Tout traitement de données personnelles par un système d'IA doit reposer sur une base légale au sens de l'article 6 du RGPD. Cette obligation est antérieure à l'AI Act et se cumule avec lui : l'IA n'exempte de rien. Pour les notions de base (donnée personnelle, responsable de traitement, sous-traitant), la sensibilisation RGPD pour salariés constitue un prérequis utile.

Six bases légales possibles :

• (a) Consentement de la personne — libre, éclairé, spécifique, univoque, retirable
• (b) Exécution d'un contrat auquel la personne est partie
• (c) Obligation légale du responsable de traitement
• (d) Sauvegarde des intérêts vitaux de la personne (cas rares)
• (e) Mission d'intérêt public (acteurs publics principalement)
• (f) Intérêt légitime du responsable ou d'un tiers (sauf si les intérêts/droits/libertés de la personne prévalent)

Pour les usages d'IA en entreprise, deux bases dominent en pratique :

L'exécution du contrat de travail (article 6(b)). Pour traiter les données des salariés via un outil RH IA, l'employeur peut s'appuyer sur l'exécution du contrat de travail. Mais attention : la doctrine de la CNIL et du Comité européen de la protection des données (lignes directrices 2/2019) est restrictive : la base contractuelle ne couvre que les traitements objectivement nécessaires à l'exécution du contrat. Un tri automatisé de CV pour une fonction donnée peut s'y appuyer ; un système de surveillance comportementale continue, non.

L'intérêt légitime (article 6(f)). Base souvent invoquée pour les outils d'aide à la productivité, l'analyse de données clients, le marketing personnalisé. Suppose un test de mise en balance tracé entre l'intérêt légitime et les droits/libertés des personnes. Pour les usages d'IA susceptibles d'avoir un impact significatif sur les personnes, l'intérêt légitime est de plus en plus fragile.

Le consentement (article 6(a)) reste rarement applicable pour les outils IA en entreprise : il n'est en principe pas considéré comme libre dans le cadre du lien de subordination entre employeur et salarié (considérant 43 du RGPD, lignes directrices 5/2020 du CEPD). Pour les clients et prospects, il est utilisé mais nécessite une UX claire et la possibilité réelle de refus.

Le choix de la base légale est structurant : il conditionne les droits de la personne (par exemple le droit à l'opposition n'existe pas pour le consentement, qui se retire ; il existe pour l'intérêt légitime). Le DPO doit valider ce choix lors de la conception du traitement.

L'article 9 du RGPD énumère des catégories de données sensibles dont le traitement est interdit par principe, sauf exceptions limitatives :

• Origine raciale ou ethnique
• Opinions politiques
• Convictions religieuses ou philosophiques
• Appartenance syndicale
• Données génétiques, biométriques (pour identification), de santé
• Données relatives à la vie sexuelle ou à l'orientation sexuelle

Les exceptions principales : consentement explicite, obligation légale, intérêt vital, organisation à but non lucratif (membres seulement), données rendues publiques par la personne, exercice d'un droit en justice, intérêt public substantiel, médecine du travail / soins, santé publique, recherche scientifique.

Pour les usages d'IA en entreprise, plusieurs pièges apparaissent :

Piège 1 — données sensibles déduites. Un système d'IA peut déduire des données sensibles à partir d'autres données. Exemple classique : un système de scoring de CV qui à partir du nom, prénom, lieu de naissance, photo, université, peut déduire l'origine ethnique présumée. Cette déduction est elle-même un traitement de données sensibles soumis à l'article 9. La déduction n'exempte pas de l'interdiction.

Piège 2 — données collectées dans les prompts. Si un collaborateur RH copie dans un assistant grand public le CV d'un candidat avec sa photo et la mention d'un engagement syndical, il transmet des données sensibles à un tiers sans aucune des exceptions de l'article 9. Manquement RGPD caractérisé.

Piège 3 — entraînement sur données sensibles. Les modèles GPAI ont été entraînés sur des corpus web qui contiennent inévitablement des données sensibles. Les fournisseurs doivent justifier cette collecte au regard du RGPD : l'avis 28/2024 du Comité européen de la protection des données (18 décembre 2024) fixe la grille d'analyse (anonymat du modèle, intérêt légitime, conséquences d'un entraînement illicite), et plusieurs plaintes d'associations sont pendantes devant les autorités nationales.

Piège 4 — biométrie « pour identification ». Un système qui reconnaît une personne à partir d'une image (reconnaissance faciale, vocale, empreinte) traite des données biométriques au sens de l'article 9. Quasi-systématiquement interdit en entreprise sauf cas très spécifiques (sécurité site sensible avec consentement explicite).

L'AI Act ajoute des restrictions complémentaires : la catégorisation biométrique permettant de déduire race, opinions politiques, syndicalisme, religion, vie sexuelle est interdite au titre de l'article 5 (cf. chapitre précédent). Cumul des deux régimes.

L'article 22 du RGPD est l'article-clé pour les usages d'IA décisionnels. Son principe : « La personne concernée a le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé, y compris le profilage, produisant des effets juridiques la concernant ou l'affectant de manière significative de façon similaire. »

Cette disposition introduit une quasi-interdiction des décisions purement automatisées qui affectent la personne. Les exceptions sont strictes :

• Décision nécessaire à la conclusion ou exécution d'un contrat
• Décision autorisée par le droit national ou européen avec garanties
• Décision fondée sur le consentement explicite de la personne

Et même dans ces cas, des garanties supplémentaires sont obligatoires : droit à l'intervention humaine, droit d'exprimer son point de vue, droit de contester la décision.

Pour les usages IA en entreprise, deux situations méritent attention :

Recrutement automatisé. Si un système IA élimine seul des candidatures sans intervention humaine, c'est une décision purement automatisée affectant les personnes (effet juridique : non-embauche). Soumis à l'article 22. La solution : intercaler une validation humaine effective dans le processus. Un humain doit examiner les décisions avant qu'elles soient communiquées, et avoir le pouvoir réel de modifier la décision (pas une validation symbolique).

Décisions de gestion automatisées. Allocation automatique de primes, attribution automatique de promotions, surveillance de productivité menant à sanction… Tous ces usages relèvent de l'article 22 si l'humain n'intervient pas substantiellement.

La jurisprudence CJUE récente (arrêt Schufa du 7 décembre 2023, affaire C-634/21) a précisé que même une simple évaluation par scoring peut constituer une « décision » au sens de l'article 22, dès lors qu'elle influence significativement la décision finale d'un tiers — même si la décision finale est techniquement prise par un humain. Cette interprétation extensive est cruciale pour les outils de scoring crédit, assurance, recrutement.

L'AI Act complète ces protections : l'article 86 crée un droit à une explication claire et pertinente du rôle joué par un système à haut risque de l'annexe III dans une décision individuelle, applicable avec le reste des obligations haut risque au 2 décembre 2027 (règlement omnibus 2026/1744).

Pour respecter l'article 22, l'organisation type qui marche : (1) le système IA produit une recommandation, (2) un humain examine la recommandation en consultant les éléments du dossier, (3) l'humain prend la décision finale avec son pouvoir réel de la modifier, (4) traçabilité de cette intervention humaine. Cette structure est compatible RGPD et compatible AI Act.

L'article 25 du RGPD impose une protection des données dès la conception (privacy by design) et par défaut (privacy by default). Concrètement, lors du choix d'un outil IA ou de son intégration dans un processus, l'entreprise doit :

• Minimiser les données collectées et traitées (principe de minimisation, article 5(1)(c))
• Limiter la durée de conservation au strict nécessaire (article 5(1)(e))
• Choisir des paramétrages par défaut qui protègent la vie privée (ex : non-entraînement du modèle par défaut, journaux activités désactivés par défaut)
• Anonymiser ou pseudonymiser dès que possible
• Documenter les choix de conception

Pour les outils d'IA générative, cela signifie privilégier :

• Des offres professionnelles dont le contrat exclut par défaut la réutilisation des données pour l'entraînement
• Un hébergement et un traitement dans l'Union, quand le fournisseur le propose
• L'anonymisation des prompts en amont, par les utilisateurs ou par un outil de prévention des fuites de données (DLP)
• Une durée de conservation des conversations courte et paramétrée
• Le cloisonnement des accès par profil et par besoin

L'article 32 impose ensuite des mesures techniques et organisationnelles appropriées pour garantir la sécurité du traitement. Pour les outils IA :

• Chiffrement en transit (TLS 1.3) et au repos
• Authentification forte (SSO entreprise + MFA)
• Gestion des accès selon le principe du moindre privilège
• Journalisation des accès et opérations sensibles
• Tests réguliers de sécurité (pentests, audits)
• Procédures de réaction aux incidents (article 33 — notification à la CNIL dans les 72h en cas de violation)

Les offres professionnelles documentent en général ces mesures par des certifications (rapport SOC 2 de type II, ISO/IEC 27001, ISO/IEC 27018 pour les données personnelles dans le cloud). Demander les attestations avant l'achat, et vérifier leur périmètre exact.

Pour les usages plus avancés (RAG sur documentation interne, fine-tuning sur données métier), s'ajoutent des considérations supplémentaires : isolement des index par client/tenant, suppression effective des données d'entraînement à la demande, contrôle des dérives potentielles du modèle.

L'Analyse d'Impact sur la Protection des Données (AIPD), en anglais Data Protection Impact Assessment (DPIA), est encadrée par l'article 35 du RGPD. Elle est obligatoire avant la mise en œuvre d'un traitement « susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques ».

La CNIL a publié (délibération n° 2018-327 du 11 octobre 2018) une liste des types de traitements pour lesquels une AIPD est requise, complétée par les neuf critères du Comité européen (lignes directrices WP248) dont deux suffisent à caractériser le risque élevé. Y figurent notamment :

• Traitements ayant pour finalité de surveiller de manière constante l'activité des salariés
• Traitements de profilage conduisant à l'exclusion ou à la réduction d'un droit ou d'un contrat
• Traitements de données de santé, biométriques ou génétiques à grande échelle
• Traitements de données de localisation à large échelle
• Critères du Comité européen : évaluation ou notation, décision automatisée à effet juridique, surveillance systématique, données sensibles, grande échelle, croisement de données, personnes vulnérables, usage innovant d'une technologie, exclusion d'un droit

Un déploiement d'IA générative sur des données personnelles cumule souvent deux critères (technologie innovante et, selon le cas, évaluation, surveillance ou données sensibles) : l'AIPD est alors obligatoire. La CNIL le rappelle dans ses recommandations sur le développement des systèmes d'IA (2024-2025).

Contenu de l'AIPD (article 35(7)) :

• Description systématique du traitement envisagé et de ses finalités
• Évaluation de la nécessité et de la proportionnalité au regard des finalités
• Évaluation des risques pour les droits et libertés des personnes
• Mesures envisagées pour faire face aux risques (techniques, organisationnelles, juridiques)

L'AIPD est réalisée avant la mise en œuvre du traitement par le responsable de traitement, qui demande conseil au DPO (article 35, paragraphe 2) et, le cas échéant, recueille l'avis des personnes concernées ou de leurs représentants (paragraphe 9). Elle est mise à jour quand le traitement évolue, conservée à disposition de la CNIL, et transmise à la CNIL pour consultation préalable si le risque résiduel reste élevé (article 36). Rien n'interdit de la partager avec le CSE : c'est même une bonne pratique quand des données de salariés sont concernées.

L'AI Act introduit un dispositif voisin mais distinct : l'analyse d'impact sur les droits fondamentaux (FRIA, Fundamental Rights Impact Assessment), prévue à l'article 27. Elle ne s'impose qu'à certains déployeurs de systèmes à haut risque de l'annexe III : organismes de droit public, entités privées fournissant des services publics, et déployeurs de systèmes d'évaluation de la solvabilité ou de tarification en assurance vie et santé. Une entreprise privée qui déploie un outil RH n'y est pas tenue, mais doit conduire l'AIPD si des données personnelles sont traitées.

Quand les deux analyses sont dues, l'article 27, paragraphe 4, prévoit expressément qu'elles peuvent être articulées : la FRIA complète l'AIPD déjà réalisée. Le DPO en est le coordinateur naturel.

Le chapitre V du RGPD (articles 44 à 49) encadre les transferts de données personnelles vers des pays tiers. Or la plupart des grands fournisseurs d'IA générative sont établis aux États-Unis, et leurs services impliquent souvent un traitement, au moins partiel, hors de l'Union.

Trois voies principales rendent un transfert licite :

1. Une décision d'adéquation de la Commission (article 45). Pour les États-Unis, il s'agit du cadre de protection des données UE-États-Unis (Data Privacy Framework, DPF), adopté le 10 juillet 2023 : les transferts vers une entreprise américaine certifiée sur la liste du ministère du Commerce sont autorisés sans garantie supplémentaire. Cette décision a été contestée par un député français : le Tribunal de l'Union a rejeté le recours le 3 septembre 2025 (affaire T-553/23, Latombe) ; un pourvoi est pendant devant la Cour de justice (C-703/25 P). La Cour avait invalidé les deux mécanismes précédents (Schrems I en 2015, Schrems II en 2020) : le risque d'invalidation existe, sans être imminent. En pratique, il faut vérifier la certification du fournisseur et qu'elle couvre bien les données RH si des données de salariés sont concernées.

2. Les clauses contractuelles types (article 46). Modèles de contrat adoptés par la Commission (décision 2021/914), à compléter par une analyse d'impact du transfert et, si nécessaire, par des mesures supplémentaires (chiffrement, pseudonymisation) selon les recommandations 01/2020 du Comité européen de la protection des données.

3. Les règles d'entreprise contraignantes (article 47). Réservées aux groupes internationaux, approuvées par l'autorité de contrôle compétente. Longues à obtenir.

Pour un outil d'IA générative, les questions à poser au fournisseur sont les suivantes :

• Où les prompts et les réponses sont-ils traités et stockés ? Une option de traitement dans l'Union est-elle proposée, et couvre-t-elle l'inférence ou seulement le stockage ?
• Le fournisseur est-il certifié au DPF, et sinon, propose-t-il des clauses contractuelles types dans son contrat de sous-traitance (article 28) ?
• Quels sous-traitants ultérieurs interviennent (hébergeur, support), et dans quels pays ?
• Le fournisseur s'engage-t-il à ne pas réutiliser les données pour entraîner ses modèles ?

L'analyse d'impact du transfert (Transfer Impact Assessment) documente ces réponses : pays de destination, données concernées, garanties contractuelles et techniques, risque d'accès par les autorités du pays tiers. Elle est exigée pour les clauses contractuelles types et constitue une bonne pratique même sous le DPF, compte tenu de l'incertitude contentieuse.

Pour les versions grand public des assistants : pas de contrat de sous-traitance négocié, conditions générales fixées unilatéralement, réutilisation possible des conversations pour l'entraînement, traitement hors de l'Union. Elles sont inadaptées à tout usage professionnel impliquant des données personnelles ou confidentielles, quelle que soit la nationalité de l'éditeur.