Conformité RGPD et IA générative : où sont les pièges

Le RGPD (Règlement Général sur la Protection des Données, Règlement (UE) 2016/679) s'applique à tout système IA générative qui traite des données personnelles — c'est-à-dire la quasi-totalité des déploiements production en 2026. Mais le RGPD a été pensé en 2016, avant ChatGPT, avant le RAG enterprise, avant les agents IA. L'application au monde IA générative pose des questions inédites : que faire d'un modèle entraîné sur des données personnelles ? D'une hallucination qui ressemble à une vraie personne ? D'un transfert international vers OpenAI ? D'une demande d'effacement sur un modèle déjà déployé ? Cet article documente les 7 pièges principaux, les recommandations CNIL/CEPD, et des mitigations concrètes par cas.

Pour le pendant EU AI Act (règlement IA distinct, complémentaire) : EU AI Act pour entreprises. Pour les recommandations ANSSI françaises : recommandations ANSSI IA.

RGPD vs EU AI Act : coexistence

Avant les pièges, clarifier la coexistence :

Les deux règlements coexistent et se cumulent. Une violation RGPD via un système IA peut déclencher des sanctions des deux côtés.

Info — La CNIL a publié plusieurs recommandations spécifiques IA depuis 2023-2024 sur cnil.fr. Le CEPD (Comité européen de la protection des données) coordonne les positions au niveau UE.

Sept pièges principaux

Piège 1 — Données personnelles dans le training set

Le piège : entraîner ou fine-tuner un modèle sur des données contenant des informations personnelles (emails, noms, adresses, identifiants) sans base légale claire.

Pourquoi c'est un problème :

• Les données sont encodées dans les poids du modèle.
• La membership inference et le verbatim extraction (Carlini 2021) permettent de reconstituer (cf. membership inference).
• Conséquence : tout entraînement sur des données personnelles est un traitement RGPD au sens Article 4.
• Base légale obligatoire (Article 6) : consentement, intérêt légitime, contrat, etc.

Mitigations :

# Politique training data
data_sources_allowed:
  - synthetic_data: "données synthétiques générées sans PII"
  - public_consented: "données publiques avec consentement explicite"
  - own_users_with_consent: "données utilisateurs avec consentement spécifique IA"
  - pseudonymized: "données pseudonymisées (Art. 4.5 RGPD)"
 
data_sources_forbidden:
  - scraping_without_legal_basis
  - personal_data_without_consent
  - sensitive_data_without_special_basis  # Article 9 RGPD
  - children_data_without_specific_consent  # Article 8 RGPD

Recommandation pratique : pour LLMs frontier (GPT-4, Claude, etc.) entraînés par des tiers, vérifier la base légale du provider (CGU, transparency reports). Pour fine-tuning interne, préférer données synthétiques ou pseudonymisées.

Piège 2 — Données personnelles dans les prompts utilisateurs

Le piège : les utilisateurs incluent des données personnelles (les leurs, ou de tiers) dans leurs prompts. Ces prompts sont envoyés à des LLMs, parfois logged, parfois utilisés pour amélioration.

Pourquoi c'est un problème :

• Le prompt est un traitement de données personnelles.
• Si envoyé à un LLM externe (OpenAI, Anthropic) : transfert international + sous-traitance.
• Si logged : politique de rétention RGPD applicable.
• Si utilisé pour ré-entraînement : nouveau traitement nécessitant base légale.

Mitigations :

• Information utilisateur (Articles 13/14) : indiquer clairement que les prompts sont traités, par qui, où, pour quoi.
• Pseudonymisation à l'ingestion (Microsoft Presidio en pré-traitement) :

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
 
analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()
 
def pseudonymize_prompt(prompt: str) -> tuple[str, dict]:
    """Pseudonymise les PII dans le prompt avant envoi au LLM."""
    pii_results = analyzer.analyze(text=prompt, language="fr")
    
    if not pii_results:
        return prompt, {}
    
    # Anonymisation avec mapping inverse
    anonymized = anonymizer.anonymize(
        text=prompt,
        analyzer_results=pii_results,
    )
    
    # Stocker le mapping inverse côté serveur (pas envoyé au LLM)
    mapping = {a.replacement: a.original for a in anonymized.items}
    
    return anonymized.text, mapping
 
