IA et RGPD : guide de conformité 2026 + checklist

L’essentiel. L’intelligence artificielle ne bénéficie d’aucune exemption au RGPD. Dès qu’un système d’IA traite des données personnelles — à l’entraînement, en production ou en sortie — le règlement s’applique intégralement : base légale (art. 6), AIPD (art. 35), encadrement des décisions automatisées (art. 22), transparence (art. 13-15), minimisation et sécurité. Depuis 2024, la CNIL a publié une doctrine dédiée qui sert de référence, et l’AI Act ajoute une couche d’obligations pour les systèmes à haut risque.

Vous entraînez un modèle sur vos données clients, vous branchez une IA générative sur vos documents internes, ou vous déployez un outil de scoring : à chaque fois, la question tombe — le RGPD s’applique-t-il, et à quelles conditions ? La réponse est courte : oui, sans dérogation. Ce qui varie, c’est comment démontrer la conformité. Ce guide passe en revue, point par point, les six chantiers à traiter pour déployer une IA conforme au RGPD en 2026, avec une checklist finale et un tableau de synthèse des obligations.

Il intègre la doctrine de la CNIL sur l’IA et son articulation avec l’AI Act.

1. Le RGPD s’applique à tous les traitements de données personnelles par l’IA

Point de départ non négociable : le RGPD ne comporte aucune dérogation pour les traitements réalisés par des systèmes d’IA. L’ensemble des principes, obligations et droits s’applique sans réserve. Trois moments du cycle de vie sont concernés :

• L’entraînement des modèles : lorsque des données personnelles servent à entraîner un modèle (données clients, comportementales, de navigation, images ou textes contenant des informations identifiantes), ce traitement est soumis au RGPD.
• Le fonctionnement opérationnel : lorsqu’un système traite des données en entrée pour produire un résultat (scoring, recommandation personnalisée, détection de fraude), le RGPD s’applique.
• Les données de sortie : lorsque les résultats de l’IA constituent eux-mêmes des données personnelles (scores, profils, prédictions rattachées à une personne identifiable), ces données relèvent aussi du RGPD.

La CNIL a confirmé cette lecture large dans ses recommandations publiées à partir de 2024 sur le développement des systèmes d’IA : la qualification de « traitement de données personnelles » doit s’apprécier de façon extensive dans le contexte de l’IA, y compris lorsqu’un modèle est susceptible de mémoriser et de restituer des données d’entraînement.

2. Choisir la bonne base légale

La détermination de la base légale est l’enjeu le plus délicat de la conformité IA. L’article 6 du RGPD impose que tout traitement repose sur l’une des six bases énumérées limitativement. Le choix dépend de la phase (entraînement ou production) et du contexte.

L’intérêt légitime (art. 6(1)(f))

Pour l’entraînement de modèles, la CNIL a reconnu que l’intérêt légitime peut constituer une base appropriée dans certains cas, sous réserve d’une mise en balance rigoureuse — le triple test — entre l’intérêt du responsable et les droits et libertés des personnes. Cette mise en balance doit intégrer des paramètres propres à l’IA :

• la nature et la sensibilité des données d’entraînement ;
• les attentes raisonnables des personnes quant à l’usage de leurs données ;
• les mesures de minimisation et de pseudonymisation mises en œuvre ;
• le risque que le modèle mémorise ou restitue des données d’entraînement ;
• les garanties supplémentaires (droit d’opposition facilité, information renforcée).

Le consentement (art. 6(1)(a))

Le consentement reste possible, mais ses exigences (libre, spécifique, éclairé, univoque) sont difficiles à réunir pour des corpus massifs et hétérogènes. Le retrait pose surtout un défi technique majeur : comment neutraliser l’influence des données d’une personne sur un modèle déjà entraîné ?

L’exécution d’un contrat (art. 6(1)(b))

Lorsque l’IA fournit un service contractuellement prévu (personnalisation, assistance), l’exécution du contrat peut fonder le traitement opérationnel. Elle est en revanche généralement inadaptée à l’entraînement du modèle, qui dépasse le périmètre du contrat conclu avec la personne concernée.

