RGPD et IA : ce qu'une entreprise qui déploie un système d'IA doit vraiment vérifier

Pourquoi cette question est devenue un enjeu financier, pas seulement juridique

Pendant des années, la conformité RGPD d'un projet d'IA a été traitée comme un détail administratif — un paragraphe dans un contrat, un document que personne ne relit. Les chiffres publiés par la CNIL pour 2025 changent la donne. L'autorité française a prononcé 83 sanctions pour un montant total de 486 839 500 euros d'amendes, un record historique, en hausse très nette par rapport à l'exercice précédent (55 212 400 euros en 2024 — donnée tierce : CNIL, bilan des sanctions). La même période a vu un record de notifications de violations de données.

Ce qui compte pour vous, ce n'est pas seulement le montant moyen : c'est que des amendes de plusieurs centaines de millions d'euros ont visé des manquements sur les cookies et les traceurs — c'est-à-dire sur des sujets que l'on croyait « secondaires ». Si les cookies ont leur sort, imaginez ce que fera l'autorité sur un système d'IA qui traite des données de santé, d'emploi ou de comportement, qui sont explicitement au cœur de ses priorités de contrôle.

Ne me faites pas dire que le régulateur est un ennemi de l'IA. La CNIL est aussi — je le constate depuis des années — l'autorité qui publie le plus de ressources pratiques pour aider les acteurs à concilier innovation et droits des personnes : recommandations, fiches, listes de vérification. La question n'est pas « faut-il éviter l'IA », mais « comment la déployer sans construire un risque ». C'est exactement ma conviction : la conformité est un actif de production, pas une case à cocher.

Vérification n°2 : chaque traitement a-t-il une base légale ?

Le RGPD ne dit pas « vous ne pouvez pas traiter de données » : il dit « chaque traitement doit avoir une base légale ». Le règlement liste six bases possibles : le consentement, l'exécution d'un contrat, le respect d'une obligation légale, la sauvegarde d'intérêts vitaux, une mission d'intérêt public, et la poursuite d'un intérêt légitime. Ma recommandation opérationnelle : pour un système d'IA, l'intérêt légitime peut être une base solide, mais elle doit être documentée par un test de mise en balance (légitimité, nécessité, proportionnalité face aux droits des personnes).

Attention au réflexe « consentement partout ». Le consentement n'est une base pertinente que s'il est libre, spécifique, éclairé et univoque, et démontrable. Pour de la donnée déjà collectée que vous souhaitez réutiliser pour entraîner un modèle, le consentement initial ne couvre pas automatiquement cette nouvelle finalité — c'est un piège classique. La CNIL insiste sur la nécessité de définir une finalité précise et de vérifier la licéité du traitement, y compris en cas de réutilisation de données (donnée tierce : CNIL, recommandations sur le développement des systèmes d'IA).

Le test pratique que j'utilise : demandez-moi « pour quelle finalité utilisez-vous ces données, et sur quelle base légale ? » Si on ne peut pas répondre en une phrase, c'est qu'il faut clarifier avant de tout baisser. Ce n'est pas une bureaucratie de plus : c'est la différence entre un système que l'on peut défendre et un système que l'on doit arrêter le jour où quelqu'un (un concurrent, un client, un salon) pose la question.

Vérification n°4 : l'AIPD et la gouvernance sont-elles en place dès la conception ?

Lorsque le traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes, le RGPD impose une analyse d'impact (AIPD ou PIA). Et un système d'IA — surtout s'il traite des données sensibles, s'il profile, ou s'il prend des décisions automatisées — est exactement le cas d'école qui déclenche cette obligation. La CNIL le recommande sans ambiguïté dans sa recommandation sur l'application du RGPD au développement des systèmes d'IA : réaliser une analyse d'impact si nécessaire, et intégrer la protection des données dès les choix de conception (privacy by design) (donnée tierce : CNIL, délibération n° 2024-011 du 18 janvier 2024).

C'est le point où je vois le plus de retard. Les équipes techniques sont concentrées sur la performance du modèle ; le PIA est perçu comme un document de juriste. Or un PIA bien mené au cadrage est une feuille de route qui protège le budget : il identifie tôt les données sensibles, les flux, les transferts hors UE, et les mesures de sécurité à prévoir — au lieu de les découvrir (payantes) en cours de route.

La gouvernance, c'est aussi la traduction concrète : qui valide un nouvel usage de l'IA, qui suit les incidents, qui tient la documentation à jour ? Le déploiement doit être précédé d'une analyse des risques et d'une stratégie de gouvernance claire, en impliquant dès le début toutes les parties prenantes — DPO, RSSI, responsables métiers (donnée tierce : CNIL). Si vous n'avez pas de DPO, mettez en place un point de responsabilité clair : c'est une question de semaines, pas de mois, si c'est traité comme une décision de gestion — pas comme un projet de conformité éternel.

Vérification n°6 : et les transferts hors de l'Union européenne ?

C'est la vérification que les équipes oublient, et celle qui m'a valu les plus gros budgets d'intervention. Un système d'IA hébergé ou entraîné aux États-Unis, en Asie ou ailleurs, qui traite des données personnelles de personnes situées dans l'UE, déclenche des obligations de transfert : il ne s'agit pas seulement de stockage, mais de tout envoi, accès ou visibilité de données hors UE par un fournisseur tiers.

Le précédent est lourd : la CNIL a prononcé en juillet 2024 une amende de 290 millions d'euros concernant le transfert vers les États-Unis de données de chauffeurs inscrits sur une plateforme (donnée tierce : CNIL, rapport annuel 2024 — décision UBER). Des centaines de millions d'euros pour un transfert jugé non conforme. C'est l'illustration la plus forte que le transfert international n'est pas un détail de contrat.

Ma méthode : cartographier l'empreinte de données du système dès le design — qui héberge, qui a accès, quelles données partent, vers quel pays, sous quels outils contractuels (clauses contractuelles types, décision d'adéquation, ou analyse des garanties). Vérifier deux fois un « oui il est basé en France » quand l'infrastructure de tel ou tel outils cloud, la supervision ou le support peuvent passer par un autre continent. Le bon moment pour traiter ce sujet, c'est avant la mise en production ; une fois les données en circulation, il est plus coûteux et plus exposé de les rattraper.