IA locale et RGPD : pourquoi l’On-Premise déplace le risque sans le supprimer
Beaucoup de DSI pensent avoir trouvé la solution définitive : déployer un LLM sur leur propre infrastructure (serveur On-Premise ou VPC) et régler ainsi la question RGPD d’un coup. Plus de transfert vers les États-Unis, plus de dépendance à OpenAI ou Anthropic, plus de risque de fuite vers l’extérieur. Le raisonnement est séduisant mais aussi partiellement faux.
En 2026, la tendance au déploiement de modèles open-source (Llama 4, Mistral) sur des infrastructures souveraines s’est accélérée, portée par des craintes légitimes sur la souveraineté des données.
L’IA locale ne supprime cependant pas le risque RGPD. Elle le déplace et dans certains cas elle l’aggrave même. L’article 32, le droit à l’oubli, l’explicabilité algorithmique : ces obligations ne disparaissent pas parce que le modèle tourne sur votre serveur.
Le transfert n’est qu’une ligne du tableur
Ne pas envoyer de données aux États-Unis est une excellente chose mais ce n’est pas suffisant.
Le RGPD ne s’arrête pas à la géographie. Une IA locale qui traite des données RH, des données clients ou des données médicales reste un traitement de données personnelles au sens du règlement, avec toutes les obligations qui en découlent.
En choisissant le déploiement local, vous ne devenez pas moins responsable. Vous devenez davantage responsable car vous passez du statut de responsable de traitement qui s’appuie sur un sous-traitant au statut de responsable de traitement qui est aussi son propre hébergeur. Vous pourriez penser que votre charge de preuve diminue, au contraire elle augmente.
Le chapitre V du RGPD, encadrant les transferts hors UE, est réglé. C’est une ligne du tableur, mais en reste plusieurs autres.
Le registre des activités de traitement d’une IA locale devrait être significativement plus dense que celui d’une solution SaaS équivalente. Si ce n’est pas le cas, c’est que le travail de documentation n’a pas commencé.
La boîte noire domestique : deux obligations que l’On-Premise ne résout pas
L’explicabilité algorithmique à votre charge
En mode SaaS, le fournisseur documente son modèle, publie ses fiches techniques, et son support peut répondre à une partie des questions sur le fonctionnement du système. En local, cette documentation n’existe pas par défaut, c’est à vous de la construire. Si un employé conteste une décision prise par votre IA locale (telle qu’un scoring RH, une recommandation commerciale, ou une évaluation automatisée) vous devez être capable d’expliquer comment le modèle a traité ses données personnelles, sans pouvoir vous retourner vers un fournisseur tiers. L’incapacité à fournir cette explication n’est pas un problème technique mais un manquement juridique.
Les droits d’accès et d’information
Les articles 13 et 15 du RGPD imposent d’informer les personnes concernées sur les traitements qui les affectent et de répondre à leurs demandes d’accès. En mode SaaS, le fournisseur fournit une partie de cette documentation et cela inclut politique de confidentialité, registre des traitements, descriptions techniques. En local, l’intégralité de cette documentation est à votre charge. Un déploiement On-Premise sans documentation des traitements associés n’est pas une architecture souveraine, c’est une architecture opaque et c’est très différent juridiquement. La souveraineté technique ne vaut rien sans la traçabilité juridique qui l’accompagne.
La sécurité : vous êtes désormais le seul rempart
En mode SaaS, la responsabilité sécurité est contractuellement partagée. Le fournisseur s’engage sur un niveau de service, documente ses mesures de protection et porte une part de la responsabilité en cas d’incident. Ce partage contractuel a une valeur juridique directe : en cas de manquement, la chaîne de responsabilité est identifiable et le contrat permet un recours.
En local, cette chaîne disparaît. L’article 32 du RGPD vous impose de mettre en œuvre des mesures techniques et organisationnelles appropriées pour garantir la sécurité des traitements, et dans ce contexte vous êtes le seul à en répondre. Ce que « appropriées » signifie n’est pas fixé de façon abstraite : c’est proportionnel au niveau de risque du traitement. Un déploiement IA local qui traite des données RH, des données clients ou des données médicales implique une évaluation du risque élevée (prévue par l’AI Act), et cela se traduit par des exigences de documentation, de tests et de supervision continues que beaucoup d’organisations sous-estiment, précisément parce qu’elles ont l’impression de maîtriser leur infrastructure.
Dans le Cloud, on peut couper les API. En local, si le service est mal segmenté, n’importe quel développeur peut « plugger » l’IA sur des bases de données confidentielles sans que le DPO ne le voie passer. C’est la « Shadow AI » domestique, et c’est le risque inverse de la Shadow IT classique. Là où un employé connectait un outil SaaS non autorisé à l’extérieur, ici c’est l’IA locale elle-même qui devient un vecteur d’accès interne non contrôlé.
À cela s’ajoute une obligation que les DSI oublient systématiquement : l’Analyse d’Impact relative à la Protection des Données, imposée par l’article 35 du RGPD. Un déploiement IA local qui traite des données à grande échelle ou des données sensibles déclenche presque systématiquement cette obligation. L’AIPD n’est pas un exercice documentaire : c’est une analyse formelle des risques du traitement, de ses mesures de mitigation, et de sa proportionnalité. Ne pas la réaliser avant le déploiement n’est pas un oubli administratif mais un manquement caractérisé.
L’entraînement et le fine-tuning : le piège du droit à l’oubli
C’est le point le plus brûlant de 2026 et le moins anticipé.
Quand une organisation fait du fine-tuning sur ses données (données clients, historiques de conversations, documents internes) pour améliorer les performances de son modèle local, ces données ne sont plus stockées dans une base de données classique mais dans les poids du modèle. Cette distinction technique a des conséquences juridiques considérables.
Le droit à l’effacement (article 17 du RGPD) impose de supprimer les données personnelles d’une personne sur demande, dans les conditions prévues par le règlement. Supprimer une ligne dans une base de données est une opération simple, traçable, vérifiable. Désapprendre une donnée à un modèle de langage est un défi technique et juridique d’une toute autre nature. Il n’existe pas aujourd’hui de méthode fiable et peu coûteuse pour extraire une information spécifique des poids d’un modèle sans procéder à un ré-entraînement complet. C’est une opération longue, coûteuse, et qui ne garantit pas l’effacement total.
Le « Machine Unlearning » est encore un domaine de recherche expérimental et l’absence de solution technique d’effacement crée une incompatibilité structurelle avec l’article 25 (Privacy by Design), sans présager de la position du régulateur.
Le cauchemar du DPO est là : comment répondre à une demande d’effacement valide si les informations de la personne font partie intégrante du modèle ? La réponse honnête est que la plupart des organisations qui font du fine-tuning sur des données personnelles ne peuvent pas y répondre correctement en l’état. Ce n’est pas une question de mauvaise volonté mais une incompatibilité structurelle entre une obligation juridique conçue pour des bases de données et une réalité technique que le législateur n’avait pas anticipée.
Ce point illustre mieux que tout autre pourquoi l’IA locale ne simplifie pas la conformité RGPD mais au contraire la complexifie sur les aspects les plus fondamentaux.
Le coût d’un ré-entraînement complet suite à une seule demande d’effacement suffit généralement à révéler que le modèle économique de conformité n’a pas été sérieusement chiffré au moment du déploiement.
Ne confondez pas étanchéité et conformité
L’IA locale est un outil puissant pour la souveraineté technologique. Elle ne dispense pas de conformité et au contraire accroît la responsabilité.
En choisissant le déploiement On-Premise, vous réglez la question du transfert de données hors UE et c’est un avantage réel. Vous prenez cependant en charge simultanément l’explicabilité algorithmique, la documentation des traitements, la sécurité sans filet contractuel, l’AIPD mais aussi la gestion du droit à l’oubli dans un modèle qui a mémorisé ce qu’il devrait pouvoir oublier.
En 2026, l’audit RGPD d’une IA locale est plus complexe que celui d’une solution SaaS, pas moins. Il exige une collaboration inédite entre le data scientist qui connaît le modèle et le DPO qui connaît les obligations. Sans cette collaboration, l’architecture souveraine reste une architecture opaque.
L’IA n’a pas besoin de voyager pour être hors-la-loi.
L’analyse, le cadrage juridique et les choix éditoriaux de cet article relèvent d’un travail humain. La rédaction a bénéficié d’une assistance par IA, intégralement relue, corrigée et validée par l’auteure.
Rédigé par Anne-Sophie, Juriste en droit des affaires et droit du numérique | 15 ans d’expérience
Diplômée en droit international des affaires et certifiée CIPP/E, Anne-Sophie a construit son expertise en entreprise, au contact des enjeux contractuels et réglementaires liés à l’innovation technologique et au numérique.
Elle accompagne depuis 3 ans les entrepreneurs et startups dans la sécurisation de leurs usages de l’IA : rédaction et négociation de contrats, mise en conformité RGPD et AI Act et gouvernance opérationnelle avec une approche concrète, adaptée aux réalités du terrain