IA et RGPD : traiter les données personnelles dans un projet d’intelligence artificielle

Pourquoi le RGPD s’applique aussi aux projets d’intelligence artificielle

Un projet d’intelligence artificielle peut traiter des données personnelles à plusieurs moments : collecte d’un jeu de données, entraînement d’un modèle, génération de réponses, conservation des journaux techniques ou analyse des usages. Le RGPD s’applique dès lors qu’une information se rapporte à une personne identifiée ou identifiable, directement ou indirectement.

Un nom, une adresse électronique ou un numéro de téléphone sont des exemples évidents. D’autres informations sont plus indirectes : adresse IP, identifiant de compte, identifiant publicitaire, voix, image, données de localisation, historique de navigation ou combinaison de plusieurs caractéristiques. Un texte rendu anonyme de manière irréversible ne relève plus du RGPD, mais la pseudonymisation ne supprime pas le caractère personnel des données. Une table contenant des identifiants remplacés par des codes reste donc concernée si une information permet de retrouver les personnes.

Le RGPD ne prohibe pas l’intelligence artificielle. Il impose un cadre pour que le traitement soit défini, justifié, proportionné, transparent et sécurisé. Le règlement européen sur l’intelligence artificielle, dit AI Act, ajoute des obligations propres à certains systèmes d’IA, mais il ne remplace pas le RGPD. Les deux textes peuvent s’appliquer au même projet avec des objectifs différents : la protection des données personnelles d’un côté, la sécurité et la conformité des systèmes d’IA de l’autre.

Cartographier les données avant de choisir un modèle

La première étape consiste à décrire le traitement avant de sélectionner un outil ou un fournisseur. Une équipe qui commence par téléverser des fichiers dans un service d’IA risque de perdre la maîtrise du périmètre, des destinataires et de la durée de conservation. Une cartographie préalable permet de repérer les données nécessaires, les flux et les points de risque.

Pour chaque source, il faut identifier :

  • la catégorie de données collectées, par exemple textes, images, sons, coordonnées ou données de connexion ;
  • la présence éventuelle de données sensibles au sens de l’article 9 du RGPD, comme les informations de santé, les opinions politiques, les convictions religieuses ou les données biométriques utilisées pour identifier une personne ;
  • la provenance des données et les conditions dans lesquelles elles ont été obtenues ;
  • les personnes concernées, telles que clients, salariés, utilisateurs, candidats ou tiers mentionnés dans des documents ;
  • les opérations réalisées par le système, depuis l’importation jusqu’à la suppression ;
  • les destinataires internes, prestataires, sous-traitants et éventuels transferts hors de l’Espace économique européen ;
  • la durée de conservation des données brutes, des jeux préparés, des journaux et des sorties produites.

Cette cartographie doit distinguer les données d’entraînement, les données utilisées pendant l’inférence et les données conservées pour améliorer le service. Ces catégories ne répondent pas nécessairement à la même base légale ni à la même durée de conservation. Un projet peut par exemple utiliser un jeu historique pour entraîner un modèle, puis traiter de nouvelles demandes contenant des informations personnelles dans son fonctionnement quotidien.

Déterminer les rôles et les responsabilités

Le responsable du traitement détermine les finalités et les moyens essentiels du traitement. Dans un projet d’IA, cette qualification dépend de la réalité des décisions prises, et non du seul contrat ou du nom donné au projet. Une organisation qui définit l’objectif du modèle, choisit les données et fixe les conditions d’utilisation peut être responsable du traitement.

Un prestataire qui traite les données selon les instructions documentées du responsable peut agir comme sous-traitant. Le contrat doit alors encadrer les instructions, la confidentialité, la sécurité, l’assistance, la gestion des violations de données, les sous-traitants ultérieurs et la suppression ou la restitution des informations en fin de prestation. Lorsque plusieurs acteurs déterminent ensemble les finalités et les moyens, une responsabilité conjointe peut être envisagée, avec une répartition claire des obligations.

Cette analyse devient délicate avec les services d’IA accessibles en ligne. Il faut vérifier si les requêtes sont conservées, si elles servent à améliorer le modèle, si les sorties sont réutilisées, quels sous-traitants interviennent et dans quels pays les données sont traitées. Les conditions contractuelles, la documentation technique et les réglages de confidentialité doivent être examinés avant tout usage de données personnelles. Une fonctionnalité présentée comme privée ne constitue pas, à elle seule, une preuve de conformité.

Choisir une base légale adaptée au traitement

Tout traitement de données personnelles doit reposer sur une base légale prévue par l’article 6 du RGPD. Le choix doit correspondre à la finalité réelle du projet et être documenté. Les principales bases sont le consentement, l’exécution d’un contrat, l’obligation légale, la sauvegarde des intérêts vitaux, la mission d’intérêt public et l’intérêt légitime.