Obligation légale et mission d’intérêt public (art. 6(1)© et (e))

Pour les organismes publics ou les entités soumises à des obligations légales spécifiques (lutte contre la fraude, santé publique), ces bases peuvent s’appliquer, sous réserve d’un fondement dans le droit de l’Union ou national.

Le cas des données sensibles

Si l’entraînement ou l’exploitation mobilise des données sensibles (santé, opinions, données biométriques d’identification), l’article 9 impose une exception spécifique (consentement explicite, intérêt public important, etc.) en plus de la base de l’article 6. La simple présence incidente de telles données dans un corpus web ne suffit pas à lever l’interdiction de principe.

3. Encadrer les décisions automatisées (article 22)

L’article 22 du RGPD accorde aux personnes 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 ou l’affectant de manière significative. C’est directement pertinent pour de nombreux systèmes d’IA :

• un algorithme de crédit qui refuse automatiquement un prêt ;
• un tri de CV qui écarte des candidatures sans revue humaine ;
• un outil qui bloque automatiquement des transactions ;
• une tarification dynamique en assurance fondée sur le profilage.

Les trois exceptions

L’article 22(2) admet la décision entièrement automatisée dans trois cas : lorsqu’elle est nécessaire à un contrat, autorisée par le droit de l’Union ou d’un État membre, ou fondée sur le consentement explicite. Dans tous les cas, des garanties minimales sont exigées :

• le droit d’obtenir une intervention humaine ;
• le droit d’exprimer son point de vue ;
• le droit de contester la décision.

L’« intervention humaine » doit être réelle : une validation formelle par un opérateur qui entérine systématiquement la sortie du modèle sans marge d’appréciation ne suffit pas à sortir du champ de l’article 22. Voir notre guide sur les décisions automatisées.

Le cumul avec l’AI Act

L’AI Act impose un contrôle humain pour les systèmes à haut risque (article 14). Ces exigences se cumulent avec l’article 22 du RGPD et créent un cadre renforcé pour les systèmes décisionnels traitant des données personnelles. Pour savoir si votre système est concerné, voir la classification des risques de l’IA Act.

4. Réaliser l’analyse d’impact (AIPD)

Quand l’AIPD est-elle obligatoire ?

L’article 35 impose une analyse d’impact (AIPD) lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés. Les lignes directrices du CEPD (WP248) listent neuf critères ; la présence d’au moins deux d’entre eux rend l’AIPD généralement obligatoire :

Critère (WP248)	Fréquent en IA ?
Évaluation ou notation (scoring, profilage)	Très fréquent
Décision automatisée à effet juridique	Fréquent
Surveillance systématique	Fréquent
Données sensibles ou hautement personnelles	Selon le cas
Traitement à grande échelle	Très fréquent
Croisement de jeux de données	Fréquent
Personnes vulnérables	Selon le cas
Usage innovant / nouvelle technologie	Quasi systématique
Traitement empêchant l’exercice d’un droit	Selon le cas

En pratique, la plupart des systèmes d’IA traitant des données personnelles remplissent au moins deux critères : l’AIPD devient quasi systématique. Notre guide dédié détaille la marche à suivre : AIPD pour l’IA.

Les éléments spécifiques à l’IA dans l’AIPD

L’AIPD d’un système d’IA doit intégrer des analyses propres à la technologie :

• le risque de biais algorithmiques et de discrimination ;
• l’opacité du modèle et ses conséquences sur les droits des personnes ;
• la qualité et la représentativité des données d’entraînement ;
• le risque de mémorisation et d’extraction de données personnelles ;
• la robustesse face aux attaques adversariales.

5. Transparence, information et droits des personnes

Les articles 13 et 14 imposent d’informer les personnes de l’existence d’un traitement automatisé, de fournir des informations utiles sur la logique sous-jacente et de communiquer sur l’importance et les conséquences du traitement. La transparence n’impose pas de divulguer le code source, mais suppose des explications compréhensibles sur les facteurs pris en compte et leurs effets.

