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.