L’intérêt légitime nécessite une mise en balance entre l’objectif poursuivi et les droits des personnes. Cette analyse doit prendre en compte les attentes raisonnables des personnes, la nature des données, l’ampleur du traitement et les garanties prévues. Elle ne peut pas être utilisée comme une formule générale pour couvrir tout entraînement de modèle. Le consentement, de son côté, doit être libre, spécifique, éclairé et univoque. Il doit pouvoir être retiré dans des conditions comparables à celles de son recueil.

Pour les catégories particulières de données, une condition supplémentaire de l’article 9 est requise. Le fait qu’une donnée soit utile au modèle ne suffit pas à autoriser son traitement. Il faut examiner si la collecte peut être évitée, si une autre source moins intrusive existe et si les mesures de protection sont adaptées. Les données relatives aux infractions et condamnations obéissent également à un régime spécifique.

Une base légale choisie pour la collecte ne couvre pas automatiquement une nouvelle finalité. L’utilisation de messages clients pour entraîner un modèle général, par exemple, peut constituer une finalité différente de la gestion initiale des demandes. Une analyse de compatibilité et une information appropriée sont alors nécessaires, sous réserve des autres exigences du RGPD.

Appliquer la minimisation et la limitation des finalités

Le principe de minimisation impose de ne traiter que des données adéquates, pertinentes et limitées à ce qui est nécessaire. Dans un projet d’IA, cette règle concerne autant les données d’entrée que les variables conservées, les exemples annotés, les prompts, les réponses et les journaux.

Une méthode opérationnelle consiste à partir de la sortie attendue, puis à remonter vers les informations indispensables. Si un outil doit classer des demandes par catégorie, le nom complet, l’adresse personnelle ou le contenu intégral d’un échange ne sont peut-être pas nécessaires. Une suppression des identifiants, une extraction des seuls passages utiles ou une agrégation peuvent réduire l’exposition sans empêcher le fonctionnement du modèle.

Avant l’entraînement, une équipe peut mettre en place plusieurs filtres :

  • détection et retrait des coordonnées, identifiants et informations de paiement ;
  • exclusion des documents contenant des données sensibles lorsque l’objectif ne le justifie pas ;
  • réduction de la précision géographique ou temporelle ;
  • déduplication des documents afin de limiter la répétition d’informations ;
  • séparation des données servant à l’évaluation de celles utilisées pour l’apprentissage ;
  • blocage des téléversements contenant des catégories interdites par la politique interne.

La pseudonymisation peut réduire les risques, mais elle exige une séparation rigoureuse de la table de correspondance et des contrôles d’accès. L’anonymisation, plus exigeante, suppose qu’une réidentification raisonnable ne soit plus possible, y compris en croisant le jeu avec d’autres informations disponibles.

Informer les personnes et gérer leurs droits

L’information fournie aux personnes doit expliquer de manière compréhensible la finalité du traitement, les catégories de données, la base légale, les destinataires, la durée de conservation, les droits et les coordonnées du responsable du traitement. Lorsque les données ne sont pas recueillies directement auprès de la personne, les règles d’information indirecte de l’article 14 doivent être examinées, avec leurs exceptions limitées.

Un système d’IA peut rendre cette information plus difficile lorsque les données proviennent de grandes collections ou de sources multiples. Une notice générale ne doit toutefois pas masquer la finalité réelle du modèle. Elle peut préciser si les contenus servent à l’entraînement, à la personnalisation, à la détection de fraude ou à l’assistance humaine, ainsi que les conséquences prévisibles pour les personnes.

Les droits d’accès, de rectification, d’effacement, de limitation, d’opposition et de portabilité doivent être pris en compte dans l’architecture. Une organisation incapable de retrouver les données associées à une personne peut rencontrer des difficultés pour répondre à une demande valide. Les mécanismes de recherche, de correction et de suppression doivent donc être testés avec des cas concrets.

Le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou des effets significatifs similaires, prévu par l’article 22 du RGPD, mérite une attention particulière. Lorsqu’il s’applique, des garanties sont requises, notamment la possibilité d’obtenir une intervention humaine, d’exprimer son point de vue et de contester la décision. Une intervention humaine doit être réelle, compétente et capable de réexaminer le résultat, pas seulement de valider mécaniquement une recommandation.

Évaluer les risques avec une analyse d’impact

Une analyse d’impact relative à la protection des données, souvent appelée AIPD, est requise lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Les systèmes d’IA peuvent atteindre ce niveau de risque en raison du volume de données, de la surveillance, du profilage, de l’utilisation de données sensibles, de l’évaluation de personnes ou de décisions automatisées.

