Avancées et applications en entreprise
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.
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 :
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.
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é.
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.
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 :
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.
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.
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 :
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.
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 :
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.
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 :
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.
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 :
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é.
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ôle | Question à documenter | Preuve attendue |
|---|---|---|
| Finalité | Quel résultat est recherché et quel usage est exclu ? | Fiche de traitement et règles d’usage |
| Données | Quelles informations sont collectées et pourquoi sont-elles nécessaires ? | Inventaire, échantillons et règles de filtrage |
| Base légale | Quelle base du RGPD couvre chaque finalité ? | Analyse juridique et information des personnes |
| Acteurs | Qui décide, qui traite et qui peut accéder aux données ? | Contrats et matrice des responsabilités |
| Risques | Le traitement nécessite-t-il une AIPD et quelles mesures réduisent les risques ? | AIPD, plan d’action et validation |
| Conservation | Quand les données, journaux et sauvegardes sont-ils supprimés ? | Politique de rétention et tests d’effacement |
| Droits | Comment 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.
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.
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.
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.
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.
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.