RGPD et AI Act : ce que la loi impose vraiment au data scientist

La première erreur du data scientist freelance est de croire que le RGPD ne concerne que son client. C'est faux. Dès que vous manipulez des données personnelles pour le compte d'un client, vous êtes presque toujours sous-traitant au sens de l'article 28 du RGPD. Ce statut n'est pas anodin : il vous impose des obligations propres.

• agir uniquement sur instruction documentée du client (responsable de traitement) ;
• garantir la confidentialité et la sécurité des données traitées ;
• tenir un registre de vos activités de sous-traitance ;
• ne pas recourir à un autre sous-traitant (cloud, API tierce) sans autorisation.

Concrètement, si vous entraînez un modèle sur un jeu de données clients hébergé chez un fournisseur cloud non couvert par le contrat, vous engagez votre responsabilité — et celle de votre client. Le contrat de sous-traitance (DPA) n'est pas une formalité : c'est le document qui répartit les responsabilités en cas de contrôle.

Un point souvent ignoré : depuis l'évolution du RGPD, le sous-traitant n'est plus un simple exécutant à l'abri derrière son donneur d'ordre. L'article 82 prévoit qu'il peut être tenu directement responsable d'un dommage s'il n'a pas respecté ses obligations propres ou s'il a agi en dehors des instructions du responsable de traitement. Autrement dit, une personne dont les données ont fuité à cause de votre négligence peut, dans certains cas, se retourner contre vous directement. Le "je n'étais que le prestataire" ne tient plus comme ligne de défense automatique.

"J'ai retiré les noms, donc ce ne sont plus des données personnelles." Cette phrase, prononcée tous les jours dans les équipes data, est juridiquement fausse et potentiellement coûteuse.

La CNIL et le Comité européen de la protection des données sont stricts : une véritable anonymisation doit empêcher l'individualisation, la corrélation et l'inférence. Or, sur des datasets riches, la ré-identification par recoupement reste souvent possible. Beaucoup de jeux dits "anonymisés" ne sont en réalité que pseudonymisés, et restent donc pleinement soumis au RGPD.

Conséquence pratique : un dataset d'entraînement "anonymisé" à tort, qui fuite, est une violation de données personnelles à notifier sous 72 heures.

Le risque est d'autant plus élevé que les modèles eux-mêmes peuvent "mémoriser" des données d'entraînement. Des travaux récents sur l'extraction de données montrent qu'un modèle de langage ou un réseau sur-paramétré peut restituer des fragments de son jeu d'entraînement. Conclusion pour le data scientist : la donnée personnelle ne disparaît pas une fois l'entraînement terminé. Le modèle livré peut, lui aussi, constituer un traitement de données personnelles, avec les obligations qui en découlent. Penser "le dataset est rangé, donc je suis tranquille" est une erreur d'appréciation du périmètre RGPD.

Le règlement européen sur l'intelligence artificielle (AI Act) entre en application par étapes. Il introduit une logique de classification par niveau de risque qui change la donne pour les modèles que vous concevez.

• Risque inacceptable : pratiques interdites (notation sociale généralisée, manipulation).
• Haut risque : systèmes utilisés pour le recrutement, l'octroi de crédit, l'accès à des services essentiels, certains usages RH. Obligations lourdes : documentation technique, gestion des risques, supervision humaine, qualité des données.
• Risque limité : obligations de transparence (signaler qu'un contenu est généré par IA).
• Risque minimal : pas d'obligation spécifique.

Le point clé pour vous : un modèle de scoring de candidats ou d'octroi de crédit que vous développez peut être qualifié de système d'IA à haut risque. Le client (déployeur) porte une partie des obligations, mais en tant que concepteur, vous êtes attendu sur la qualité des données d'entraînement, la documentation et l'évaluation des risques. Ignorer ce cadre, c'est exposer votre client à des sanctions — et vous à une action en garantie.

Toute la pédagogie RGPD tient dans une idée simple souvent négligée par les équipes data : un traitement de données personnelles doit reposer sur une base légale définie avant de commencer. Pas après avoir constaté que le modèle est utile. L'article 6 du RGPD en liste six : consentement, contrat, obligation légale, intérêt vital, mission d'intérêt public, intérêt légitime.

Pour le data scientist, deux d'entre elles reviennent constamment :

• l'intérêt légitime, qui exige une mise en balance documentée entre l'objectif poursuivi et les droits des personnes ;
• le consentement, qui doit être libre, spécifique, éclairé et révocable — un opt-in noyé dans des CGU ne vaut pas consentement.

Le problème classique du machine learning, c'est la finalité. Des données collectées pour gérer des commandes ne peuvent pas, sans autre justification, servir à entraîner un modèle de prédiction comportementale : c'est un détournement de finalité. Le principe de minimisation impose en outre de n'utiliser que les données strictement nécessaires. Entraîner un modèle sur "tout ce qu'on a sous la main" est l'antithèse de ce principe — et un angle d'attaque idéal pour la CNIL ou pour un client mécontent qui cherche à reporter la faute sur son prestataire.

Si votre activité touche à l'IA générative ou au fine-tuning de modèles, deux risques réglementaires se cumulent.

D'abord, la licéité des données d'entraînement. Scraper des données publiques ne signifie pas qu'on a le droit de les réutiliser : données personnelles, contenus protégés par le droit d'auteur, conditions d'utilisation des sources. La base légale du traitement doit exister avant l'entraînement, pas après.

Ensuite, la propriété intellectuelle des sorties. Un modèle qui régurgite un contenu protégé expose votre client à une action en contrefaçon, et vous à une mise en cause au titre de l'atteinte involontaire à la propriété intellectuelle. C'est l'un des cas où l'assurance cyber et la RC Pro se complètent : l'une couvre l'incident de données, l'autre la faute professionnelle de conception.

La conformité réglementaire ne se sous-traite pas à un assureur — mais l'assurance amortit le choc quand un incident survient malgré vos précautions. L'option Cyber couplée à la RC Pro prend en charge :

• les frais de notification d'une violation de données aux personnes concernées et à la CNIL ;
• la défense administrative en cas de contrôle ou de mise en demeure de la CNIL ;
• les sanctions pécuniaires dans la mesure où elles sont légalement assurables, ainsi que les frais d'expertise et de remédiation ;
• la gestion de crise après un incident (forensic, communication).

Aucun contrat ne couvre une non-conformité délibérée ou la fraude. Mais pour le data scientist diligent qui subit une violation malgré un dispositif sérieux, cette couverture fait la différence entre un incident gérable et une faillite. Pour caler le bon niveau de garantie selon les données que vous traitez, consultez la page big data et data science.