La Commission nationale de l’informatique et des libertés, la CNIL, publie des ressources méthodologiques et des listes de traitements susceptibles de nécessiter une AIPD. L’analyse doit décrire le traitement, vérifier sa nécessité et sa proportionnalité, puis évaluer les risques et les mesures destinées à les réduire. Elle ne doit pas être réduite à un formulaire rempli avant le lancement : elle accompagne les évolutions du modèle, des données et des usages.

Une démarche concrète peut suivre ces étapes :

  1. décrire les finalités, les flux et les acteurs ;
  2. recenser les données, les opérations et les catégories de personnes ;
  3. examiner la nécessité de chaque donnée au regard du service rendu ;
  4. identifier les risques de divulgation, discrimination, erreur, réidentification, exclusion ou détournement ;
  5. évaluer la gravité et la vraisemblance de ces risques ;
  6. définir les mesures techniques, organisationnelles et contractuelles ;
  7. faire valider le niveau de risque résiduel et planifier une réévaluation.

Si un risque élevé ne peut pas être suffisamment réduit, une consultation préalable de l’autorité de contrôle peut être nécessaire avant la mise en œuvre, conformément au RGPD.

Sécuriser les données, les modèles et les journaux

La sécurité doit couvrir toute la chaîne, et pas uniquement la base de données principale. Les jeux d’entraînement, fichiers temporaires, environnements de test, sauvegardes, clés d’API, notebooks, journaux de requêtes et sorties générées peuvent contenir des informations personnelles.

Les mesures à adapter au contexte comprennent notamment :

  • chiffrement des données pendant le transport et lorsqu’elles sont stockées ;
  • contrôle d’accès fondé sur les rôles et authentification renforcée pour les comptes sensibles ;
  • séparation des environnements de développement, de test et de production ;
  • journalisation des accès et des opérations, avec une durée de conservation maîtrisée ;
  • rotation et stockage sécurisé des secrets techniques ;
  • sauvegardes protégées, testées et soumises à des règles d’effacement ;
  • tests de fuite de données dans les réponses du modèle ;
  • procédure de détection, de confinement et de notification des violations.

Un modèle peut mémoriser des fragments présents dans ses données d’apprentissage et les restituer dans certaines conditions. Les tests doivent donc rechercher la reproduction d’informations rares, les réponses trop précises et les contournements de garde-fous. Les contrôles ne remplacent pas la minimisation : une donnée qui n’est pas collectée ne peut pas être divulguée par erreur.

Les journaux doivent être conçus avec la même prudence. Conserver intégralement chaque requête pour diagnostiquer un incident peut créer une nouvelle base de données personnelle. Des extraits masqués, des identifiants techniques et des durées courtes peuvent répondre au besoin de supervision tout en réduisant l’exposition.

Vérifier les transferts et la sous-traitance

L’utilisation d’une infrastructure située dans un autre pays ou accessible depuis un pays tiers peut entraîner un transfert de données hors de l’Espace économique européen. Il faut examiner la localisation des serveurs, les accès du support, les sous-traitants ultérieurs, les sauvegardes et les flux de télémétrie. La localisation commerciale d’un prestataire ne suffit pas à décrire la réalité technique du traitement.

Le chapitre V du RGPD encadre les transferts vers des pays tiers. Selon la situation, le cadre peut reposer sur une décision d’adéquation, des garanties appropriées telles que les clauses contractuelles types ou une dérogation strictement encadrée. L’arrêt Schrems II de la Cour de justice de l’Union européenne a également renforcé l’analyse du droit et des pratiques du pays destinataire, ainsi que la nécessité de mesures supplémentaires lorsque les garanties sont insuffisantes.

Avant de transmettre des données à un service d’IA, il est pertinent de demander :

  • où les données sont hébergées et depuis quels pays elles peuvent être consultées ;
  • si les requêtes et les sorties sont utilisées pour entraîner ou améliorer un modèle ;
  • quels sous-traitants interviennent et comment ils sont contrôlés ;
  • comment sont gérées la suppression, la restitution et les sauvegardes ;
  • quels engagements contractuels couvrent la confidentialité, la sécurité et les incidents.

En l’absence de réponses documentées, une architecture locale, une instance dédiée ou un jeu de données préalablement anonymisé peut réduire le risque, sans dispenser de l’analyse juridique et technique.

Encadrer les usages de l’IA générative au quotidien

Les outils génératifs créent un risque particulier parce que les utilisateurs peuvent y copier des informations sans mesurer les conséquences. Une politique interne doit définir les usages autorisés, les données interdites, les outils validés et les contrôles applicables. Elle doit aussi expliquer que les réponses produites peuvent être inexactes, biaisées ou révéler des informations confidentielles.

