IA et RGPD : obligations et checklist de conformité

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, il faut identifier les données traitées, les responsabilités et les conditions d’utilisation. La conformité se vérifie à chaque phase, avec les règles correspondant au traitement réel.

Ce guide présente les six chantiers à traiter pour développer ou utiliser une IA dans le respect du RGPD. Il tient compte du cadre européen consulté au 26 septembre 2026. Le recours à l’IA ne crée pas une exemption générale ; il ne rend pas non plus toutes les obligations identiques pour chaque projet.

Ce qu’il faut retenir

• Analysez séparément les données d’entraînement, les entrées, les sorties et les éventuelles données mémorisées dans le modèle.
• Définissez une finalité et une base légale pour chaque traitement. Des données accessibles sur le web ne sont pas librement réutilisables pour tout objectif.
• L’AIPD dépend du risque élevé pour les personnes. L’étiquette « IA » ne remplace pas cette analyse.
• L’article 22 concerne les décisions exclusivement automatisées ayant des effets juridiques ou significatifs comparables ; toutes les recommandations algorithmiques n’entrent pas automatiquement dans ce cadre.
• Organisez l’exercice des droits dans le système réel, y compris les bases documentaires, historiques et modèles concernés.

1. Déterminer les données et les responsabilités

Un traitement automatisé portant sur une personne identifiée ou identifiable relève du RGPD dans son champ d’application. Les données personnelles peuvent intervenir lors de la constitution du corpus, de l’apprentissage, de l’utilisation ou dans les résultats. Un score ou une prédiction rattachée à une personne peut constituer une donnée personnelle, même si l’information est déduite. RGPD, art. 2(1), 4(1) et 4(2).

Dressez une carte des données : sources, personnes concernées, champs, destinataires, lieux d’accès, conservations et opérations. Pour un outil connecté à des documents internes, incluez la base documentaire interrogée et les droits d’accès des utilisateurs. Pour une API, ajoutez les requêtes, les réponses et les journaux du prestataire.

Le statut du modèle entraîné exige une analyse propre. La CNIL demande de documenter la possibilité de réidentifier une personne ou d’extraire ses données avec des moyens raisonnablement susceptibles d’être employés. Un modèle anonyme ne rend pas anonymes les nouvelles données personnelles que l’utilisateur lui soumet. Quelques requêtes sans résultat nominatif ne suffisent pas à démontrer l’anonymat. CNIL, analyse du statut d’un modèle d’IA.

Le responsable du traitement détermine les finalités et les moyens ; le sous-traitant traite les données pour son compte. Ces rôles peuvent varier selon l’opération. Un fournisseur peut agir sur instruction pour votre service et poursuivre une finalité propre pour une autre réutilisation. Examinez les faits, le contrat et les réglages, sans attribuer automatiquement le rôle de sous-traitant à tout service SaaS. RGPD, art. 4(7), 4(8), 26(1) et 28(10).

2. Choisir la base légale et encadrer les réutilisations

L’article 6(1) énumère six bases légales. Le choix dépend de la finalité, de la relation avec les personnes et de la nécessité du traitement. La base de l’entraînement n’est pas automatiquement celle du déploiement. Si vous réutilisez des données pour un autre objectif, examinez aussi la compatibilité prévue par l’article 6(4), lorsqu’elle est applicable, et l’information préalable requise. RGPD, art. 5(1)(b), 6(1), 6(4), 13(3) et 14(4).

L’intérêt légitime, article 6(1)(f), suppose un intérêt licite, la nécessité du traitement et une mise en balance avec les droits des personnes. Dans un projet d’IA, examinez les attentes raisonnables, la nature des données, la mémorisation possible, les effets de la diffusion et les garanties effectives. Il ne s’agit pas d’une base par défaut ; les autorités publiques ne peuvent l’invoquer dans l’exécution de leurs missions. RGPD, art. 6(1)(f) et dernier alinéa ; CNIL, intérêt légitime pour développer une IA.

Le consentement, article 6(1)(a), reste possible s’il est libre, spécifique, éclairé et univoque, et si son retrait peut être exercé. Une autorisation pour recevoir un service ne couvre pas automatiquement un entraînement distinct. Le contrat, article 6(1)(b), exige une nécessité objective pour le contrat conclu avec la personne : écrire « amélioration de l’IA » dans des conditions générales ne suffit pas. La CNIL n’exclut pas cette base pour tout apprentissage, mais exige que ses conditions soient réunies. RGPD, art. 4(11), 6(1)(a)–(b) et 7(3) ; CNIL, définir une base légale.