L’article 15 étend le droit d’accès à ces mêmes informations, ce qui suppose d’intégrer des mécanismes d’explicabilité dès la conception. Les autres droits restent pleinement exerçables :

• rectification des données inexactes utilisées ou produites ;
• opposition au traitement (voir le droit d’opposition), notamment lorsque la base est l’intérêt légitime ;
• effacement (voir ci-dessous).

Le droit à l’effacement face aux modèles entraînés

L’article 17 consacre le droit à l’effacement. Son application à l’IA soulève des questions techniques inédites : une fois le modèle entraîné, l’information est encodée de façon diffuse dans ses paramètres. La CNIL distingue :

• les données d’entraînement elles-mêmes : leur suppression doit être possible et effective ;
• l’influence des données sur le modèle : la CNIL admet, de façon pragmatique, que l’effacement des données d’entraînement peut suffire sans imposer un ré-entraînement complet, à condition que les risques de mémorisation et d’extraction soient suffisamment faibles et documentés (tests de mémorisation, évaluation du risque d’extraction).

6. Minimisation, sécurité et gouvernance

Le paradoxe de la minimisation

Le principe de minimisation (art. 5(1)©) impose des données adéquates, pertinentes et limitées au nécessaire — ce qui entre en tension apparente avec l’appétit des modèles pour les grands volumes. La CNIL identifie plusieurs leviers de conciliation :

• anonymisation en amont : quand les données personnelles ne sont pas nécessaires, l’anonymisation préalable fait sortir du champ du RGPD ;
• pseudonymisation : remplacer les identifiants directs réduit le risque sans dégrader nécessairement la performance ;
• apprentissage fédéré : les données restent sur les terminaux, seuls les paramètres circulent ;
• confidentialité différentielle : l’ajout de bruit statistique limite la reconstitution de données individuelles ;
• sélection rigoureuse des variables au regard de la finalité.

Ces enjeux sont particulièrement aigus dans les systèmes de RAG (génération augmentée par récupération), où la base documentaire interrogée contient souvent des données personnelles à strictement circonscrire.

Sécurité des traitements d’IA

L’article 32 impose des mesures de sécurité adaptées au risque. Pour l’IA, cela couvre des menaces spécifiques : attaques adversariales, vol et inversion de modèle, empoisonnement des données d’entraînement, fuites par mémorisation, injection de prompt. L’AI Act ajoute des exigences de cybersécurité pour les systèmes à haut risque.

Sous-traitance et outils tiers

Dès lors que vous utilisez un fournisseur d’IA (API, SaaS), celui-ci agit le plus souvent en sous-traitant : un contrat conforme à l’article 28 est requis, précisant finalités, sécurité, transferts hors UE et sort des données en fin de contrat. Documentez le tout dans votre registre des traitements.

Tableau de synthèse des obligations

Chantier	Article RGPD	Livrable attendu
Base légale	Art. 6 (et 9 si sensible)	Analyse de base légale, triple test si intérêt légitime
Décisions automatisées	Art. 22	Garanties : intervention humaine, contestation
AIPD	Art. 35	Analyse d’impact documentée
Transparence	Art. 13-15	Mentions d’information + explicabilité
Minimisation	Art. 5(1)©	Mesures de réduction des données
Sécurité	Art. 32	Mesures techniques contre menaces IA
Sous-traitance	Art. 28	Contrat de sous-traitance conforme
Registre	Art. 30	Inscription des traitements IA

Checklist de conformité IA RGPD

• [ ] Tous les systèmes d’IA traitant des données personnelles sont cartographiés
• [ ] Une base légale est identifiée pour chaque phase (entraînement / production)
• [ ] Le triple test est réalisé si la base est l’intérêt légitime
• [ ] Les données sensibles sont couvertes par une exception de l’article 9
• [ ] Les décisions automatisées à effet significatif sont encadrées (art. 22)
• [ ] Une AIPD est réalisée pour les traitements à risque élevé
• [ ] Les mentions d’information couvrent la logique et les conséquences
• [ ] Les droits (accès, rectification, opposition, effacement) sont opérationnels
• [ ] Les mesures de minimisation et de sécurité sont documentées
• [ ] Les fournisseurs d’IA sont liés par un contrat de sous-traitance conforme
• [ ] Les traitements figurent au registre