Une procédure pratique peut prévoir :

  1. identifier la nature des informations avant chaque saisie ;
  2. retirer les noms, coordonnées, numéros de dossier et détails non nécessaires ;
  3. utiliser un environnement approuvé dont les conditions de conservation sont connues ;
  4. vérifier la sortie avant toute transmission ou décision ;
  5. ne pas confondre une réponse plausible avec une information vérifiée ;
  6. signaler les incidents, fuites ou résultats discriminatoires selon un circuit défini.

Pour les salariés, la formation doit présenter des exemples de données personnelles, de secrets d’affaires et de contenus sensibles. Une interdiction générale peut être contournée si elle ne s’accompagne pas d’une solution opérationnelle. À l’inverse, une autorisation sans règles de conservation ni contrôle des accès expose les personnes et l’organisation.

Les contenus générés doivent également être réexaminés avant réutilisation. Un texte peut contenir une donnée personnelle inventée, attribuer à tort une caractéristique à une personne ou reprendre une information confidentielle fournie dans un contexte antérieur. La supervision humaine reste donc une mesure de protection autant qu’une exigence de qualité.

Construire une grille de contrôle avant la mise en production

Une revue de conformité gagne à réunir les responsables du projet, les équipes techniques, la sécurité, les métiers et, lorsqu’il existe, le délégué à la protection des données. La décision de lancement doit reposer sur des éléments vérifiables plutôt que sur une promesse de performance du modèle.

Point de contrôleQuestion à documenterPreuve attendue
FinalitéQuel résultat est recherché et quel usage est exclu ?Fiche de traitement et règles d’usage
DonnéesQuelles informations sont collectées et pourquoi sont-elles nécessaires ?Inventaire, échantillons et règles de filtrage
Base légaleQuelle base du RGPD couvre chaque finalité ?Analyse juridique et information des personnes
ActeursQui décide, qui traite et qui peut accéder aux données ?Contrats et matrice des responsabilités
RisquesLe traitement nécessite-t-il une AIPD et quelles mesures réduisent les risques ?AIPD, plan d’action et validation
ConservationQuand les données, journaux et sauvegardes sont-ils supprimés ?Politique de rétention et tests d’effacement
DroitsComment répondre à une demande d’accès, de correction ou d’opposition ?Procédure testée et responsable désigné
SécuritéComment sont limités les accès, les fuites et les usages abusifs ?Mesures techniques, journaux et tests

Après le lancement, des indicateurs peuvent suivre les demandes de droits, les incidents, les erreurs, les changements de fournisseurs et les évolutions du modèle. Toute modification importante du jeu de données, de la finalité ou du public concerné doit déclencher une nouvelle revue.

FAQ : données personnelles et intelligence artificielle

Un modèle entraîné avec des données personnelles peut-il être utilisé indéfiniment ?

Non. La durée de conservation et l’utilisation doivent rester compatibles avec la finalité, la base légale et le principe de minimisation. La conservation d’un modèle peut aussi soulever des questions si celui-ci mémorise ou permet de restituer des informations personnelles. Une réévaluation est nécessaire lorsque le modèle change de fonction ou de public.

La pseudonymisation rend-elle un jeu de données libre de toute obligation ?

Non. Tant qu’une personne peut être réidentifiée à l’aide d’informations conservées ou raisonnablement accessibles, les données restent personnelles. La pseudonymisation réduit certains risques, mais elle exige une protection séparée des éléments de correspondance et une limitation stricte des accès.

Peut-on saisir des données de clients dans un outil génératif public ?

Une telle utilisation ne doit pas être décidée sans vérifier la base légale, l’information des personnes, les conditions du service, la conservation des requêtes, les transferts et les garanties de sécurité. Lorsque ces éléments ne sont pas maîtrisés, les données doivent être exclues ou transformées de manière suffisamment protectrice.

Une validation humaine supprime-t-elle les obligations du RGPD ?

Non. La validation humaine peut réduire certains risques liés aux décisions automatisées, mais elle ne dispense ni de base légale, ni d’information, ni de minimisation, ni de sécurité. Pour être pertinente, elle doit permettre un véritable examen et une contestation du résultat.

Qui peut aider à cadrer un projet à risque élevé ?

Le responsable du traitement doit mobiliser les compétences juridiques, techniques et métier nécessaires. Le délégué à la protection des données, lorsqu’il est désigné, doit être associé en amont. Les ressources publiées par la CNIL, le Comité européen de la protection des données et les textes européens constituent des références utiles pour documenter l’analyse.