GDPR et AI : garder vos modèles du bon côté des règles européennes sur les données

Une hypothèse répandue veut qu'AI soit assez nouvelle pour se situer en dehors des anciennes règles sur les données. Ce n'est pas le cas. Si un modèle touche des données personnelles, que ce soit à l'entraînement, dans une invite, ou dans un résultat, GDPR s'applique exactement comme toujours. La loi européenne AI ajoute une seconde couche par-dessus, mais les premières questions qu'une entreprise européenne doit se poser sur son AI restent des questions GDPR, et certaines sont plus vives dans un contexte AI qu'elles ne l'étaient avant.

Les principes n'ont pas changé, mais AI les met sous tension

GDPR repose sur une poignée de principes, et AI exerce une pression sur les mêmes à chaque fois. La base légale : il vous faut une raison que la loi reconnaît pour traiter des données personnelles, et « nous voulions entraîner un modèle » n'en est pas automatiquement une. La limitation des finalités : des données recueillies pour faire tourner un service ne peuvent pas discrètement devenir des données d'entraînement pour autre chose sans une base nouvelle. La minimisation des données : nourrir un modèle avec tout parce que cela pourrait aider est l'inverse de ce que demande la règle. Rien de tout cela n'est nouveau. Ce qui est nouveau, c'est la facilité avec laquelle un projet AI bulldoze les trois sans s'en apercevoir.

Les décisions automatisées, là où cela devient sérieux

L'article 22 donne aux personnes le droit de ne pas être soumises à des décisions purement automatisées qui produisent des effets juridiques ou similairement significatifs, avec des exceptions étroites. Un système AI qui décide seul du crédit, de l'emploi ou de l'éligibilité tombe en plein dans cette disposition. C'est en grande partie pourquoi garder un humain dans la boucle n'est pas seulement une bonne pratique mais souvent une obligation légale, et pourquoi la question de conception « le modèle décide-t-il, ou assiste-t-il une personne qui décide » a des conséquences bien au-delà du bon goût.

Les droits qui s'accordent mal avec un modèle entraîné

GDPR donne aux personnes des droits sur leurs données, et certains s'accordent inconfortablement avec la façon dont fonctionnent les modèles. Le droit à l'effacement est simple pour une ligne de base de données et réellement difficile pour un modèle qui a déjà appris de la donnée. La transparence signifie être capable d'expliquer, en termes humains, ce qui arrive aux données de quelqu'un. Ni l'un ni l'autre n'est une raison de ne pas construire ; tous deux sont des raisons de concevoir en les ayant à l'esprit dès le départ plutôt que de les découvrir lors d'un audit. Une partie de cela consiste simplement à savoir où vont vos données lorsque vous utilisez AI en premier lieu.

GDPR et la loi AI s'empilent

Pour une entreprise européenne, les deux régimes travaillent ensemble. GDPR régit les données personnelles ; la loi européenne AI régit le risque du système lui-même, avec des obligations plus lourdes pour les usages à plus haut risque. La résidence des données traverse les deux : garder les données et le traitement à l'intérieur de l'UE est souvent la façon la plus propre de satisfaire aux questions que pose chaque régime. Un cabinet qui les traite comme une seule contrainte de conception combinée, plutôt que comme deux projets de conformité, avance plus vite et avec moins de risque.

Les questions que posera votre DPO, répondues avant qu'il ne les pose

Une façon pratique de mettre un projet AI sous pression est de répondre aux questions de protection des données avant que le projet ne commence, parce qu'elles sont prévisibles. Quelles données personnelles le système touche-t-il, à l'entraînement et à l'inférence, et pourrait-il faire son travail avec moins ? Quelle est la base légale de chacun de ces usages, écrite noir sur blanc, pas supposée ? Où vont physiquement les données, y compris via toute API de modèle tierce, et existe-t-il un accord de traitement des données qui couvre cela ? Si le système contribue à des décisions sur des personnes, où exactement la personne décide-t-elle, et pouvez-vous le montrer ? Et si quelqu'un exerce ses droits, accès, opposition, effacement, que se passe-t-il concrètement, étape par étape ?

Un exemple illustratif rend l'habitude concrète : une entreprise veut un assistant de support qui répond aux e-mails des clients. La construction tentante nourrit des boîtes de réception entières à un modèle hébergé. La construction conforme pose d'abord les questions et arrive à quelque chose de meilleur : retirer ou masquer les identifiants dont l'assistant n'a pas besoin, garder le traitement dans une région UE sous un accord en bonne et due forme, journaliser sur quelles sources chaque réponse s'est appuyée, et garder une personne sur tout ce qui change le compte d'un client. Le second système n'est pas seulement plus sûr juridiquement. Il est plus facile à expliquer, plus facile à auditer, et pas moins bon dans le travail.

À quoi ressemble une bonne pratique

Sachez quelles données personnelles alimentent vos modèles et pourquoi, tenez une base légale pour cela, gardez une personne responsable des décisions qui affectent des gens, et soyez capable d'expliquer ce que vous faites en langage clair. Faites cela et GDPR cesse d'être un obstacle pour devenir un cahier des charges. Si vous déployez AI sur des données personnelles européennes et voulez poser correctement les fondations de conformité avant qu'elles ne deviennent une observation d'audit, dites-nous ce que vous construisez, et découvrez comment nous abordons cela sous conseil AI.