# À la sortie : optionnellement reconstituer les PII pour l'utilisateur
def restore_pii(llm_response: str, mapping: dict) -> str:
    for marker, original in mapping.items():
        llm_response = llm_response.replace(marker, original)
    return llm_response

• Politique de rétention claire : durée minimale nécessaire, suppression automatique.
• Choix endpoint UE : Azure OpenAI EU, Anthropic via Vertex EU, Mistral en France.

Piège 3 — Données personnelles dans le RAG corpus

Le piège : pipelines RAG ingèrent des documents qui contiennent des données personnelles (emails, dossiers RH, contrats, comptes-rendus). Ces données :

• Sont indexées en clair (vector + metadata).
• Peuvent être retournées à des utilisateurs n'ayant pas le droit d'y accéder.
• Sont sujettes à embedding inversion (Vec2Text) — voir model inversion.

Mitigations :

• Classification de sensibilité par chunk + ACL strictes au retrieval.
• Pseudonymisation des PII avant indexation pour les corpus à risque.
• Tenant isolation forte + double filtre pre/post retrieval.
• Audit logs des requêtes + chunks retrievés.

Voir architecture RAG sécurisée.

Piège 4 — Hallucinations qui correspondent à des personnes réelles

Le piège : le LLM produit en sortie un nom, une adresse, un numéro qui correspond par hasard (ou par mémorisation) à une personne réelle.

Pourquoi c'est un problème :

• Position dominante CNIL/CEPD : oui, c'est un traitement de données personnelles si la sortie permet d'identifier la personne.
• La personne peut exercer ses droits (rectification, effacement).
• Sanctions possibles si la sortie est diffamatoire ou erronée.

Cas réels : plusieurs procédures CNIL/CEPD contre OpenAI et autres pour hallucinations diffamatoires.

Mitigations :

• Output filter spécifique détectant les références à des personnes réelles :

def filter_personal_references(output: str, allowed_persons: set = None) -> str:
    """Filtre les références à des personnes physiques dans la sortie."""
    pii = analyzer.analyze(text=output, language="fr")
    persons = [r for r in pii if r.entity_type == "PERSON"]
    
    for p in persons:
        person_name = output[p.start:p.end]
        if allowed_persons and person_name in allowed_persons:
            continue  # personne autorisée (ex: contexte spécifique)
        # Sinon, masquer ou avertir
        output = output[:p.start] + "[PERSONNE]" + output[p.end:]
    
    return output

• Disclaimers : indiquer clairement que les sorties peuvent être imprécises.
• Procédure de rectification : permettre aux personnes de signaler les hallucinations les concernant. Plusieurs éditeurs (OpenAI, Anthropic) ont mis en place des formulaires dédiés.

Piège 5 — Droits des personnes sur les modèles entraînés

Le piège : une personne demande l'effacement (Art. 17), la rectification (Art. 16), ou l'accès (Art. 15) à ses données dans un modèle entraîné. Techniquement très difficile.

Pourquoi c'est un problème :

• Les données sont encodées dans les poids, pas isolables.
• Ré-entraîner sans la donnée = coûteux (trillions tokens, semaines GPU, M€).
• Machine unlearning = recherche active mais pas mature pour LLMs frontier.

Mitigations :

Pour les RAG : effacement plus simple (suppression document → ré-indexation).

Pour les modèles entraînés : argumenter l'impossibilité technique disproportionnée (Article 17.3 RGPD). La position CNIL/CEPD évolue en 2025-2026.

Piège 6 — Transferts internationaux

Le piège : utiliser un LLM US (OpenAI, Anthropic, Google) avec données personnelles UE = transfert de données vers les États-Unis.

Cadre juridique :

