Une IA est conforme au RGPD lorsque chaque traitement de données personnelles a une finalité, une base légale, des rôles contractuels, des données minimisées, une durée de conservation, des mesures de sécurité et une procédure d'exercice des droits. Héberger le modèle en Europe ou ajouter une validation humaine peut réduire certains risques, mais ne remplace aucun de ces éléments.
Le bon livrable n'est donc pas une promesse « conforme by design ». C'est un dossier vérifiable : cartographie des flux, registre, contrats de sous-traitance, analyse des transferts, AIPD si nécessaire, tests et journal des décisions.
L'essentiel
- • Le RGPD s'applique dès qu'un système d'IA traite une information liée à une personne identifiable — dans les données d'entrée, les journaux, la base documentaire ou la sortie.
- • L'article 22 encadre les décisions fondées exclusivement sur un traitement automatisé qui produisent un effet juridique ou significatif ; il n'interdit pas indistinctement toute aide à la décision.
- • Une AIPD est requise lorsque le traitement est susceptible d'engendrer un risque élevé. Elle se décide à partir du traitement réel, pas du simple mot « IA ».
- • Un prestataire de modèle ou d'hébergement peut être sous-traitant : l'article 28, la sécurité, les sous-traitants ultérieurs et les transferts hors EEE doivent être examinés.
- • Le RGPD s'applique déjà. Pour l'AI Act, l'article 50 s'applique le 2 août 2026 et les obligations renforcées de l'Annexe III sont attendues le 2 décembre 2027.
Dans cet article
- 1. Quand le RGPD s'applique à un système d'IA
- 2. Ce que dit réellement l'article 22
- 3. Quand réaliser une AIPD
- 4. Checklist opérationnelle en douze contrôles
- 5. Architecture : prompts, journaux, sécurité et transferts
- 6. Scénario RH : une architecture vérifiable
- 7. Articulation avec l'AI Act
- 8. Questions fréquentes
1. Quand le RGPD s'applique à un système d'IA
La première question n'est pas « quel modèle utilisons-nous ? », mais « quelles données circulent, pour quelle finalité et sous quelle responsabilité ? ». Un nom, un e-mail ou un CV sont évidemment des données personnelles. Un identifiant client, une conversation, une adresse IP ou une sortie qui permet de retrouver une personne peuvent l'être aussi.
Il faut cartographier quatre zones souvent oubliées :
- les entrées : formulaire, document, message, image ou voix ;
- le contexte : CRM, base documentaire, historique et mémoire du système ;
- les journaux : prompts, sorties, erreurs, traces techniques et sauvegardes ;
- les destinataires : modèle, hébergeur, orchestrateur, outil métier et support.
Une donnée pseudonymisée reste une donnée personnelle si la ré-identification reste possible. Une anonymisation ne sort du RGPD que si elle est effectivement irréversible compte tenu des moyens raisonnablement utilisables.
Responsable de traitement ou sous-traitant ?
L'entreprise qui décide pourquoi et comment utiliser l'IA est généralement responsable de traitement. Les prestataires qui traitent les données pour son compte peuvent être sous-traitants. Le contrat prévu par l'article 28 doit alors couvrir les instructions, la confidentialité, la sécurité, les sous-traitants ultérieurs, l'assistance sur les droits et le sort des données en fin de contrat.
La base légale dépend de la finalité
Le consentement n'est pas une réponse universelle. Selon le cas, le traitement peut reposer sur le contrat, une obligation légale, l'intérêt légitime ou le consentement. Les données sensibles relèvent en plus de l'article 9 et exigent une exception propre. Le choix se documente finalité par finalité ; il ne se déduit pas de la technologie.
2. Ce que dit réellement l'article 22
L'article 22 vise une situation précise : une décision fondée exclusivement sur un traitement automatisé qui produit un effet juridique ou affecte la personne de manière significative. Refuser automatiquement un crédit, une candidature ou une prestation peut entrer dans ce cadre.
Trois nuances évitent les raccourcis :
- Une recommandation IA examinée réellement par une personne n'est pas nécessairement une décision exclusivement automatisée. Une validation de façade ne suffit toutefois pas.
- Une décision automatisée peut être admise dans certaines situations prévues par le texte, avec des garanties adaptées.
- L'information utile porte sur la logique, l'importance et les conséquences du traitement. Il ne s'agit pas de promettre l'explication mathématique parfaite de chaque calcul interne.
Test du contrôle humain
La personne qui valide dispose-t-elle du temps, de la compétence, des informations sources et du pouvoir nécessaires pour contredire la recommandation ? Si la réponse est non, le contrôle humain risque d'être purement nominal.
3. Quand réaliser une AIPD
L'analyse d'impact relative à la protection des données est obligatoire lorsque le traitement est susceptible d'engendrer un risque élevé pour les droits et libertés. Le volume n'est pas le seul critère : évaluation systématique, données sensibles, surveillance, personnes vulnérables, combinaison de fichiers et nouveauté technologique peuvent se cumuler.
Une AIPD utile décrit le traitement, évalue sa nécessité et sa proportionnalité, identifie les risques pour les personnes puis documente les mesures prévues. Elle doit précéder le déploiement et être révisée quand la finalité, le modèle, les données ou les destinataires changent.
Le DPO, lorsqu'il existe, conseille et contrôle la démarche ; il n'est pas le « valideur juridique » obligatoire de chaque projet. La responsabilité demeure celle du responsable de traitement.
4. Checklist opérationnelle en douze contrôles
1. Finalité
Écrire ce que le système accomplit et ce qu'il ne doit jamais décider.
2. Données
Lister les champs nécessaires, les données sensibles et les sources interdites.
3. Base légale
Associer une base à chaque finalité et documenter la mise en balance si nécessaire.
4. Rôles
Identifier responsable, sous-traitants, fournisseurs de modèles et sous-traitants ultérieurs.
5. Contrats
Vérifier l'article 28, les instructions, la réversibilité et la suppression en fin de contrat.
6. Transferts
Localiser traitements et accès ; documenter le mécanisme pour tout transfert hors EEE.
7. Minimisation
Retirer les identifiants et attributs inutiles avant l'appel au modèle.
8. Conservation
Définir des durées pour les entrées, sorties, journaux, sauvegardes et jeux de test.
9. Sécurité
Limiter les accès, chiffrer, séparer les environnements et tester les fuites de données.
10. Droits
Prévoir recherche, export, rectification, effacement, opposition et contestation humaine.
11. Décisions
Documenter critères, seuils, exceptions, validation et procédure de recours.
12. Incidents
Détecter les fuites ou sorties dangereuses, couper le flux et organiser l'escalade.
5. Architecture : prompts, journaux, sécurité et transferts
L'hébergement européen n'est qu'une ligne du dossier
Une région européenne facilite la maîtrise des flux, mais n'est pas une garantie de conformité. Les équipes de support, sauvegardes, outils d'observabilité et sous-traitants peuvent introduire d'autres accès. À l'inverse, un transfert hors EEE n'est pas automatiquement interdit : il doit reposer sur un mécanisme valable et, selon le cas, sur des mesures complémentaires.
Les journaux sont une nouvelle base de données
Journaliser aide à comprendre les erreurs et à démontrer les contrôles. Conserver tous les prompts et documents sans limite produit toutefois un second fichier de données personnelles, souvent moins protégé que le CRM. Les champs journalisés, les accès et la durée doivent être configurés explicitement.
Prévenir la fuite par les entrées et les sorties
Les mesures de l'article 32 se traduisent par des contrôles concrets : permissions minimales, séparation développement/production, secrets hors prompts, filtrage des documents, tests d'injection, validation des sorties avant action et procédure de coupure. Un modèle ne doit jamais recevoir les droits globaux d'un salarié par commodité.
6. Scénario RH : une architecture vérifiable
Le scénario suivant illustre une architecture, pas un résultat client. Une PME veut préparer la lecture de candidatures sans déléguer le refus à l'IA.
- Collecte. Le candidat reçoit une information claire sur la finalité, les destinataires, les durées et ses droits.
- Séparation. Les coordonnées sont isolées des éléments nécessaires à la comparaison avec les exigences du poste.
- Extraction. Le modèle structure compétences et certifications, avec renvoi vers le passage exact du CV.
- Contrôle. Le recruteur voit la source, corrige l'extraction et examine les parcours atypiques ; aucune candidature n'est refusée automatiquement.
- Conservation. Les durées sont définies selon la finalité, et la mise en vivier fait l'objet d'une information adaptée.
- Recours. Le candidat peut demander l'accès, la rectification ou une explication humaine sur le traitement de son dossier.
Ce scénario exige aussi une analyse AI Act propre aux usages RH. Notre article sur l'automatisation du recrutement distingue les tâches administratives des systèmes de sélection.
7. Articulation avec l'AI Act
Le RGPD protège les données personnelles et les personnes concernées. L'AI Act encadre les systèmes d'IA selon leur fonction et leur niveau de risque. Les deux analyses se complètent : une IA peut relever de l'AI Act sans traiter de données personnelles, et un simple workflow sans IA peut rester soumis au RGPD.
| Question | RGPD | AI Act |
|---|---|---|
| Déclencheur | Traitement de données personnelles | Système répondant à la définition de l'IA |
| Analyse | Finalité, base légale, risques et droits | Rôle, finalité et catégorie de risque |
| Décision humaine | Article 22 si décision exclusivement automatisée et significative | Supervision requise pour les systèmes à haut risque |
| Calendrier | Déjà applicable | Article 50 : 02/08/2026 · Annexe III : 02/12/2027 |
Le plafond de 35 millions d'euros ou 7 % du chiffre d'affaires prévu par l'article 99 de l'AI Act concerne les pratiques interdites. Il ne doit pas être associé indistinctement à chaque défaut de documentation ou à l'échéance de transparence.
Pour une analyse complète du projet, consultez notre page IA conforme RGPD et AI Act.
Besoin de cartographier un système IA existant ?
Nous documentons les flux, les fournisseurs, les décisions et les contrôles techniques, en coordination avec votre DPO ou votre conseil juridique.
Échanger sur votre systèmeRecevez le livre blanc complet par email
Format PDF haute qualité (22 pages) – le lien de téléchargement arrive directement dans votre boîte mail
8. Questions fréquentes
Une IA hébergée en Europe est-elle automatiquement conforme ?
Non. La localisation aide, mais il faut encore une finalité, une base légale, des contrats, des mesures de sécurité, des durées de conservation et une procédure d'exercice des droits. Il faut aussi vérifier les accès et sous-traitants hors EEE.
Faut-il le consentement pour utiliser une IA ?
Pas systématiquement. La base légale dépend de la finalité et du contexte. Le consentement doit être libre, spécifique, éclairé et révocable lorsqu'il est retenu ; d'autres bases peuvent être plus appropriées.
Faut-il une AIPD pour chaque projet d'IA ?
Non. Elle est obligatoire lorsqu'un risque élevé est probable. Il faut documenter l'analyse, en tenant compte notamment du profilage, de l'évaluation, des données sensibles, de la surveillance et des personnes vulnérables.
Un DPO doit-il valider chaque système ?
Non. Le DPO conseille, contrôle et doit être associé en temps utile lorsqu'il existe. La responsabilité de conformité demeure celle du responsable de traitement.
Peut-on utiliser un fournisseur de modèle américain ?
Ce n'est pas interdit par principe. Il faut analyser le rôle du fournisseur, le contrat, la conservation, les accès et le mécanisme juridique de transfert. La minimisation avant l'appel reste essentielle.
Pseudonymiser suffit-il pour sortir du RGPD ?
Non. Si une ré-identification reste possible avec des informations séparées, les données sont pseudonymisées et le RGPD continue de s'appliquer. Seule une anonymisation effective peut les faire sortir de son champ.
