AI Act et RGPD : comment les deux règlements s'articulent

L'AI Act régit des systèmes, le RGPD régit des données personnelles. Où ils se recouvrent, ce que chacun ajoute, et pourquoi une AIPD déjà faite ne libère pas des obligations de l'AI Act.

Des objets différents, des champs qui se recouvrent

La façon la plus claire de tenir les deux textes séparés est de se rappeler ce que chacun régit.

• Le RGPD régit le traitement de données à caractère personnel. Son déclencheur, ce sont les données personnelles, quelle que soit la technologie qui les touche.
• L'AI Act régit les systèmes d'IA mis sur le marché de l'Union ou mis en service. Son déclencheur, c'est le système et sa destination, que des données personnelles soient en jeu ou non.

Un système d'IA qui prédit une panne machine à partir de relevés de capteurs relève de l'AI Act et échappe au RGPD. Un tableur de fiches clients relève du RGPD et échappe à l'AI Act. Un outil de tri de CV relève pleinement des deux.

L'AI Act ne retranche rien au RGPD. Là où les deux s'appliquent, ils s'appliquent cumulativement.

Côte à côte

Là où les rôles ne se superposent pas

Responsable/sous-traitant et fournisseur/déployeur ne sont pas des concepts parallèles, et plaquer l'un sur l'autre est une source d'erreur fréquente.

Un éditeur qui conçoit et vend un outil de présélection de candidatures est le fournisseur au sens de l'AI Act. Si l'outil tourne sur les données du client, selon ses instructions, ce même éditeur est vraisemblablement sous-traitant au sens du RGPD. Le client est déployeur au sens de l'AI Act et responsable de traitement au sens du RGPD.

Les deux axes bougent indépendamment. Au titre de l'article 25, un déployeur qui modifie substantiellement un système ou le met sur le marché sous son propre nom devient fournisseur — sans que son rôle RGPD change d'un iota. Voir fournisseurs et déployeurs.

Décisions automatisées : article 22 du RGPD et article 14 de l'AI Act

Les deux sont souvent traités comme une même exigence. Ils ne le sont pas.

L'article 22 du RGPD donne à la personne concernée le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou similairement significatifs, sous réserve d'exceptions assorties de garanties, dont le droit d'obtenir une intervention humaine. C'est un droit détenu par un individu et exercé après coup.

L'article 14 de l'AI Act impose que les systèmes à haut risque soient conçus et développés de manière que la supervision humaine soit effective pendant l'utilisation. C'est une obligation de conception et d'exploitation pesant sur le fournisseur et le déployeur, due avant que quoi que ce soit ne dérape.

On peut satisfaire à l'article 22 avec un processus de relecture greffé après coup. On ne peut pas satisfaire ainsi à l'article 14 : la capacité de supervision doit être intégrée au système et confiée à quelqu'un de compétent pour l'exercer — c'est là que la littératie en IA devient porteuse.

AIPD et AIDF

L'article 27 impose à certains déployeurs de systèmes à haut risque de l'annexe III — organismes de droit public, entités privées fournissant des services publics, et déployeurs de systèmes d'évaluation de solvabilité et de tarification en assurance vie et santé — de réaliser une analyse d'impact sur les droits fondamentaux avant la première utilisation.

Les périmètres diffèrent :

• Une AIPD examine les risques pour les droits et libertés des personnes physiques résultant du traitement de données.
• Une AIDF examine le contexte de déploiement : les catégories de personnes affectées, les risques spécifiques de préjudice pour elles, les mesures de supervision humaine et les dispositifs de gouvernance si les risques se matérialisent.

L'article 27 précise expressément que l'AIDF complète l'AIPD et que l'analyse peut s'appuyer sur elle lorsqu'une AIPD a déjà été réalisée. En pratique, la voie efficace est un exercice unique et combiné produisant deux livrables clairement identifiés — pas une AIPD rebaptisée.

La gouvernance des données tire dans les deux sens

L'article 10 exige que les données d'entraînement, de validation et de test des systèmes à haut risque soient pertinentes, suffisamment représentatives et, dans la mesure du possible, exemptes d'erreurs. Atteindre cette représentativité peut imposer de traiter davantage de données, et parfois des données sensibles, pour détecter et corriger les biais.

Le règlement anticipe la tension : l'article 10(5) autorise le traitement de catégories particulières de données à caractère personnel strictement aux fins de la détection et de la correction des biais dans les systèmes à haut risque, sous réserve de garanties — limites techniques à la réutilisation, pseudonymisation lorsque c'est possible, et suppression une fois le biais corrigé. C'est une porte étroite et finalisée, pas une licence générale.

Séquencement pratique

1. Inventorier une fois, classer deux fois. Un seul registre de systèmes, évalué au regard du RGPD (des données personnelles sont-elles traitées ?) et de l'article 6 (est-ce du haut risque ?).
2. Cartographier les deux couples de rôles par système. Responsable/sous-traitant et fournisseur/déployeur. Les consigner séparément.
3. Combiner les analyses, garder les livrables distincts. Un atelier, un dossier de preuves, deux conclusions documentées.
4. Réutiliser la machinerie RGPD déjà en place. Registre des traitements, durées de conservation, diligence fournisseurs et réponse à incident s'étendent aux obligations de l'AI Act moyennant une adaptation modeste.
5. Ne pas confondre maturité RGPD et préparation à l'AI Act. La documentation technique de l'annexe IV, la journalisation de l'article 12, l'exactitude et la robustesse de l'article 15 et l'évaluation de la conformité n'ont aucun équivalent au RGPD.

Pour la vue d'ensemble de la convergence réglementaire européenne, voir AI Act, DORA et NIS2.

Contenu éditorial, ne constitue pas un conseil juridique.