L’AI Act reprend une grande partie de la grammaire du RGPD : approche par les risques, accountability, documentation, transparence. Pour un DPO ou un RSSI qui pilote déjà un programme de conformité, cela change la manière d’aborder le chantier. Le vrai risque opérationnel, c’est la duplication : deux registres, deux campagnes d’analyse d’impact, deux séries de questionnaires envoyés aux mêmes métiers, à quelques semaines d’intervalle. Une stratégie de conformité RGPD et AI Act tenable identifie très tôt les zones de recouvrement et les traite une seule fois.
Le calendrier a bougé cet été. Les pratiques interdites s’appliquent depuis février 2025, les modèles à usage général depuis août 2025. Le paquet Digital Omnibus, adopté fin juin 2026, a en revanche repoussé les obligations les plus lourdes : 2 décembre 2027 pour les systèmes à haut risque de l’annexe III, 2 août 2028 pour l’IA embarquée dans les produits déjà réglementés de l’annexe I. Le régime de sanctions et les obligations de transparence, eux, sont bien entrés en application le 2 août 2026. Le report allonge le délai sans réduire la charge : la documentation attendue en 2027 se construit sur les registres et les analyses d’impact que vous tenez déjà. Les arbitrages d’organisation se prennent maintenant.
Les fondations communes : une philosophie de régulation partagée
Le législateur européen a gardé une structure familière pour l’AI Act. Elle s’insère sans douleur dans un cadre de gouvernance existant.
L’approche par les risques comme dénominateur commun
Le RGPD module ses exigences selon la sensibilité des traitements. L’AI Act classe les systèmes en quatre niveaux : inacceptable, haut, limité, minimal. Dans les deux cas, plus l’atteinte potentielle aux droits et libertés est forte, plus les obligations de sécurité et de transparence se resserrent. Vos matrices de risques et vos échelles de cotation existantes se réutilisent pour qualifier vos projets d’IA, à condition d’y ajouter les critères propres à l’annexe III.
Le principe d’accountability et la responsabilité de l’organisation
Les deux règlements demandent de documenter la conformité et de pouvoir la démontrer à tout moment. Politiques internes, formations, contrôles périodiques, preuves conservées : le mécanisme est identique. Une organisation dotée d’un programme RGPD mature possède déjà l’ossature nécessaire pour porter l’AI Act. Ce sont les objets contrôlés qui changent, pas la logique de pilotage.
L’exigence de documentation technique et de traçabilité
L’article 11 de l’AI Act impose aux fournisseurs de systèmes à haut risque une documentation technique détaillée, complétée par la journalisation prévue à l’article 12. On retrouve la logique du privacy by design et de la traçabilité des accès. Centralisez ces documents au même endroit que vos preuves RGPD : une seule source de vérité, une seule campagne de collecte au moment de l’audit.
Là où les deux textes divergent
Les similitudes s’arrêtent aux cibles visées et au vocabulaire juridique. Confondre les deux mène à des angles morts.
L’objet protégé : données personnelles d’un côté, droits fondamentaux et sécurité de l’autre
Le RGPD couvre les données à caractère personnel et la vie privée des personnes physiques. L’AI Act vise un spectre plus large : la santé, la sécurité, les droits fondamentaux, la non-discrimination. Un système entraîné sur des données anonymisées peut être irréprochable au regard du RGPD et rester interdit au titre de l’article 5 de l’AI Act, par exemple s’il relève de la notation sociale ou de la catégorisation biométrique prohibée.
La qualification des acteurs : responsable de traitement, fournisseur, déployeur
Le RGPD raisonne en responsable de traitement et sous-traitant. L’AI Act introduit le fournisseur, celui qui développe ou fait développer le système et le met sur le marché sous son nom, et le déployeur, celui qui l’utilise sous son autorité. Les deux grilles ne se superposent pas : une entreprise est souvent déployeur d’une IA tierce et responsable de traitement pour les données que ce système manipule. Attention au basculement de statut : un déployeur qui modifie substantiellement un système à haut risque ou l’exploite sous sa propre marque devient fournisseur, avec les obligations qui vont avec. Clarifiez ces rôles dans les contrats, avant la mise en production.
Le périmètre d’application géographique et matériel
L’AI Act s’applique dès lors que les résultats produits par le système sont utilisés dans l’Union, quel que soit le lieu d’établissement du fournisseur. La portée extraterritoriale est calquée sur celle du RGPD. Les plafonds de sanction montent plus haut : jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires mondial pour les pratiques interdites.
Synergies opérationnelles : quand l’un s’appuie sur l’autre
L’articulation des deux textes ouvre de vraies simplifications pour vos équipes, à condition de la construire dès le départ.
De l’AIPD à l’évaluation d’impact sur les droits fondamentaux
L’AIPD est un exercice rodé chez la plupart des DPO. L’article 27 de l’AI Act ajoute l’évaluation d’impact sur les droits fondamentaux pour certains déployeurs de systèmes à haut risque, notamment les organismes publics et certains acteurs privés fournissant des services essentiels. Le texte prévoit lui-même que les éléments déjà couverts par une AIPD ne soient pas dupliqués. Intégrez donc les questions IA dans votre canevas d’AIPD : biais, supervision humaine, explicabilité, mesures de recours. Les métiers sont sollicités une fois, pour un même projet.
La gouvernance des données au service de l’IA
L’article 10 impose des critères de qualité sur les jeux de données d’entraînement, de validation et de test : pertinence, représentativité, examen des biais possibles. C’est le prolongement direct des principes de minimisation et d’exactitude du RGPD. Une organisation qui maîtrise déjà la provenance, la durée de conservation et la qualité de ses données a franchi la moitié du chemin.
Droit à l’information et transparence algorithmique
Les articles 13, 14 et 22 du RGPD encadrent déjà l’information sur les décisions automatisées. L’AI Act ajoute l’obligation d’informer les personnes lorsqu’elles interagissent avec un système d’IA et de marquer les contenus générés. Vos mentions d’information, vos politiques de confidentialité et vos parcours utilisateurs doivent couvrir les deux volets, en langage clair.
Vers un référentiel de conformité unique et centralisé
Piloter les deux réglementations sur des classeurs Excel parallèles produit toujours le même résultat : des versions divergentes, des ressaisies et des données obsolètes le jour de l’audit. Pour tenir votre conformité RGPD et l’AI Act ensemble, unifiez les référentiels.
Mutualiser les inventaires pour une vision consolidée
Le registre des systèmes d’IA et le registre des activités de traitement partagent une large part de leurs champs : finalité, catégories de données, destinataires, responsable interne, sous-traitants. Créez un objet unique « application » ou « système » dans votre plateforme de GRC, puis rattachez-lui les attributs RGPD d’un côté, les attributs AI Act de l’autre. Une seule fiche, deux lectures réglementaires.
Fusionner les contrôles de sécurité et de conformité
Les exigences de cybersécurité, de robustesse et d’exactitude de l’article 15 recoupent l’obligation de sécurité de l’article 32 du RGPD, et croisent largement l’ISO 27001 comme l’ISO 42001. Un plan d’action consolidé permet de prioriser les remédiations qui servent plusieurs référentiels d’un coup. Le durcissement de la journalisation, par exemple, alimente à la fois la traçabilité des accès aux données et celle des décisions du modèle.
Automatiser le pilotage pour éviter les doubles saisies
Connectez votre catalogue de services, votre CMDB ou vos outils de développement à votre plateforme de conformité. L’apparition d’un nouveau projet d’IA déclenche alors le questionnaire de qualification, sans intervention manuelle. Fini les relances par mail et les tableaux de suivi remplis à moitié : l’information remonte structurée, datée, rattachée à un responsable.
Gouvernance : qui porte la conformité de l’intelligence artificielle ?
La répartition des rôles arrive presque toujours en première question, avant même le sujet du registre. Elle mérite d’être tranchée par écrit.
Le binôme DPO et RSSI au cœur du dispositif
Le DPO apporte la lecture juridique et éthique : finalités, bases légales, droits des personnes, proportionnalité. Le RSSI évalue la robustesse technique et les attaques propres aux modèles, du data poisoning à l’inversion de modèle en passant par l’injection de prompt. Ni l’un ni l’autre ne couvre le sujet seul. Formalisez le circuit de décision entre eux, sinon les arbitrages se prennent en réunion projet, sans trace.
L’émergence du responsable de la conformité IA
Dans les grandes organisations, un AI Compliance Officer apparaît, souvent rattaché à la direction juridique ou à la DSI. Il fait le lien entre les exigences techniques de l’AI Act et les besoins métiers. Son action doit rester coordonnée avec celle du DPO, faute de quoi deux interprétations concurrentes circulent sur l’usage des données personnelles par les modèles.
Impliquer les métiers et la direction juridique
Marketing, RH et Finance déploient des outils d’IA sans toujours passer par la DSI. Formez ces équipes pour qu’elles identifient elles-mêmes si une solution relève de l’AI Act, plutôt que de découvrir l’usage six mois plus tard. La direction juridique, elle, révise les clauses fournisseurs : engagements de conformité, accès à la documentation technique, obligations d’information en cas d’incident grave.
Registre des systèmes d’IA et registre des traitements : fusion ou distinction ?
La question du registre revient systématiquement. Nouveau document ou extension de l’existant ?
| Caractéristique | Registre des traitements (RGPD) | Inventaire des systèmes d’IA (AI Act) | Mutualisation possible ? |
|---|---|---|---|
| Unité de base | Activité de traitement | Système d’intelligence artificielle | Oui, l’IA est le support du traitement |
| Caractère obligatoire | Article 30, sauf exceptions | Documentation et enregistrement pour le haut risque | Oui |
| Finalité du texte | Protection des personnes | Sécurité, santé, droits fondamentaux | Oui |
| Documentation associée | Flux, durées, destinataires | Architecture, jeux de données, logs, performance | Partielle |
Les points de recoupement des deux inventaires
Un registre des activités de traitement bien tenu contient déjà une bonne partie de ce que réclame l’AI Act. Ajoutez les champs manquants : classe de risque, rôle endossé (fournisseur ou déployeur), version du modèle, mécanismes de supervision humaine, statut du marquage CE. Le registre devient un outil de pilotage multi-référentiel.
Gérer les spécificités des systèmes à haut risque
Certains champs ne concernent que l’IA : description de la logique algorithmique, mesures anti-biais, métriques de performance, procédure d’arrêt d’urgence. Gérez-les par formulaires conditionnels. Si l’application est cochée « IA à haut risque », les champs complémentaires deviennent obligatoires. Les autres fiches restent légères.
La structure d’un registre hybride
Trois couches suffisent :
- Identité : nom de l’outil, propriétaire métier, éditeur, version, description fonctionnelle.
- RGPD : base légale, catégories de données et de personnes, durées de conservation, transferts, sous-traitants.
- AI Act : classe de risque, rôle, fournisseur, documentation technique, supervision humaine, journalisation.
Méthodologie de transition : partir du RGPD pour intégrer l’AI Act
Pas besoin de repartir d’une page blanche. Vos acquis RGPD constituent le point de départ le plus rapide.
Étape 1 : cartographier les systèmes d’IA dans les traitements existants
Reprenez votre registre actuel et repérez les traitements qui reposent sur de l’apprentissage automatique, du scoring ou des systèmes experts. Profitez-en pour traquer le shadow AI : les extensions de navigateur, les assistants intégrés aux suites SaaS et les abonnements souscrits en direct par un service. C’est souvent là que se trouvent les usages les plus exposés.
Étape 2 : mettre à jour les politiques de gouvernance des données
Vos politiques internes doivent intégrer les exigences de l’article 10 sur la qualité des jeux de données. Définissez qui valide un corpus d’entraînement, selon quels critères, et comment les résultats de test sont conservés. Sans procédure écrite, la preuve d’absence de biais discriminatoire se reconstruit dans l’urgence, au mauvais moment.
Étape 3 : adapter les achats et la revue des tiers
Enrichissez votre questionnaire fournisseurs. La question « êtes-vous conforme au RGPD ? » ne suffit plus : demandez la déclaration de conformité UE, le marquage CE quand il s’applique, les instructions d’utilisation prévues à l’article 13 et l’accès à la documentation technique. Intégrez ces éléments à votre démarche TPRM plutôt que d’ouvrir un canal d’évaluation parallèle.
Ce qu’il faut retenir
- Un seul processus : mutualisez registres et analyses d’impact plutôt que de faire tourner deux chaînes de conformité en parallèle.
- Le risque comme boussole : votre méthode d’analyse de risque RGPD sert de base pour classer les systèmes d’IA selon les catégories de l’AI Act.
- Les données comme socle : une gouvernance saine des données conditionne la conformité aux deux textes.
- Des rôles écrits : DPO, RSSI, juridique et métiers doivent savoir qui tranche quoi, et à quel moment du projet.
- Un outil centralisé : maintenir une conformité continue sur plusieurs référentiels demande une source unique de vérité, pas une collection de classeurs.
- L’anticipation : qualifier un système d’IA avant sa mise en production coûte nettement moins cher qu’une refonte après coup.
Questions fréquentes
Le DPO peut-il être aussi responsable de la conformité IA ? Oui, et c’est courant dans les ETI. Cela suppose une montée en compétences sur les aspects techniques des modèles et un accès aux équipes data. Vérifiez surtout la charge : cumuler les deux périmètres sans ressources supplémentaires dégrade les missions RGPD de base, à commencer par le traitement des demandes d’exercice de droits.
Faut-il refaire toutes mes AIPD si j’utilise une IA ? Les mettre à jour, plutôt que les refaire. Un traitement existant qui intègre une brique d’IA change de profil de risque : opacité de la décision, biais, nouveaux vecteurs d’attaque, dépendance à un fournisseur. Un volet IA ajouté à votre modèle d’AIPD couvre l’essentiel dans la plupart des cas.
Quelles sont les sanctions en cas de non-conformité à l’AI Act ? Elles sont graduées. Jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires mondial pour les pratiques interdites de l’article 5. Jusqu’à 15 millions d’euros ou 3 % pour le manquement aux autres obligations. Jusqu’à 7,5 millions d’euros ou 1 % pour la fourniture d’informations inexactes aux autorités.
Un système d’IA qui ne traite aucune donnée personnelle relève-t-il du RGPD ? Non. Le RGPD s’applique au traitement de données à caractère personnel. L’AI Act, lui, s’applique indépendamment, dès lors que le système entre dans une catégorie de risque définie, par exemple un composant de sécurité d’une infrastructure critique. La qualification se fait texte par texte.
Comment prouver la supervision humaine exigée par l’AI Act ? Par des procédures documentées : qui surveille le système, à quelle fréquence, comment les alertes remontent, dans quelles conditions un opérateur peut ignorer une recommandation ou arrêter le système. Ajoutez les traces d’exercice réel, les habilitations associées et les comptes rendus de test. Une procédure jamais éprouvée ne tient pas devant un contrôle.
Pour aller plus loin
Commencez par un inventaire rapide de vos usages d’IA, y compris ceux qui n’ont jamais transité par la DSI. Prenez ensuite vos trois systèmes les plus exposés et passez-les dans une analyse d’impact combinée RGPD et AI Act : c’est le meilleur test de votre gouvernance, et cela ne bloque aucun projet. En parallèle, mettez à jour votre charte informatique pour encadrer l’usage des IA génératives par vos collaborateurs et limiter les fuites de données vers des services non maîtrisés.
Make IT Safe centralise vos actifs, vos registres, vos analyses de risque et vos plans d’action dans une seule plateforme collaborative, hébergée en France. Le registre des traitements d’un côté, celui des systèmes d’IA de l’autre, et des preuves partagées entre les deux : c’est le socle commun décrit dans cet article. Nous pouvons vous le montrer en fonctionnement : demandez une démonstration.
