AI Act et RGPD : ce que votre conformité vous fait déjà gagner
Vous avez investi dans le RGPD ? Une partie est réutilisable pour l'AI Act. Ce que votre conformité couvre, ce qu'elle ne couvre pas, et comment articuler les deux.
Quand un créateur de start-up me dit « on est à jour sur le RGPD, est-ce qu'on est tranquilles pour l'AI Act ? », ma réponse tient en deux temps. Oui, une partie réelle de votre travail sur le RGPD se réutilise et vous fait gagner du temps. Et non, le RGPD ne couvre pas tout — l'AI Act ajoute une logique que le règlement (UE) 2016/679 n'a jamais eu vocation à porter.
Comprendre où les deux textes se recoupent, et où ils divergent, évite deux erreurs symétriques : repartir de zéro alors qu'on a déjà l'essentiel, ou croire qu'une conformité RGPD vaut conformité IA. Voici la carte.
Le RGPD protège un droit fondamental : la protection des données personnelles. Sa boussole, ce sont les personnes concernées, leurs droits, la licéité des traitements.
L'AI Act, lui, est avant tout une réglementation de sécurité des produits. Sa logique est proche de celle du marquage CE : un système d'IA jugé à haut risque doit être documenté, testé, surveillé et, le cas échéant, évalué avant d'être mis sur le marché. Le centre de gravité n'est pas la personne dont on traite les données, c'est le système lui-même et sa sûreté.
Cette différence de nature explique tout le reste. Les deux textes se croisent dès qu'un système d'IA traite des données personnelles, mais ils ne posent pas les mêmes questions. Gardez cette grille en tête : elle vous dira, à chaque obligation, si vous l'avez déjà traitée côté RGPD ou si c'est un chantier neuf.
Si vous avez fait sérieusement votre RGPD, vous avez construit des briques directement transposables.
Votre cartographie des traitements. Le registre de l'article 30 du RGPD recense déjà vos flux de données. C'est la base idéale pour dresser l'inventaire des systèmes d'IA que l'AI Act suppose : on part de ce qui existe, on ajoute une colonne « usage d'IA » et la qualification du rôle et du risque.
Votre méthode d'analyse d'impact. L'analyse d'impact relative à la protection des données (AIPD, article 35 du RGPD) vous a appris à évaluer un traitement risqué avant de le lancer. L'AI Act prévoit, pour certains déployeurs de systèmes à haut risque, une analyse d'impact sur les droits fondamentaux (article 27). Les deux exercices ne se confondent pas, mais la culture méthodologique est la même, et les deux analyses peuvent largement être menées ensemble.
Votre gestion des sous-traitants. Les contrats de sous-traitance imposés par l'article 28 du RGPD — les fameux DPA — vous ont habitué à encadrer la chaîne de prestataires. L'AI Act demande la même rigueur sur la chaîne de valeur IA : identification des fournisseurs de modèles, des sous-traitants techniques, mécanismes de notification. Vos réflexes contractuels valent ici aussi. J'en détaille la mécanique dans l'article sur la sous-traitance dans un contrat SaaS.
Votre gouvernance. DPO ou référent données, procédures internes, registre des incidents : cette gouvernance est le socle naturel sur lequel poser la gouvernance IA, plutôt que d'en créer une parallèle.
En pratique. Les startups qui avaient déjà investi sur le RGPD démarrent l'AI Act avec une longueur d'avance. Si ce socle vous manque encore, l'impact opérationnel du RGPD sur les startups reste un bon point d'entrée — il sert les deux conformités à la fois.
C'est l'intersection la plus sensible entre les deux textes, et celle qui revient dans toutes mes négociations IA.
Entraîner ou affiner un modèle sur des données personnelles est un traitement au sens du RGPD. Il faut donc une base légale. Dans son avis 28/2024 du 17 décembre 2024, le Comité européen de la protection des données (CEPD) a confirmé que l'intérêt légitime (article 6(1)(f) du RGPD) peut, sous conditions, servir de base à l'entraînement comme au déploiement d'un modèle — au terme d'un test en trois étapes : finalité légitime, nécessité, et mise en balance avec les droits des personnes.
Le même avis bat en brèche une idée répandue : un modèle entraîné ne devient pas automatiquement anonyme. Des données personnelles peuvent rester « absorbées » dans ses paramètres et, dans certains cas, être réextraites. L'anonymité doit se démontrer au cas par cas, pas se présumer.
Point d'attention. Le CEPD a aussi indiqué qu'un entraînement réalisé en violation du RGPD peut « contaminer » la phase de déploiement du modèle. Autrement dit, un raccourci pris en amont sur les données peut fragiliser tout l'usage en aval. C'est un risque qui se traite contractuellement, en encadrant strictement l'origine des données et l'usage d'entraînement — un sujet que je développe côté contrats dans l'article sur l'AI Act et les contrats SaaS.
C'est là que votre conformité RGPD montre ses limites. Plusieurs obligations de l'AI Act n'ont pas d'équivalent dans le RGPD, surtout pour les systèmes à haut risque : système de gestion des risques (article 9), documentation technique du système (article 11 et annexe IV), supervision humaine pensée dès la conception (article 14), exigences d'exactitude, de robustesse et de cybersécurité (article 15), et, le cas échéant, évaluation de conformité avant mise sur le marché.
Si votre produit relève du haut risque, ces obligations représentent un chantier distinct, de nature « produit », que votre DPO ne traitera pas seul. Si votre produit relève du risque limité ou minimal — le cas le plus fréquent en SaaS B2B — l'ajout par rapport au RGPD se concentre sur deux points : la transparence de l'article 50 (signaler à l'utilisateur qu'il interagit avec une IA, permettre d'identifier les contenus générés) et la maîtrise de l'IA de l'article 4 (la formation interne). Ni l'une ni l'autre n'est couverte par le RGPD.
Une nuance utile sur un point que les deux textes abordent : la décision automatisée. L'article 22 du RGPD encadre déjà les décisions produisant des effets juridiques prises sans intervention humaine. L'AI Act ajoute, pour le haut risque, une exigence de supervision humaine. Les deux se complètent, mais ne disent pas la même chose : l'un protège la personne visée par la décision, l'autre impose une architecture de contrôle dans le système.
L'articulation entre les deux textes continue d'évoluer, et un point mérite votre attention.
Le Digital Omnibus, en cours d'adoption au moment où j'écris (accord politique du 7 mai 2026), prévoit notamment de clarifier le traitement de données sensibles aux fins de détection et de correction des biais dans les systèmes d'IA — un sujet à la frontière exacte de l'article 9 du RGPD, qui interdit en principe ce type de traitement. Dans leur avis conjoint de février 2026, le CEPD et le contrôleur européen de la protection des données ont accueilli favorablement l'objectif, tout en demandant des garanties précises sur le périmètre de la dérogation.
Concrètement : si vous travaillez sur l'équité de vos modèles, l'usage de données sensibles à cette fin est en train de se clarifier — mais le cadre n'est pas figé. À suivre, et à ne pas anticiper de façon trop large tant que le texte n'est pas définitif. (Analyse arrêtée au 2 juin 2026.)
L'erreur serait de traiter AI Act et RGPD comme deux silos. Voici la façon dont je les articule avec mes clients :
Le bon état d'esprit n'est pas « encore une réglementation de plus ». C'est de voir l'AI Act comme une extension de la discipline que vous avez déjà acquise avec le RGPD — même culture de la traçabilité, même réflexe de documenter, appliqués à un objet nouveau. Les entreprises qui réussiront cette transition sont celles qui capitalisent sur l'existant au lieu de tout réinventer. Si vous voulez auditer ce que votre conformité actuelle couvre déjà et identifier les vrais manques, prenons rendez-vous.
Le Digital Omnibus a décalé le calendrier de l'AI Act. Ce qui s'applique vraiment en 2026, ce qui est reporté, et comment savoir si votre SaaS est concerné.
SaaS, IT, hébergement, intégration : panorama des modes de résiliation d'un contrat informatique en droit français, et des réflexes à avoir.
Avançons ensemble pour accélérer votre activité
J'accompagne les éditeurs de logiciels et de SaaS depuis plus de 10 ans, pour structurer leur activité, protéger leur propriété intellectuelle et améliorer leurs contrats.
