#Pourquoi un LLM local est RGPD-natif

Le RGPD ne dit pas "vous n'avez pas le droit d'utiliser l'IA". Il dit que tout traitement de données personnelles doit reposer sur une base légale, être documenté, minimisé, sécurisé, et que les transferts hors UE doivent être encadrés. Le problème avec un LLM cloud, ce n'est pas l'IA — c'est le traitement par un sous-traitant tiers, souvent américain, avec une chaîne contractuelle complexe et des risques de transfert au sens du chapitre V du RGPD.

Un LLM exécuté en local renverse l'équation. Les poids du modèle sont téléchargés une fois depuis Hugging Face ou Ollama, puis l'inférence se fait à 100 % sur votre matériel. Aucun prompt n'est envoyé sur internet. Aucune réponse n'est journalisée chez un tiers. Le "traitement" reste interne, sous votre maîtrise effective.

Pas de transfert hors UE: Article 44 et chapitre V du RGPD : aucune donnée ne quitte vos serveurs, donc pas de Standard Contractual Clauses, pas de Transfer Impact Assessment, pas de question sur le Cloud Act américain.
Pas de sous-traitant au sens art. 28: Pas d'accord de sous-traitance à négocier, pas d'annexe 7 à mettre à jour à chaque évolution produit du fournisseur, pas de fournisseur qui change unilatéralement ses CGU.
Minimisation native: Article 5.1.c : vous ne pouvez pas envoyer trop de données par accident à un tiers, puisqu'il n'y a pas de tiers. La minimisation devient une propriété de l'architecture, pas une politique à faire respecter.
Effacement réel: Article 17 (droit à l'effacement) : effacer une trace dans votre propre base est trivial. Demander à OpenAI d'effacer un prompt envoyé il y a 6 mois est une procédure contractuelle, pas une garantie technique.

Recommandation CNIL

Depuis 2024, la CNIL publie régulièrement des fiches sur l'IA et le RGPD. Sa position constante : privilégier les solutions on-premise ou souveraines pour les traitements impliquant des données sensibles, des données de santé, des données RH ou tout secret professionnel.

#Le cadre légal en mai 2026 : RGPD + AI Act

Deux textes se superposent désormais en Europe pour encadrer l'usage des LLM en entreprise. Le RGPD couvre les données personnelles, l'AI Act couvre les systèmes d'IA en tant que tels — peu importe qu'ils traitent ou non des données personnelles.

#RGPD : ce qui s'applique aux LLM

Base légale (art. 6): Intérêt légitime, exécution d'un contrat, consentement : tout traitement par LLM doit s'y rattacher. Un LLM local n'efface pas cette obligation mais simplifie la documentation.
Information des personnes (art. 13-14): Vos politiques de confidentialité doivent mentionner l'usage d'un LLM, même local. Pas besoin de nommer le modèle, mais la finalité oui.
AIPD (art. 35): Une Analyse d'Impact est requise pour les traitements à risque élevé. Avec un LLM cloud, l'AIPD doit couvrir le sous-traitant ; en local, elle se réduit à votre propre infrastructure.
Sécurité (art. 32): Chiffrement des disques contenant les modèles et logs, contrôle d'accès aux serveurs d'inférence, journalisation. Standard pour de l'infra interne.

#AI Act : l'échéance d'août 2026

L'AI Act (Règlement UE 2024/1689) est entré en vigueur le 1ᵉʳ août 2024. Ses dispositions s'appliquent par paliers. Le palier le plus structurant pour les LLM généralistes — les obligations pour les modèles à usage général (GPAI) — est entré en application le 2 août 2025. Les obligations pour les systèmes d'IA à haut risque s'appliquent le 2 août 2026, soit dans environ trois mois au moment où vous lisez ce guide.

GPAI (modèles fondationnaux): Les obligations pèsent sur les fournisseurs (OpenAI, Anthropic, Mistral, Meta...). Si vous utilisez Llama, Mistral ou Qwen en local, l'éditeur a déjà la responsabilité de fournir une documentation technique conforme.
Systèmes à haut risque: Annexe III : RH, scoring crédit, éducation, services publics essentiels, infrastructures critiques. Si votre LLM est intégré dans un de ces flux, vous êtes "déployeur" au sens de l'AI Act et avez des obligations propres.
Transparence: Tout contenu généré par IA doit être identifiable comme tel. Tout système qui interagit avec une personne physique doit le lui signaler — y compris un chatbot interne.
Sanctions: Jusqu'à 35 M€ ou 7 % du CA mondial pour les violations les plus graves (usage interdit). Pour les obligations GPAI, jusqu'à 15 M€ ou 3 % du CA.

Statut de déployeur vs fournisseur

Faire tourner Llama 3.3 70B en local ne fait pas de vous un fournisseur GPAI. Vous restez "déployeur". En revanche, si vous fine-tunez un modèle et le mettez à disposition d'autres entités, vous pouvez basculer dans la catégorie fournisseur avec ses obligations propres.

#Les risques concrets avec ChatGPT, Claude ou Gemini

Ces fournisseurs proposent désormais des offres entreprise (ChatGPT Enterprise, Claude for Work, Gemini for Workspace) qui contractent une non-utilisation des données pour l'entraînement et un hébergement parfois européen. C'est mieux qu'une API grand public. Ça ne résout pas tout.

Le Cloud Act US: Une entité de droit américain (OpenAI Inc., Anthropic PBC, Google LLC) reste juridiquement contrainte de coopérer avec les autorités américaines, même pour des données stockées en UE. La CJUE l'a rappelé dans Schrems II en 2020.
Le DPF en sursis: Le Data Privacy Framework UE-USA (juillet 2023) qui fonde la majorité des transferts est attaqué devant la CJUE. Un Schrems III invaliderait des milliers d'AIPD du jour au lendemain.
L'opacité du modèle: Vous ne savez pas exactement ce que le modèle a vu en entraînement, ni comment les filtres de modération journalisent vos prompts. Côté ChatGPT, des logs "abuse" sont conservés 30 jours minimum même en Enterprise.
Le shadow IT: Le risque #1 en pratique n'est pas le contrat, c'est qu'un collaborateur copie-colle un fichier RH dans la version gratuite de ChatGPT. Aucune politique écrite ne résiste à un onglet de navigateur.

→

L'argument qui parle au CODIR

Un LLM local supprime à la fois le risque juridique (transferts, sanctions AI Act) et le risque shadow IT (les collaborateurs ont enfin une alternative interne qui marche). C'est rarement "moins cher que ChatGPT Enterprise", mais c'est presque toujours "moins risqué et plus rapide à auditer".

#La stack recommandée pour un DPO en 2026

Il n'existe pas une stack unique, mais une famille de combinaisons éprouvées que les DSI et DPO français déploient depuis 18 mois. Trois profils types couvrent 90 % des besoins.

#Profil 1 — Petite équipe, postes individuels

Matériel: Postes équipés d'une RTX 4070 12 Go, RTX 4080 16 Go ou Mac M4 Pro 24-48 Go. Pas de serveur central.
Logiciel: Ollama (daemon local sur chaque poste) + LM Studio ou Open WebUI comme interface. Aucune donnée ne quitte le poste.
Modèle conseillé: Mistral Small 24B Q4 (français natif, licence Mistral AI Research ou commerciale selon usage) ou Llama 3.3 70B Q4 si VRAM ≥ 40 Go.
Cible: Cabinets d'avocats, cabinets comptables, équipes RH de PME, journalistes. Toute structure < 30 personnes avec un usage individuel.

#Profil 2 — Serveur d'inférence interne

Matériel: Serveur GPU dédié : RTX 4090 24 Go, A6000 48 Go ou 2× RTX 3090 24 Go. Hébergé dans le SI ou chez un cloud souverain (OVH, Scaleway, Outscale).
Logiciel: vLLM ou Ollama exposant une API OpenAI-compatible sur le réseau interne. Open WebUI ou LibreChat en frontend, derrière l'IdP de l'entreprise (Keycloak, Azure AD).
Modèle conseillé: Mistral Small 24B, Qwen 2.5 32B ou Llama 3.3 70B Q4 selon VRAM. Modèle d'embeddings BGE-M3 ou Solon pour le RAG documentaire.
Cible: ETI, services juridiques internes, équipes data 30-500 personnes. Permet la mutualisation et le contrôle d'accès centralisé.

#Profil 3 — Air-gap pour données sensibles

Matériel: Serveur isolé physiquement du réseau public. Disques chiffrés LUKS. Modèles téléchargés via support physique sur un poste de transit.
Logiciel: vLLM compilé localement, llama.cpp from source. Pas de container public, pas d'image Docker tirée à chaud.
Modèle conseillé: Modèles à licence permissive validés (Mistral, Llama 3, Qwen avec audit des poids). Idéalement un modèle dont vous avez archivé une copie locale du tarball.
Cible: Santé (DMP, comptes-rendus), défense, secret des affaires lourd, OIV/OSE. Tout ce qui relèverait d'une AIPD à risque résiduel élevé en cloud.

#Mise en œuvre : les 5 étapes structurantes

01
Cartographier les usages
Avant de choisir un modèle, listez les cas d'usage réels : rédaction, traduction, résumé de contrats, analyse de logs, support N1. Pour chaque cas, notez la sensibilité des données traitées (publiques, internes, confidentielles, secret pro). Cette cartographie devient l'annexe d'usage de votre AIPD.
02
Choisir le profil et le modèle
À partir de la cartographie et de l'inventaire matériel, sélectionnez un des trois profils ci-dessus. Pour le modèle, partez de Mistral Small 24B en Q4_K_M si vous avez 16-24 Go de VRAM — c'est le compromis le plus équilibré pour le français en 2026. Q4_K_M reste la quantization recommandée par défaut (perte de qualité < 2 % vs FP16).
03
Installer le serveur d'inférence
Ollama écoute par défaut sur http://localhost:11434. Pour exposer sur le réseau interne, définissez OLLAMA_HOST=0.0.0.0:11434 et placez l'API derrière un reverse proxy (Caddy, Traefik) qui gère l'authentification. Activez les logs d'accès et conservez-les 6 mois pour traçabilité.
04
Documenter dans le registre
Créez ou mettez à jour la fiche de traitement "Assistance par IA générative interne" dans votre registre des activités de traitement (article 30 RGPD). Finalités, catégories de données, durées de conservation, mesures techniques. Le fait que ce soit local doit y figurer explicitement.
05
Former et communiquer
Une charte d'usage de l'IA, signée par chaque collaborateur, qui rappelle : (1) usage exclusif de l'instance interne, (2) interdiction des outils cloud non validés, (3) types de données autorisés par cas d'usage. Annexez-la au règlement intérieur après consultation du CSE.

Configuration Ollama exposé sur le réseau interne

# Sur Linux (systemd)
sudo systemctl edit ollama.service

# Ajouter :
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.interne.entreprise.fr"
Environment="OLLAMA_KEEP_ALIVE=24h"

# Recharger et redémarrer
sudo systemctl daemon-reload
sudo systemctl restart ollama

# Vérifier
curl http://serveur-ia.interne:11434/api/tags

Ne pas exposer 0.0.0.0 sans reverse proxy

OLLAMA_HOST=0.0.0.0 expose l'API sans aucune authentification. Toute personne sur le réseau peut interroger vos modèles, lister les conversations et en télécharger. Placez systématiquement un reverse proxy avec authentification (OIDC, mTLS, basic auth + IP filtering) devant. C'est non négociable.

#Checklist d'audit de conformité

Cette grille couvre les points qu'un audit RGPD-IA Act vérifierait sur un déploiement LLM local en entreprise. Imprimez-la, cochez-la, archivez-la.

#Gouvernance et documentation

Registre art. 30: Fiche de traitement "IA générative interne" à jour, avec finalités, données, durées, destinataires (internes uniquement) et mesures techniques.
AIPD: Réalisée si le traitement est à risque élevé (RH, santé, profilage). Mise à jour à chaque changement majeur de modèle ou de cas d'usage.
Charte d'usage IA: Diffusée, signée, intégrée au règlement intérieur après consultation CSE.
Cartographie des usages: Liste à jour des cas d'usage validés et des données autorisées par cas.
Désignation du référent IA: Un responsable identifié (DPO, RSSI ou DSI selon org), avec mandat formalisé.

#Sécurité technique

Chiffrement au repos: Disque(s) du serveur d'inférence chiffrés (LUKS, BitLocker, FileVault). Inclut les modèles téléchargés et les éventuels caches de prompts.
Authentification: Accès à l'API filtré par OIDC ou mTLS. Pas d'instance Ollama accessible sans authentification, même en interne.
Journalisation: Logs d'accès (qui, quand, modèle interrogé) conservés 6 à 12 mois. Pas de log du contenu des prompts sauf cas d'usage explicite et documenté.
Cloisonnement réseau: Le serveur d'inférence n'a pas d'accès internet sortant en production. Pour les déploiements sensibles, air-gap complet.
Sauvegarde et reprise: PRA documenté : les modèles peuvent être ré-installés depuis une archive interne, sans dépendance immédiate à Hugging Face.

#Conformité AI Act

Classification du système: Vous avez statué : usage à risque limité, élevé, ou minimal. Si haut risque (annexe III), un dossier de conformité spécifique existe.
Information des utilisateurs: Chaque interface affiche "contenu généré par IA" ou un disclaimer équivalent. Article 50 AI Act, applicable août 2026.
Traçabilité du modèle: Version exacte du modèle utilisé, source des poids, date de téléchargement, hash SHA256 archivés. Permet de répondre à un audit sur "quel modèle a généré telle réponse à telle date".
Surveillance humaine: Pour les usages à haut risque, une procédure de revue humaine documentée avant toute décision affectant une personne (recrutement, scoring, sanction).

#Pièges fréquents

"Local" mais avec télémétrie: Certaines interfaces (LM Studio dans des versions anciennes, certains plugins VSCode) envoient des télémétries. Vérifiez avec un sniffer (Wireshark, Little Snitch) que rien ne sort. Notre guide checklist confidentialité couvre cette étape.
Modèles avec licence ambiguë: Llama 3 a une licence communautaire (Llama Community License) qui interdit l'usage par les très grandes entreprises (> 700 M MAU). Vérifiez la licence avant de déployer en prod, surtout si vous êtes une grosse structure ou un éditeur.
Confusion modèle / fine-tuning: Faire un fine-tuning sur des données RH internes crée un nouveau traitement, avec sa propre AIPD. Le modèle fine-tuné peut révéler des données d'entraînement (memorization). Pour des données sensibles, préférez le RAG au fine-tuning.
Sous-estimer la traçabilité: Si dans 18 mois quelqu'un vous demande "montrez-moi ce que l'IA a répondu sur mon dossier en mars", vous devez pouvoir répondre. Pensez logs d'audit dès le jour 1, pas après le premier incident.
Croire qu'un LLM local règle tout: Le LLM local règle le transfert, pas l'usage. Un modèle local utilisé pour faire du scoring RH automatisé reste un système à haut risque au sens de l'AI Act. Local ≠ exempté.

Position CNIL résumée

La CNIL a publié plusieurs fiches IA depuis 2024 (fiches sur la base légale, la minimisation, l'AIPD-IA). Elle n'impose pas le local mais le valorise comme "mesure technique appropriée" au sens de l'article 32 RGPD, surtout pour les données sensibles.

#Pour aller plus loin

Une fois la conformité posée, trois directions naturelles pour approfondir le déploiement :

Verrouiller la confidentialité technique: La checklist confidentialité détaille les vérifications réseau et système qui complètent le cadre légal côté DPO. Indispensable avant la mise en production.
Construire un RAG sur vos documents internes: Pour passer d'un assistant générique à un outil métier, le RAG (Retrieval-Augmented Generation) permet d'interroger contrats, procédures et bases internes sans fine-tuning. Le guide d'introduction au RAG local pose les bases.
Choisir l'interface utilisateur: Open WebUI couvre 80 % des besoins en entreprise : multi-utilisateurs, OIDC, RAG intégré, logs. Le guide dédié décrit le déploiement Docker derrière un reverse proxy.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Sécurité · 6 min

LLM local et RGPD : la conformité données privées en entreprise