RGPD et IA : les questions que la CNIL vous posera

Beaucoup de directions traitent la conformité RGPD de leurs projets IA comme une case à cocher après coup, une fois l’outil choisi et le pilote lancé. C’est l’ordre inverse de ce qu’attend un régulateur. Le RGPD ne fait aucune exception pour l’intelligence artificielle : chaque traitement de données personnelles par un système d’IA doit répondre aux mêmes exigences de base légale, de minimisation et de finalité que n’importe quel autre traitement. Voici les questions précises que poserait un contrôle CNIL sur un projet IA — et pourquoi il vaut mieux y répondre avant qu’après.

Le RGPD ne fait pas d’exception pour l’IA

C’est le malentendu le plus répandu en comité de direction : l’idée qu’un usage innovant de l’IA bénéficierait d’une forme de tolérance réglementaire, le temps que la loi s’adapte. Il n’en est rien. Un système d’IA qui traite des données de candidats, de salariés ou de clients est un traitement de données personnelles comme un autre, soumis à l’intégralité du RGPD, indépendamment de la sophistication technologique de l’outil utilisé.

La seule spécificité de l’IA, du point de vue du régulateur, est qu’elle rend certaines questions plus difficiles à documenter — notamment la traçabilité d’une décision automatisée et la provenance exacte des données ayant servi à entraîner ou paramétrer le système. C’est précisément sur ces points que portent les contrôles.

Les questions que posera votre régulateur

Un contrôle structuré autour d’un système d’IA suit généralement une même logique, indépendamment du secteur :

1. Quelle est la base légale du traitement ? Intérêt légitime, consentement, exécution d’un contrat : la base légale doit être identifiée avant le déploiement, pas reconstituée après coup pour justifier un usage déjà en place.
2. Le principe de minimisation est-il respecté ? Le système traite-t-il uniquement les données strictement nécessaires à la finalité annoncée, ou une quantité plus large « au cas où » — une pratique fréquente avec les outils d’IA générative et particulièrement risquée.
3. Une analyse d’impact (AIPD) a-t-elle été réalisée ? Dès qu’un traitement présente un risque élevé pour les droits des personnes — ce qui est fréquent avec des systèmes de scoring ou de décision automatisée — une AIPD documentée est attendue, pas optionnelle.
4. Quelle est la chaîne de sous-traitance ? Qui héberge le modèle, où sont localisés les serveurs, les données transitent-elles par un pays hors Union européenne — chaque maillon de cette chaîne doit être identifié et contractuellement encadré.
5. Comment les droits des personnes sont-ils garantis ? Droit d’accès, de rectification, d’opposition à une décision automatisée : le système doit permettre d’y répondre concrètement, pas seulement en théorie dans une politique de confidentialité.

Où les projets IA échouent le plus souvent

Dans la pratique, les manquements les plus fréquents ne relèvent pas d’une mauvaise volonté mais d’un défaut d’anticipation :

• Le shadow AI — des équipes utilisent des outils d’IA grand public non validés par la DSI ou le DPO pour traiter des données sensibles, sans que la direction n’en ait connaissance ni contrôle.
• Les données qui alimentent l’entraînement d’un modèle tiers — selon les conditions contractuelles d’un fournisseur, des données clients ou salariés peuvent involontairement contribuer à l’amélioration d’un modèle externe.
• L’absence de durée de conservation définie — un système d’IA qui accumule des historiques de conversation ou de traitement sans politique de purge explicite viole le principe de limitation de conservation dès le premier jour.
• Le manque de documentation sur la logique de décision — quand un système contribue à une décision affectant une personne (candidature, crédit, évaluation), l’absence d’explication compréhensible de cette logique est l’un des points de contrôle les plus fréquemment sanctionnés.

Un projet IA conforme au RGPD n’est pas un projet IA plus lent. C’est un projet IA dont chaque décision de conception peut être justifiée le jour où on vous la demande.

Ce qu’un diagnostic conforme change dès la conception

La meilleure façon d’éviter ces écueils n’est pas de les corriger après déploiement, mais de les traiter dès la conception du projet. Un diagnostic qui repose sur un mode push — le client transmet un export de ses données, sans jamais donner accès à ses systèmes internes — réduit mécaniquement la surface de risque : aucune intégration à un SIRH, aucun accès permanent aux systèmes de l’entreprise, un périmètre de données strictement délimité au fichier transmis. Un déploiement on-premise, quant à lui, garantit que les données ne quittent jamais le périmètre de l’entreprise et ne servent jamais à l’entraînement d’un modèle tiers.

Ces choix architecturaux ne sont pas des arguments commerciaux accessoires. Ce sont, très concrètement, les réponses aux questions 3 et 4 posées plus haut — et elles doivent être tranchées avant le premier traitement de données, pas négociées après.

Le calendrier réglementaire à connaître

Au RGPD s’ajoute désormais l’AI Act, qui impose des obligations de documentation spécifiques aux usages à haut risque à partir d’août 2026 — décembre 2027 pour les entités bénéficiant du mécanisme Omnibus. Ces deux cadres se recoupent largement : une documentation RGPD rigoureuse constitue une base solide pour répondre aux exigences de l’AI Act, à condition d’avoir anticipé les deux ensemble plutôt que de traiter chaque échéance dans l’urgence.

S’y ajoute, pour les entreprises de plus de trois cents salariés, l’obligation de consultation du CSE dans le cadre de la GEPP triennale dès qu’une transformation touche l’organisation du travail — ce qui est presque toujours le cas d’un déploiement IA d’ampleur. Une documentation de conformité déjà constituée transforme cette consultation en discussion factuelle plutôt qu’en terrain de suspicion.

La conformité RGPD d’un projet IA ne se rattrape pas après coup avec une charte bien rédigée. Elle se construit dans l’architecture du système, avant le premier octet de donnée traité.