• Schrems II (CJUE 2020) : invalidation Privacy Shield, exigence de garanties adéquates.
• Data Privacy Framework (DPF) UE-US : adopté juillet 2023, considéré comme adéquat — mais exposition à un nouveau Schrems III possible.
• Clauses contractuelles types (CCT) : restent obligatoires si DPF non utilisable.
• Cloud Act US : permet aux autorités US d'accéder aux données stockées par entreprises US, même hors US.

Mitigations :

# Décision data residency par sensibilité
data_residency_policy:
  public_data:
    allowed: "any provider"
  
  internal_business:
    allowed: ["EU regions of hyperscalers"]
    forbidden: ["non-EU regions"]
    notes: "DPF + DPA + CCT en place"
  
  personal_data_normal:
    allowed: ["EU regions of hyperscalers", "EU sovereign cloud"]
    forbidden: ["US regions"]
    notes: "DPA obligatoire, Schrems II analysis documented"
  
  sensitive_personal_data:
    allowed: ["SecNumCloud only", "EU sovereign cloud"]
    forbidden: ["all US providers including EU regions if Cloud Act applies"]
    notes: "Avis CNIL si applicable"
  
  oiv_or_state_data:
    allowed: ["SecNumCloud certified"]
    notes: "Conformité ANSSI obligatoire"

Endpoints UE recommandés :

• Azure OpenAI : régions UE explicites (France, Suède, Pays-Bas).
• Anthropic via Google Vertex AI : régions UE.
• Mistral (FR) : hébergement souverain disponible.
• OVHcloud : LLMs hébergés sur infrastructure souveraine.

Piège 7 — DPIA / FRIA absents ou superficiels

Le piège : déployer un système IA générative sans Data Protection Impact Assessment (Art. 35 RGPD) et/ou sans Fundamental Rights Impact Assessment (EU AI Act Art. 27 si haut risque).

Quand DPIA obligatoire : selon Article 35 RGPD :

• Risque élevé pour les droits et libertés.
• Évaluation systématique d'aspects personnels (profilage).
• Traitement à grande échelle de données sensibles.
• Surveillance systématique d'une zone.
• Liste CNIL des traitements obligatoirement soumis à DPIA inclut explicitement plusieurs cas IA.

Contenu obligatoire DPIA (Art. 35.7) :

1. Description du traitement.
2. Évaluation de la nécessité et proportionnalité.
3. Évaluation des risques pour les droits et libertés.
4. Mesures envisagées pour traiter les risques.

Combinaison DPIA + FRIA : pour systèmes haut-risque EU AI Act, FRIA distincte mais souvent à faire en parallèle. Templates CNIL et EU Commission disponibles.

Mitigation : faire le DPIA avant déploiement, pas après. Le réviser annuellement ou à chaque changement majeur.

Recommandations CNIL spécifiques IA

La CNIL a publié plusieurs recommandations 2023-2024 :

Constitution de bases de données pour l'IA

• Critères de licéité de la constitution de datasets.
• Conditions d'usage de données publiques (web scraping nuance).
• Encadrement des datasets achetés.
• Anonymisation et pseudonymisation.

Développement de systèmes IA

• Privacy by design dès la conception.
• Analyse d'impact obligatoire pour cas à risque.
• Documentation technique (alignée avec Article 11 EU AI Act).
• Mesures de sécurité.

Déploiement

• Information des utilisateurs.
• Exercice des droits.
• Surveillance humaine pour décisions critiques.
• Audit régulier.

Formulaires CNIL

• Formulaire DPIA en ligne.
• Notification de violation Article 33 (sous 72h).
• Demande de consultation préalable Article 36 si risque résiduel élevé.

Plan de mise en conformité

Étape 1 — Inventaire (mois 1)