L’obligation légale et la mission d’intérêt public, articles 6(1)(c) et 6(1)(e), nécessitent un fondement juridique répondant à l’article 6(3). Un objectif utile ou une ambition générale de lutte contre la fraude ne démontre pas, seul, cette nécessité. RGPD, art. 6(1)(c), 6(1)(e) et 6(3).

Les données sensibles exigent, en plus de la base légale, une exception à l’interdiction de l’article 9(1). L’intérêt légitime ne lève pas cette interdiction. Le nouvel article 4a de l’AI Act autorise exceptionnellement certains traitements strictement nécessaires à la détection et à la correction de biais, sous garanties cumulatives : ce n’est pas une autorisation générale de collecter des données sensibles pour améliorer un modèle. RGPD, art. 9(1)–(2) ; règlement 2026/1744, art. 1(6).

3. Examiner le processus de décision

L’article 22(1) encadre les décisions fondées exclusivement sur un traitement automatisé qui produisent des effets juridiques ou affectent une personne de manière significative comparable. Un refus automatique de candidature ou de crédit appelle cette analyse. Une aide à la rédaction sans effet décisionnel sur une personne n’entre pas, pour ce seul usage, dans la même catégorie. RGPD, art. 22(1).

L’article 22(2) prévoit trois voies : nécessité contractuelle, autorisation par le droit avec garanties appropriées, ou consentement explicite. Pour les voies du contrat et du consentement, le paragraphe 3 exige au moins l’intervention humaine, la possibilité d’exprimer son point de vue et de contester la décision. Pour l’autorisation légale, les garanties doivent résulter du cadre visé au paragraphe 2(b). Les catégories particulières de données font en outre l’objet de la restriction du paragraphe 4. RGPD, art. 22(2) à 22(4).

Décrivez concrètement qui décide, à quel moment et avec quels pouvoirs. Une signature humaine ne démontre pas à elle seule qu’un examen effectif a eu lieu. Notre guide des décisions automatisées au sens du RGPD détaille l’analyse du processus et les garanties à organiser.

4. Décider si une AIPD est requise

L’article 35(1) exige une AIPD avant un traitement susceptible d’engendrer un risque élevé pour les droits et libertés. Les cas de l’article 35(3) et les listes de l’autorité compétente doivent également être examinés. Ne réduisez pas cette décision à un calcul mécanique du nombre de critères. RGPD, art. 35(1), 35(3) et 35(4).

La CNIL précise que toute IA n’est pas un usage innovant et que le volume total d’un corpus ne suffit pas à qualifier la grande échelle : les personnes et données personnelles concernées comptent. Elle présume nécessaire une AIPD pour le développement de systèmes à haut risque impliquant des données personnelles. Ces repères aident l’analyse, sans transformer chaque projet en obligation automatique. CNIL, réaliser une AIPD si nécessaire.

L’AIPD pour un système d’IA doit décrire le traitement, sa nécessité, les risques et les mesures retenues. Examinez notamment les divulgations, les inférences préjudiciables, la discrimination, les erreurs et les difficultés d’exercice des droits. Si un risque élevé subsiste en l’absence de mesures suffisantes, l’article 36(1) prévoit une consultation préalable de l’autorité. RGPD, art. 35(7) et 36(1).

5. Informer et rendre les droits praticables

Les articles 13 et 14 imposent notamment l’information sur les finalités, la base légale, les destinataires, les durées et les droits. Les dispositions particulières sur la logique sous-jacente et les conséquences visent les décisions automatisées mentionnées à l’article 22(1) et 22(4) : elles ne sont pas une exigence identique d’explication algorithmique pour tout traitement automatisé. RGPD, art. 13(1)–(2), 14(1)–(2) et 15(1)(h).

Une collecte indirecte sur le web ne dispense pas automatiquement d’information individuelle. L’exception pour impossibilité ou efforts disproportionnés de l’article 14(5)(b) doit être justifiée ; elle s’accompagne de mesures appropriées, dont la mise à disposition publique des informations. Une simple notice en ligne ne remplace donc pas systématiquement la démarche requise. RGPD, art. 14(3) et 14(5)(b).