Articulation avec l’AI Act

L’AI Act et le RGPD sont deux textes distincts mais complémentaires : le RGPD protège les données personnelles, l’AI Act encadre la mise sur le marché et l’usage des systèmes d’IA selon leur niveau de risque. Leurs obligations se superposent pour un système à haut risque traitant des données personnelles. Le déploiement de l’AI Act s’échelonne jusqu’en 2027 ; pour suivre les échéances applicables, consultez le calendrier de l’AI Act et notre veille IA 2026.

La complexité de cette double conformité justifie souvent un outillage dédié : un logiciel RGPD permet d’industrialiser la tenue du registre, la production des AIPD et le suivi de l’exercice des droits pour un parc d’outils d’IA. Pour une revue complète de l’existant, un audit RGPD constitue le point de départ.

Guides pratiques par outil d’IA

L’analyse ci-dessus vaut pour tous les outils. Pour une évaluation par fournisseur — DPA, transferts, sécurité, configuration recommandée — consultez nos guides dédiés :

• Claude (Anthropic) et RGPD : guide de conformité
• ChatGPT et RGPD : ce que dit la CNIL
• RGPD et outils : guide de conformité par logiciel

FAQ

Le RGPD s’applique-t-il vraiment à l’entraînement d’un modèle d’IA ?

Oui. Dès que des données personnelles servent à entraîner un modèle, il s’agit d’un traitement soumis à l’article 6. Il faut une base légale (souvent l’intérêt légitime, sous réserve d’un triple test), des mesures de minimisation et une information des personnes. Le fait que les données proviennent de sources publiques ne les fait pas sortir du RGPD.

Une AIPD est-elle obligatoire pour un système d’IA ?

Dans la grande majorité des cas, oui. Les systèmes d’IA remplissent généralement au moins deux des critères déclencheurs du CEPD (traitement à grande échelle, décision automatisée, usage innovant, profilage). L’AIPD doit intégrer les risques propres à l’IA : biais, opacité, qualité des données, mémorisation.

L’article 22 interdit-il les décisions prises par une IA ?

Il donne le droit de ne pas faire l’objet d’une décision exclusivement automatisée produisant des effets juridiques ou significatifs. Des exceptions existent (contrat, consentement explicite, droit national), mais dans tous les cas, l’intervention humaine, l’expression du point de vue et la contestation doivent être garanties. Une supervision humaine purement formelle ne suffit pas.

Comment gérer le droit à l’effacement avec un modèle déjà entraîné ?

La CNIL distingue les données d’entraînement (leur suppression doit être possible) de l’influence encodée dans le modèle. La suppression des données d’entraînement peut suffire sans ré-entraîner le modèle, à condition que les risques de mémorisation soient faibles et documentés par des tests d’extraction.

Quelles mesures de sécurité spécifiques pour une IA ?

Au-delà des mesures classiques de l’article 32, les systèmes d’IA appellent une protection contre les attaques adversariales, le vol et l’inversion de modèle, l’empoisonnement des données et les fuites par mémorisation. L’AI Act ajoute des exigences de cybersécurité pour les systèmes à haut risque.

Un fournisseur d’IA générative est-il sous-traitant ou responsable de traitement ?

Cela dépend de qui détermine les finalités. Lorsque vous utilisez une API pour vos propres finalités, le fournisseur agit en principe comme sous-traitant et doit être lié par un contrat conforme à l’article 28. S’il réutilise vos données pour entraîner ses propres modèles à ses fins, il peut devenir responsable de traitement pour cette réutilisation : vérifiez précisément ce que prévoit sa documentation contractuelle.