# Inventaire systèmes IA + RGPD
ai_systems_rgpd:
  - id: AS-001
    name: "Chatbot support clients"
    personal_data_processed: true
    data_categories: ["nom", "email", "historique support"]
    data_subjects: "clients"
    legal_basis: "intérêt légitime (Art. 6.1.f)"
    dpia_required: true  # à vérifier
    dpia_completed: false  # gap
    international_transfer: true  # OpenAI US
    transfer_safeguards: "DPF + DPA + CCT"
    
  - id: AS-002
    name: "Outil sélection candidats"
    personal_data_processed: true
    data_categories: ["CV complet", "candidature"]
    data_subjects: "candidats"
    legal_basis: "consentement (Art. 6.1.a) + intérêt légitime"
    dpia_required: true
    dpia_completed: yes
    fria_required: true  # haut risque EU AI Act
    fria_completed: false  # gap

Étape 2 — Analyse juridique par système

• Base légale identifiée et documentée.
• Données traitées minimisées (Article 5.1.c).
• Durées de conservation définies (Article 5.1.e).

Étape 3 — DPIA + FRIA

Pour les systèmes à risque élevé :

• DPIA selon template CNIL.
• FRIA si haut risque EU AI Act.
• Validation par DPO + AI Risk Officer.

Étape 4 — Mesures techniques

• Pseudonymisation aux ingestions.
• Output filter sur PII.
• Audit logs RGPD-compliant.
• Endpoints UE pour les systèmes traitant des PII.

Étape 5 — Information et droits

• Mentions d'information à jour (Articles 13/14).
• Procédures pour exercice des droits.
• Procédure de notification incidents (Article 33 sous 72h).

Étape 6 — Audit et amélioration

• Audit interne RGPD annuel minimum.
• Re-DPIA si changement majeur.
• Veille CNIL/CEPD continue.

Mapping pratiques RGPD ↔ EU AI Act

Mise en conformité combinée RGPD + EU AI Act = rationalisable en pratique. DPIA + FRIA souvent en un document unique.

Pièges fréquents en implémentation

Outils opérationnels

Évolutions attendues 2026-2027

• Position CNIL/CEPD sur unlearning : guidances probables sur droit à l'effacement modèles entraînés.
• Précédents jurisprudentiels IA : décisions CNIL et tribunaux sur cas IA, premiers retours d'expérience.
• Évolution DPF UE-US : potentiel Schrems III (recours déjà déposés).
• Articulation RGPD + EU AI Act : guidances communes attendues, formulaires intégrés.
• Sectoriel : recommandations spécifiques santé, RH, finance attendues.

Points clés à retenir

• Le RGPD s'applique à tout système IA générative traitant des données personnelles. La quasi-totalité des déploiements production en 2026.
• 7 pièges principaux : training data, prompts utilisateurs, RAG corpus, hallucinations, droits des personnes (effacement quasi-impossible sur modèle entraîné), transferts internationaux (Schrems II + DPF), DPIA absent ou superficiel.
• DPIA (RGPD Art. 35) distinct de FRIA (EU AI Act Art. 27) — souvent à faire conjointement.
• Hallucinations identifiables = traitement de données personnelles selon CNIL/CEPD. Output filter PII obligatoire.
• Droits sur modèle entraîné : rectification possible via output filter, effacement complet quasi-impossible techniquement (argumentation Art. 17.3).
• Transferts internationaux : DPF UE-US adopté juillet 2023 mais fragile. Préférer endpoints UE (Azure OpenAI EU, Vertex EU, Mistral, OVHcloud).
• CNIL publie recommandations spécifiques IA depuis 2023-2024 — surveiller cnil.fr.
• Sanctions : 20M€ ou 4% CA RGPD. Cumul possible avec EU AI Act (35M€ / 7%).
• Pseudonymisation ≠ anonymisation. La première reste RGPD, la seconde est très difficile sur LLM.
• Mapping RGPD ↔ EU AI Act : rationalisable en pratique. DPIA + FRIA souvent un document unique.

Le RGPD est une contrainte structurante pour les déploiements IA générative. Pas un obstacle insurmontable, mais nécessite une démarche rigoureuse : inventaire, analyse juridique par système, DPIA + FRIA pour les cas à risque, mesures techniques (pseudonymisation, output filter, endpoints UE), procédures pour exercice des droits. Combiné avec EU AI Act, c'est un programme de conformité à anticiper et à maintenir dans la durée.