L’effacement connaît des conditions et exceptions, l’opposition dépend du fondement du traitement et la portabilité a son propre périmètre. La réponse doit intervenir dans les meilleurs délais, en principe sous un mois, avec prolongation motivée possible de deux mois selon les conditions légales. RGPD, art. 12(3), 17(1)–(3), 20(1) et 21(1)–(3).

Pour un modèle non anonyme, distinguez la suppression dans le corpus et la réponse concernant les données mémorisées. La CNIL examine notamment le réentraînement et, subsidiairement, des filtres dont l’efficacité et la robustesse sont démontrées lorsque le réentraînement est impossible ou disproportionné. Un filtre ne supprime pas les données des paramètres. La réponse doit expliquer les mesures réellement prises ; une faible probabilité de restitution ne constitue pas une dispense générale d’examiner la demande. CNIL, exercice des droits dans l’IA.

6. Minimiser, sécuriser et encadrer les prestataires

Le principe de minimisation impose des données adéquates, pertinentes et limitées au nécessaire. Écartez les champs inutiles, réduisez les accès et définissez les conservations selon les finalités. Une pseudonymisation réduit certains risques sans faire sortir les données du RGPD ; une anonymisation doit être réellement démontrée. RGPD, art. 5(1)(c), 5(1)(e), 4(5) et considérant 26.

L’article 32 exige une sécurité adaptée aux risques. Pour l’IA, la CNIL recommande d’examiner les composants, les sources de données, les interfaces et les possibilités d’extraction ou d’altération. Les contrôles d’accès et la sécurité des logiciels ordinaires restent essentiels : toute attaque n’a pas besoin de cibler les paramètres du modèle. RGPD, art. 32(1)–(2) ; CNIL, sécurité du développement IA.

Lorsque le prestataire est sous-traitant, le contrat de l’article 28(3) doit traiter notamment des instructions, de la sécurité, de l’assistance et du sort des données. Vérifiez les autres sous-traitants et les accès depuis des pays tiers. Le chapitre V s’applique aux transferts concernés, indépendamment d’une simple promesse d’hébergement européen. Notre guide de la sous-traitance IA et du RGPD aide à répartir ces responsabilités. RGPD, art. 28(2)–(4) et 44.

Checklist de mise en service

Attribuez un responsable à chaque ligne et traitez les lacunes bloquantes avant l’ouverture du service. Après une évolution de modèle, de finalité ou de source documentaire, réexaminez les éléments concernés. La démarche et les preuves permettent de satisfaire au principe de responsabilité de l’article 5(2).

Articuler le RGPD avec l’AI Act

Les rôles et obligations des deux textes se déterminent séparément. Au 26 septembre 2026, les échéances de certaines exigences de haut risque ont été reportées à décembre 2027 ou août 2028 selon le périmètre, tandis que les obligations de transparence de l’article 50 s’appliquent depuis août 2026, sous transition ciblée. Ces échéances ne suspendent pas le RGPD. Règlement 2026/1744, art. 1(39)–(40).

Utilisez notre lecture des recommandations CNIL sur l’IA pour les fiches de développement, et le guide des systèmes d’IA à haut risque pour qualifier le projet au regard de l’autre règlement. Les mêmes pièces peuvent être réutilisées quand elles répondent aux exigences pertinentes, sans confondre les obligations.

Questions fréquentes

Des données publiques peuvent-elles entraîner une IA ?

La publicité d’une donnée ne dispense pas de base légale, de finalité, de minimisation ou d’information. La réutilisation doit être examinée selon son contexte, les attentes des personnes et les autres droits applicables.

Une AIPD est-elle obligatoire pour toute IA ?

Non. Elle dépend du risque élevé, des cas légaux et des listes applicables. Documentez l’analyse ; le fait qu’un outil soit récent dans votre entreprise ne suffit pas à le qualifier d’usage technologiquement innovant.

Supprimer le corpus suffit-il à effacer les données du modèle ?

Pas nécessairement. Il faut déterminer si le modèle contient encore des données personnelles et traiter la demande correspondante. La mesure prise et ses limites doivent être expliquées, sans promettre un effacement technique qui n’a pas été réalisé.

Le fournisseur est-il toujours sous-traitant ?

Non. Sa qualification dépend de ses décisions sur les finalités et les moyens, opération par opération. Une réutilisation autonome pour son propre entraînement doit être analysée séparément du service fourni sur instruction.

Recevez nos analyses pratiques de conformité dans la newsletter.

À propos de l’auteur. Thiébaut Devergranne est docteur en droit privé, titulaire du CAPA et fondateur de Legiscope. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.