Le Règlement général sur la protection des données a eu huit ans en 2026. Il a été rédigé à une époque où les modèles d'apprentissage automatique étaient comparativement restreints et où l'idée d'une IA conversationnelle traitant des millions de données personnelles en temps réel relevait de la science-fiction. Et pourtant, les principes du RGPD s'appliquent remarquablement bien aux déploiements LLM — souvent de manière à créer des problèmes de conformité significatifs pour les organisations utilisant des API d'IA cloud.

Le problème fondamental du RGPD avec les LLM cloud

L'article 5 du RGPD énonce six principes pour le traitement des données personnelles. Examinons comment les API LLM cloud s'y mesurent :

Licéité, loyauté et transparence. Vos utilisateurs savent-ils que leurs données sont envoyées à un fournisseur d'IA tiers ? Existe-t-il une base légale pour ce transfert ? De nombreuses organisations déployant des chatbots IA n'ont pas réfléchi sérieusement à savoir si elles ont divulgué cela dans leurs mentions de confidentialité.

Limitation des finalités. Les données collectées à une fin ne devraient pas être utilisées à une autre. Lorsqu'un fournisseur cloud utilise vos requêtes API pour améliorer son modèle, est-ce cohérent avec les finalités pour lesquelles vos utilisateurs vous ont confié leurs données ? Presque certainement pas.

Minimisation des données. Vous ne devez traiter que les données « adéquates, pertinentes et limitées à ce qui est nécessaire ». Envoyer des historiques de conversation complets à une API cloud alors qu'un résumé suffirait viole ce principe.

Exactitude. Moins pertinent pour les LLM, mais il convient de noter que les sorties générées par l'IA peuvent créer des enregistrements inexacts si elles sont réintroduites dans des systèmes de données.

Limitation de la conservation. Les données ne doivent pas être conservées plus longtemps que nécessaire. Les politiques de rétention des fournisseurs cloud pour les journaux d'appels API peuvent ne pas correspondre à vos obligations de rétention.

Intégrité et confidentialité. Des mesures de sécurité appropriées doivent être en place. L'envoi de données sensibles via Internet vers un fournisseur cloud étranger introduit une surface de sécurité que vous ne contrôlez pas.

Article 28 : Les accords sur le traitement des données

Si un fournisseur d'IA cloud traite des données personnelles pour votre compte, il est un sous-traitant au sens de l'article 28 du RGPD. Vous devez disposer d'un Accord de traitement des données (DPA). La plupart des grands fournisseurs cloud proposent des DPA standard, mais ce sont souvent des documents uniformes qui ne traitent pas des spécificités du traitement par LLM — en particulier concernant l'entraînement des modèles.

Lisez les petits caractères. De nombreux DPA excluent explicitement l'entraînement et l'amélioration des modèles de leurs restrictions de traitement des données. Cette exclusion signifie que le fournisseur peut s'entraîner sur les données de vos utilisateurs, et le DPA ne vous en protège pas.

Transferts transfrontaliers : Articles 44 à 49

L'envoi de données personnelles à un fournisseur aux États-Unis ou ailleurs hors de l'EEE requiert un mécanisme juridique au titre du chapitre V du RGPD. Le cadre de protection des données UE-États-Unis couvre de nombreux transferts vers les États-Unis, mais :

Il ne couvre que les fournisseurs certifiés dans le cadre
Il a été contesté juridiquement et pourrait être invalidé (comme ses prédécesseurs)
Il ne couvre pas les transferts vers des fournisseurs dans d'autres pays tiers

Pour les organisations qui ne peuvent pas tolérer le risque lié aux mécanismes de transfert, la seule solution certaine est de maintenir le traitement au sein de l'EEE.

La réponse du LLM local

Faire tourner un LLM en local — sur vos propres serveurs, dans un centre de données de l'UE — élimine la plupart de ces problèmes de façon structurelle :

Pas de sous-traitant tiers. Aucun DPA nécessaire pour la couche d'inférence (vous êtes à la fois responsable du traitement et sous-traitant).
Pas de transfert transfrontalier. Les données ne quittent jamais l'EEE.
Aucun entraînement sur vos données. Les poids du modèle sont statiques ; vos données ne sont retransmises nulle part.
Conservation sous votre contrôle. Les journaux vous appartiennent ; les politiques de rétention s'appliquent selon votre configuration.

Les obligations RGPD restantes — base légale, transparence, droits des personnes concernées — s'appliquent toujours. Mais vous n'ajoutez pas une couche entière de conformité liée au sous-traitant et aux transferts par-dessus.

Considérations pratiques

Sélection du modèle. EULLM Hub propose des modèles pré-spécialisés avec des fiches de conformité AI Act. L'utilisation d'un modèle dont la provenance des données d'entraînement est documentée constitue une bonne pratique au regard du principe de responsabilité du RGPD.

Journalisation d'audit. EULLM Engine intègre une journalisation d'audit native. La tenue des registres des activités de traitement (article 30) est simple lorsque vous contrôlez la pile d'inférence.

Demandes des personnes concernées. Lorsqu'un utilisateur demande quelles données vous détenez sur lui, ou en demande l'effacement, une infrastructure locale rend cela gérable. Vous savez exactement ce qui est stocké et où.

La conclusion : pour les organisations traitant des données personnelles avec l'IA — ce qui représente presque tous les cas d'usage IA en entreprise — une infrastructure LLM locale n'est pas seulement techniquement viable. Dans de nombreux contextes, c'est la seule option conforme au RGPD.

EULLM Engine s'exécute entièrement au sein de votre infrastructure. Voir le projet sur GitHub.