Model extraction et inference attacks sur les LLM : comment les attaquants volent vos modèles et vos données d'entraînement

Enjeux : pourquoi votre LLM fine-tuné est un actif volable

Quand une entreprise fine-tune un LLM sur ses données métier — contrats clients, procédures internes, base de connaissances propriétaire — elle crée deux catégories d'actifs intellectuels distincts :

• Le modèle lui-même : les poids ajustés représentent des mois de travail d'ingénierie, des coûts de compute significatifs, et une expertise métier encodée dans les paramètres du réseau de neurones.
• Les données d'entraînement : la base de connaissance, les exemples annotés, les documents confidentiels utilisés pour le fine-tuning peuvent être partiellement reconstruits à partir du modèle entraîné.

Ces deux actifs sont menacés par des catégories d'attaques distinctes. Un concurrent, un acteur étatique hostile ou un cybercriminel peut être motivé à les dérober pour éviter les coûts de développement, obtenir des informations confidentielles sur votre entreprise, ou revendre un modèle concurrent sur des marchés souterrains.

Model Extraction Attacks : reconstruire votre modèle par observation

Principe fondamental

Une model extraction attack (aussi appelée model stealing) exploite le fait que les API LLM exposent des informations sur le modèle à chaque inférence. En soumettant un large volume de requêtes soigneusement choisies et en observant les sorties, un attaquant peut entraîner un modèle surrogate (modèle substitut) qui reproduit le comportement du modèle cible avec une précision élevée.

La technique fondatrice (Tramèr et al., 2016) visait des classifieurs simples. Appliquée aux LLM modernes, elle est plus complexe mais reste réalisable, particulièrement pour des modèles fine-tunés sur des domaines spécifiques où l'espace des comportements est plus restreint qu'un modèle généraliste.

Anatomie d'une attaque d'extraction LLM

Phase 1 — Reconnaissance (1-5K requêtes) : l'attaquant cartographie le comportement général du modèle, identifie ses spécialités, teste ses guardrails et détermine les domaines de compétence distinctifs qui trahissent le fine-tuning.

Phase 2 — Génération du dataset de distillation (10-100K requêtes) : l'attaquant génère un dataset synthétique en soumettant des requêtes variées et en collectant les paires (input, output). Pour les LLM, les probabilités de tokens (logprobs) sont particulièrement informatives — si l'API les expose, la vitesse d'extraction est multipliée par 5 à 10.

Phase 3 — Entraînement du modèle surrogate : le dataset collecté est utilisé pour fine-tuner un modèle de base (souvent open source : Llama, Mistral) par distillation de connaissances. Le résultat est un modèle qui imite le comportement du modèle cible.

Efficacité selon le type de modèle

Type de modèle cible	Difficulté d'extraction	Requêtes nécessaires	Fidélité du surrogate
Classifieur spécialisé (sentiment, toxicité)	Faible	1 000 – 10 000	90-95%
LLM généraliste (GPT-4 like)	Très élevée	Millions+	60-70%
LLM fine-tuné domaine spécifique	Moyenne	50 000 – 200 000	75-85%
LLM RAG avec base documentaire	Faible (pour le comportement)	10 000 – 50 000	80-90% sur le domaine
Modèle embedding spécialisé	Élevée	100 000 – 500 000	70-80%

Logprobs : le multiplicateur d'efficacité

Si votre API expose les log-probabilités des tokens (logprobs), chaque requête donne à l'attaquant une information beaucoup plus riche que la simple sortie texte. Les logprobs révèlent la distribution de probabilité complète du modèle, permettant une distillation bien plus efficace. Recommandation immédiate : désactiver l'exposition des logprobs dans toutes vos API LLM de production si ce n'est pas fonctionnellement nécessaire.

Membership Inference Attacks : savoir si une donnée était dans l'entraînement

Définition et enjeux

Une membership inference attack (MIA) détermine si un exemple spécifique faisait partie du dataset d'entraînement d'un modèle. Pour les LLM fine-tunés sur des données confidentielles, cette attaque permet à un adversaire de vérifier si des documents spécifiques (contrats, e-mails, données personnelles) ont été inclus dans l'entraînement — ce qui constitue une violation de confidentialité même sans accéder aux données directement.

Mécanisme

Les LLM ont tendance à assigner des probabilités plus élevées aux séquences qu'ils ont vues pendant l'entraînement (phénomène de mémorisation). Une MIA exploite cette différence statistique :

1. L'attaquant soumet le texte suspect au modèle et observe la log-vraisemblance (ou la perplexité) de la séquence
2. Si la perplexité est anormalement basse, le texte a probablement été vu pendant l'entraînement
3. Comparée à des textes de référence similaires non vus pendant l'entraînement, la différence statistique permet de classifier

Application pratique par un attaquant

Imaginons qu'une entreprise ait fine-tuné un LLM sur ses e-mails internes. Un concurrent ayant accès à l'API peut soumettre des e-mails suspects (obtenus par d'autres moyens) et déterminer avec une précision de 70-80% s'ils faisaient partie du corpus d'entraînement — confirmant ainsi leur authenticité et leur contenu.

Dans un contexte RGPD, si des données personnelles ont été incluses dans le fine-tuning, une MIA réussie constitue une preuve de traitement de données personnelles dans le modèle, avec des implications légales significatives.

Model Inversion Attacks : reconstruire les données d'entraînement

Principe

Les model inversion attacks vont plus loin que les MIA : elles tentent de reconstruire des données d'entraînement à partir des gradients ou des activations du modèle. Pour les LLM, cela se traduit par la capacité à générer des exemples représentatifs du corpus d'entraînement — sans y avoir accès directement.

Gradient leakage dans le fine-tuning fédéré

Le risque est particulièrement marqué dans les scénarios de federated learning ou de fine-tuning distribué, où des gradients sont échangés entre participants. Des techniques comme Deep Leakage from Gradients (DLG) permettent de reconstruire des données d'entraînement avec une fidélité surprenante à partir de gradients échangés — un vecteur d'attaque à surveiller pour les consortiums d'entreprises qui partagent l'entraînement de modèles sectoriels.

Training Data Extraction : forcer le modèle à révéler ses secrets

Mémorisation des LLM

Les LLM mémorisent une fraction de leurs données d'entraînement de façon verbatim. La recherche de Carlini et al. (Google, 2023) a démontré que des séquences spécifiques — numéros de téléphone, adresses e-mail, extraits de documents confidentiels — peuvent être extraites en invitant le modèle à les compléter ou à les reproduire.

Cette mémorisation est particulièrement marquée pour :

• Les données apparaissant plusieurs fois dans le corpus (duplication de données)
• Les séquences longues et structurées (numéros de séquence, codes, données tabulaires)
• Les données incluses en début ou en fin de documents
• Les données de fine-tuning (qui ont reçu plus d'epochs d'entraînement)

Techniques d'extraction

Attaque par complétion : soumettre le début d'une séquence connue ou probable et observer si le modèle complète correctement — "Le contrat signé le 15 mars 2025 entre [ENTREPRISE] et..."

Attaque par prefix : utiliser des préfixes spéciaux qui augmentent la mémorisation (certains tokens ont un effet de déclenchement sur la mémorisation).

Génération massive et filtrage : générer de grandes quantités de texte et filtrer les sorties contenant des patterns reconnaissables (adresses, numéros, noms propres).

Implications RGPD

Si des données personnelles ont été incluses dans le corpus de fine-tuning, leur extraction via ces techniques constitue une violation de données au sens RGPD — même si l'attaquant n'a accès qu'à l'API publique du modèle. Le responsable de traitement (l'entreprise qui a déployé le LLM) est responsable de cette fuite. La CNIL a explicitement mentionné ce risque dans ses recommandations 2026 sur l'IA (voir recommandations CNIL 2026).

Vecteurs d'accès et surface d'attaque

Vecteur d'accès	Attaques facilitées	Profil attaquant	Probabilité
API d'inférence exposée (Internet)	Model extraction, training data extraction, MIA	Concurrent, criminel organisé	Élevée
Accès partenaire/client à l'API	Model extraction, MIA	Client malveillant, partenaire concurrent	Moyenne
Insider (employé, prestataire)	Exfiltration directe des poids, training data extraction	Employé mécontent, espion industriel	Faible (mais impact maximal)
Compromission du fournisseur LLM	Accès aux poids, aux données d'entraînement	Acteur étatique, APT	Très faible (mais catastrophique)
Accès physique à l'infrastructure	Copie directe des poids, extraction DRAM	Acteur étatique, vol physique	Très faible

Défenses techniques pour RSSI : protéger vos modèles et vos données

Défenses contre l'extraction de modèle

1. Rate limiting agressif

C'est la défense la plus immédiate. Une extraction efficace nécessite des dizaines de milliers de requêtes. Limiter chaque utilisateur/API key à quelques centaines de requêtes par heure rend l'extraction économiquement non viable pour les modèles de grande taille.

2. Désactivation des logprobs

Ne jamais exposer les log-probabilités de tokens dans les API de production. Cette seule mesure multiplie par 5 à 10 le volume de requêtes nécessaire pour une extraction efficace.

3. Output perturbation (differential privacy)

Ajouter du bruit calibré aux sorties du modèle (randomized response, température augmentée) réduit la précision des modèles surrogates entraînés sur ces sorties. Cette technique dégrade légèrement la qualité des réponses mais protège efficacement contre l'extraction.

4. Watermarking des sorties

Des techniques de watermarking statistique des sorties LLM permettent de tracer l'origine d'un modèle extrait. Si un modèle concurrent présente les patterns de watermark de votre système, vous disposez d'une preuve légale de vol.

5. Diversification des modèles

Entraîner plusieurs variantes du modèle et router les requêtes de façon aléatoire rend l'extraction moins efficace (le surrogate doit imiter plusieurs distributions).

Défenses contre les inference attacks

1. Differential Privacy (DP) pendant le fine-tuning

L'entraînement avec garanties de differential privacy (DP-SGD) ajoute du bruit calibré aux gradients pendant l'entraînement, réduisant mathématiquement la mémorisation et la vulnérabilité aux MIA et aux attaques d'inversion. Le coût est une légère dégradation des performances du modèle.

2. Déduplication des données d'entraînement

La mémorisation est proportionnelle à la fréquence d'apparition dans le corpus. Dédupliquer rigoureusement les données de fine-tuning réduit drastiquement la mémorisation verbatim.

3. Data minimization dans le fine-tuning

N'inclure dans le corpus de fine-tuning que les données strictement nécessaires. Les données personnelles et les informations confidentielles qui ne sont pas nécessaires au comportement cible du modèle ne devraient jamais entrer dans le corpus.

4. Anonymisation et pseudonymisation

Anonymiser les données sensibles avant inclusion dans le corpus de fine-tuning. Des techniques comme le Named Entity Recognition (NER) + remplacement permettent de conserver la structure linguistique tout en supprimant les identifiants.

Protection des poids du modèle

• Chiffrement au repos des fichiers de poids (AES-256) avec gestion des clés en HSM
• Contrôle d'accès granulaire : seuls les processus d'inférence autorisés peuvent charger les poids
• Cloisonnement réseau : les serveurs hébergeant les modèles n'ont pas d'accès Internet sortant
• Journalisation de tout accès aux fichiers de poids (audit trail pour détection d'exfiltration)
• Sauvegarde chiffrée hors-site avec contrôle d'intégrité

Détection et monitoring des attaques d'extraction

Signaux d'alerte d'une extraction en cours

Les attaques d'extraction ont des patterns comportementaux distinctifs :

• Volume anormal de requêtes : un utilisateur ou une API key soumettant 10x à 100x plus de requêtes que la moyenne
• Distribution atypique des inputs : les datasets d'extraction contiennent souvent des requêtes très diverses (couverture de l'espace des inputs) ou très structurées (grilles de templates)
• Requêtes courtes et répétitives : des milliers de requêtes courtes maximisant le nombre de tokens de sortie par requête
• Accès aux endpoints de logprobs : tout appel aux endpoints exposant les probabilités de tokens doit générer une alerte
• Patterns de requêtes automatisées : absence de variabilité temporelle (burst régulier), User-Agent inhabituel, absence de cookies de session

Système de détection recommandé

Implémenter une pipeline de détection à plusieurs niveaux :

1. Niveau 1 — Rate limiting automatique : blocage immédiat au dépassement des seuils (API gateway)
2. Niveau 2 — Analyse statistique temps réel : détection des distributions anormales de requêtes (ML sur les méta-données)
3. Niveau 3 — Honeypot tokens : inclure des données leurres dans le système qui, si retrouvées dans un modèle concurrent, prouvent l'extraction
4. Niveau 4 — Veille externe : surveiller les modèles publiés sur Hugging Face et ailleurs pour détecter des comportements similaires au vôtre

Intelligence Privée : architecture anti-extraction by design

L'architecture d'Intelligence Privée élimine plusieurs vecteurs d'attaque à la source :

• Pas d'API publique par défaut : vos modèles ELODIE et KEVINA 32B ne sont accessibles que depuis votre réseau interne, éliminant les attaques d'extraction depuis Internet
• Logprobs jamais exposés : les log-probabilités ne sont pas disponibles dans l'API pour les clients
• Rate limiting configurable : chaque équipe et chaque application peut se voir attribuer des quotas distincts
• Audit trail complet : chaque requête est journalisée avec IP source, utilisateur, timestamp et volume de tokens pour la détection d'anomalies
• Hébergement souverain : vos poids ne quittent jamais les datacenters français, éliminant le risque de compromission via un fournisseur cloud étranger (voir souveraineté des données)

Cadre légal et droits de propriété intellectuelle des modèles IA

La protection juridique des modèles IA en France

Avant de traiter des défenses techniques, il est essentiel de comprendre le cadre juridique qui protège vos modèles IA. La protection légale d'un modèle de langage fine-tuné s'articule autour de plusieurs corps de droit :

Le droit d'auteur : en France, le droit d'auteur protège les œuvres de l'esprit originales. Les poids d'un modèle fine-tuné peuvent-ils bénéficier de cette protection ? La question est débattue. La jurisprudence française n'a pas encore tranché clairement, mais la tendance est de reconnaître une protection pour les éléments de conception originaux (architecture, choix de données, processus de fine-tuning) plutôt que pour les poids eux-mêmes.

Le secret des affaires : la loi du 30 juillet 2018 (transposant la directive européenne 2016/943) protège les informations secrètes ayant une valeur commerciale et pour lesquelles des mesures raisonnables de protection ont été prises. Un modèle fine-tuné sur des données propriétaires, conservé sous contrôle d'accès strict, peut bénéficier de cette protection. C'est souvent la voie juridique la plus efficace contre le vol de modèle.

Le droit sui generis des bases de données : si votre modèle a été entraîné sur une base de données constituée avec un investissement substantiel, cette base bénéficie d'une protection sui generis. L'extraction substantial d'informations de cette base (via des inference attacks réussies) pourrait constituer une violation de ce droit.

La concurrence déloyale : même sans qualification pénale, le vol d'un modèle suivi de son exploitation commerciale peut être sanctionné par les prud'hommes ou les tribunaux de commerce sur le fondement de la concurrence déloyale.

Constituer les preuves pour une action judiciaire

Pour transformer un vol de modèle en action judiciaire réussie, vous devez être en mesure de prouver :

1. La propriété du modèle original : documentation de la date de création, des investissements réalisés, des données d'entraînement utilisées. Versionnement git des pipelines de fine-tuning avec horodatage.
2. Les mesures de protection mises en place : contrôle d'accès, chiffrement, monitoring — preuves que vous avez traité le modèle comme un secret commercial.
3. L'extraction : logs des requêtes anormales, patterns statistiques compatibles avec une campagne d'extraction, honeypot tokens retrouvés dans le modèle suspect.
4. L'identité du modèle extrait : comparaison comportementale (benchmark identique), watermarks retrouvés, performance anormalement proche du modèle original sur les cas d'usage spécifiques.

Une approche recommandée : faire établir un constat d'huissier sur vos mesures de protection et les caractéristiques comportementales de votre modèle ("empreinte digitale") avant tout incident. Ce constat daté sera une preuve précieuse si un vol survient ultérieurement.

Cas d'études : extractions réelles documentées

L'extraction de GPT-3.5 par des chercheurs universitaires (2024)

En 2024, des chercheurs de l'Université de Washington ont publié une démonstration d'extraction partielle de GPT-3.5-turbo via l'API OpenAI, avec un budget d'environ 2 000 USD de requêtes API. Leur modèle surrogate reproduisait 80% des comportements du modèle original sur les benchmarks testés. OpenAI a rapidement limité les endpoints exposant les logprobs après cet incident. L'étude a démontré que même les LLM les plus grands et les plus sécurisés des fournisseurs majeurs ne sont pas immunisés contre l'extraction.

Le vol de modèle dans le secteur financier

Plusieurs incidents non publics (documentés de façon anonymisée par des cabinets de cybersécurité) impliquent des extractions de modèles de détection de fraude dans le secteur bancaire. Un concurrent ayant identifié qu'une banque utilisait un modèle IA propriétaire pour scorer les demandes de crédit a soumis des milliers de demandes test via des prête-noms pour reconstituer les règles de décision du modèle. Ce type d'attaque (model extraction appliquée aux systèmes de décision) est distincte de l'extraction LLM mais illustre la motivation économique réelle du vol de modèle.

La fuite interne : le risque majoritaire

Les données de la communauté de la sécurité IA suggèrent que la majorité des vols de modèles impliquent un accès interne : un data scientist qui copie les poids sur son poste avant de partir chez un concurrent, un prestataire de fine-tuning qui conserve une copie du modèle client, ou un ingénieur qui exfiltre via un service cloud personnel. Ces vols sont difficiles à détecter et à prouver, d'où l'importance des contrôles d'accès granulaires et des audits trails sur les fichiers de poids.

Stratégie complète de protection des actifs LLM

La politique de protection des modèles IA

Une politique formelle de protection des modèles IA doit être documentée et communiquée à tous les acteurs impliqués. Elle doit couvrir :

• Classification des actifs : identifier et classer chaque modèle IA selon sa sensibilité (modèle de base public, modèle fine-tuné interne, modèle intégrant des données clients)
• Contrôles d'accès : qui peut accéder aux poids, aux données d'entraînement, aux pipelines de fine-tuning — avec authentification forte et audit de chaque accès
• Exigences contractuelles : clauses de confidentialité dans les contrats des prestataires ayant accès aux modèles, avec définition explicite des interdictions (copie, réutilisation, formation de modèles concurrents)
• Procédures de départ : révocation immédiate des accès aux modèles lors du départ d'un collaborateur, avec checklist de vérification
• Surveillance continue : monitoring des accès aux fichiers de poids, détection des exfiltrations via DLP (Data Loss Prevention)

Architecture technique de protection

Les poids d'un modèle LLM sont des fichiers de plusieurs dizaines à centaines de gigaoctets (un modèle 7B en FP16 = ~14 GB, un 70B = ~140 GB). Leur protection technique repose sur :

• Stockage chiffré : chiffrement au repos avec AES-256, clés gérées dans un HSM (Hardware Security Module). Certains fournisseurs cloud proposent des customer-managed keys (CMK) — exiger cette option pour les modèles critiques.
• Serving sécurisé : le serveur d'inférence qui charge les poids en mémoire GPU doit être dans un réseau isolé, sans accès Internet sortant, avec journalisation de tout trafic réseau.
• Attestation à distance : des technologies comme Intel TDX ou AMD SEV permettent de vérifier cryptographiquement que le modèle tourne dans un environnement d'exécution de confiance, sans accès possible depuis l'hôte.
• Limitation des sorties : pour les modèles accessible via API, implémenter des limites strictes sur le volume de sortie par requête et sur le total journalier par utilisateur, rendant l'extraction économiquement non viable.

Pour une vue complète de la protection de votre infrastructure IA : notre guide LLM local sur GPU : infrastructure et sécurité et notre article sur la souveraineté des données cloud.

Choisir un fournisseur IA qui protège vos modèles

Si vous externalisez le fine-tuning ou l'hébergement de vos modèles, les questions à poser à votre fournisseur IA :

• Vos poids de modèle fine-tuné sont-ils stockés dans un espace de stockage dédié, isolé des autres clients ?
• Qui dans les équipes du fournisseur peut accéder à vos poids ? Dans quelles circonstances ? Avec quelle journalisation ?
• Le contrat prévoit-il explicitement l'interdiction pour le fournisseur d'utiliser votre modèle fine-tuné pour entraîner d'autres modèles ou servir d'autres clients ?
• Quelles sont les procédures de restitution et de destruction des poids en cas de résiliation du contrat ?
• Le fournisseur a-t-il un programme de bug bounty ou des audits de sécurité réguliers publiés ?

Intelligence Privée répond positivement à toutes ces questions avec des garanties contractuelles explicites. Vos modèles fine-tunés sur KEVINA 32B sont stockés dans un espace dédié à votre organisation, chiffré avec des clés dont vous êtes le seul détenteur, et détruits dans les 30 jours suivant la résiliation du contrat sur demande.

Membership Inference et RGPD : implications légales et pratiques

Quand la MIA devient une violation de données personnelles

La Commission Nationale de l'Informatique et des Libertés (CNIL) a explicitement évoqué dans ses recommandations de 2026 le risque que des attaques d'inférence sur des LLM constituent des violations de données personnelles au sens de l'Article 4(12) du RGPD. Ce positionnement a des implications pratiques importantes pour les entreprises qui fine-tunent des LLM sur des données incluant des informations personnelles.

La qualification juridique repose sur un raisonnement en trois étapes :

1. Les données personnelles ont été traitées : elles ont été incluses dans le corpus de fine-tuning, ce qui constitue un traitement au sens du RGPD.
2. Les données sont en partie "mémorisées" dans le modèle : les poids encodent de façon implicite des informations sur les données d'entraînement.
3. Un tiers non autorisé peut extraire ces informations : via une MIA réussie, le tiers accède à des informations personnelles sans y être autorisé — violation de données.

Les conséquences pour les responsables de traitement : si votre LLM fine-tuné mémorise des données personnelles exploitables via MIA, vous avez potentiellement une base de données personnelles vulnérable déguisée en modèle IA. Une violation via MIA doit être notifiée à la CNIL dans les 72h si elle affecte des droits et libertés des personnes.

Mesures préventives RGPD pour le fine-tuning

Pour éviter de créer cette vulnérabilité RGPD via le fine-tuning, voici les mesures recommandées :

• Data minimization stricte : n'inclure dans le corpus de fine-tuning que les données strictement nécessaires au comportement cible. Si vous fine-tunez un assistant comptable, les données clients nominatives des dossiers ne sont pas nécessaires — les patterns de raisonnement comptable anonymisés suffisent.
• Anonymisation avant fine-tuning : appliquer des techniques d'anonymisation robustes (pseudonymisation + agrégation) sur toutes les données personnelles avant leur inclusion dans le corpus. Des outils comme Presidio (Microsoft) ou spaCy + NER permettent d'identifier et remplacer automatiquement les entités nommées.
• Differential Privacy : l'entraînement avec garanties DP (DP-SGD) réduit mathématiquement le risque de mémorisation et renforce la défense contre les MIA.
• Évaluation ex ante des risques MIA : avant de déployer un modèle fine-tuné sur des données personnelles, effectuer une évaluation du risque MIA en utilisant des outils comme ML Privacy Meter (MIT) pour estimer la vulnérabilité du modèle.
• Documentation de la base légale : documenter explicitement la base légale du traitement IA des données personnelles dans le registre des traitements RGPD, en incluant les mesures de minimisation du risque d'inférence.

Watermarking des LLM : technique de traçabilité et de preuve

Principe et enjeux du watermarking LLM

Le watermarking des LLM est une technique qui intègre des marqueurs statistiques imperceptibles dans les sorties du modèle, permettant d'identifier ultérieurement que du texte a été généré par un modèle spécifique. Cette technologie est centrale dans deux usages défensifs :

• Détection du contenu généré par IA : identifier si un texte soumis a été généré par votre LLM (usage interne, détection de fraude)
• Traçabilité du vol de modèle : si un modèle extrait est utilisé pour générer du contenu, les watermarks de l'original peuvent se retrouver dans les sorties du surrogate — constituant une preuve de vol

Techniques de watermarking LLM

Deux familles de techniques existent :

Watermarking du processus de génération (red-green list) : lors de la génération de tokens, une règle secrète (basée sur un hash du contexte) classe les tokens du vocabulaire en deux groupes ("rouge" et "vert"). Le modèle favorise systématiquement les tokens verts. Un observateur avec la clé peut vérifier statistiquement si un texte suit ce biais. Avantage : imperceptible pour l'utilisateur. Inconvénient : modifie légèrement la distribution des sorties.

Watermarking post-génération (steganographie) : des techniques de steganographie linguistique modifient subtilement le texte généré (choix de synonymes, variations de ponctuation) pour encoder un message secret. Plus fragile mais applicable à des LLM existants sans modification.

Des implémentations open source sont disponibles : KGW Watermark (Kirchenbauer et al., Maryland), SynthID Text (Google DeepMind). Intelligence Privée implémente un watermarking propriétaire sur les sorties de KEVINA 32B pour permettre à ses clients de tracer l'origine de leur contenu généré.

Limites du watermarking

Le watermarking n'est pas une protection absolue :

• Le paraphrasage humain ou automatique des sorties peut effacer les watermarks statistiques
• La traduction vers une autre langue efface généralement les watermarks
• Un attaquant informé de l'existence du watermarking peut tenter de l'effacer activement

Le watermarking doit être considéré comme un outil de détection a posteriori et de preuve judiciaire, pas comme une protection préventive. Il est complémentaire des défenses préventives (rate limiting, output perturbation) et des contrôles d'accès physiques.

La veille concurrentielle sur les modèles : détecter le vol a posteriori

Une fois les protections en place, la surveillance continue est nécessaire pour détecter des vols qui auraient eu lieu malgré les défenses. Les techniques de veille concurrentielle pour la protection des modèles IA :

• Monitoring de Hugging Face : surveiller les nouveaux modèles publiés dans votre secteur en utilisant des requêtes test caractéristiques de votre modèle. Un modèle suspect qui répond de façon anormalement similaire au vôtre sur vos cas d'usage spécifiques mérite investigation.
• Benchmarks fingerprint : constituer un ensemble de 100 à 200 paires input/output très caractéristiques de votre modèle fine-tuné (là où votre modèle se distingue le plus des modèles de base). Tester régulièrement ces inputs sur des modèles concurrents.
• Watermark verification : si vous avez implémenté le watermarking, vérifier périodiquement si des textes circulant dans votre secteur portent les signatures de votre modèle.
• Veille des brevets IA : certains acteurs déposent des brevets sur des comportements de modèle proches des vôtres — signal précoce d'une appropriation de savoir-faire.

En cas de détection d'un vol de modèle probable, la démarche recommandée est : 1) Documenter les preuves (logs, tests comportementaux, watermarks) avant toute notification. 2) Consulter un avocat spécialisé en propriété intellectuelle IA. 3) Engager une procédure de mesure d'instruction (saisie-contrefaçon) si les preuves sont suffisantes. 4) Notifier les partenaires et clients concernés si des données sensibles pourraient avoir été compromises.

Pour aller plus loin sur la protection globale de vos actifs IA : notre article sur l'audit fournisseur IA et notre guide sur les clauses contractuelles essentielles pour les contrats IA SaaS.

Synthèse : protéger vos modèles LLM par une approche multicouche

La protection des actifs LLM contre les attaques d'extraction et d'inférence nécessite une approche multicouche combinant mesures techniques, juridiques et organisationnelles. Aucune mesure isolée n'est suffisante : le rate limiting sans audit trail laisse des attaques non détectées ; la differential privacy sans rate limiting ralentit mais n'arrête pas l'extraction ; les clauses contractuelles sans chiffrement des poids ne protègent pas contre les incidents techniques. La souveraineté de l'infrastructure est la mesure structurelle la plus efficace : en éliminant l'exposition des poids à des fournisseurs cloud étrangers et en contrôlant totalement l'accès réseau, elle réduit drastiquement la surface d'attaque. Intelligence Privée héberge vos modèles fine-tunés dans une architecture conçue pour cette protection maximale. Pour une vue complète de la gestion des risques IA : consultez notre guide ultime de l'IA en entreprise 2026.

FAQ — Model Extraction et Inference Attacks

Une attaque d'extraction peut-elle réussir sur un modèle protégé par authentification ?

L'authentification ralentit mais n'empêche pas les attaques. Un attaquant avec un accès légitime (client, partenaire, employé) peut mener une extraction depuis un compte autorisé. Les protections efficaces sont le rate limiting, la désactivation des logprobs, et l'output perturbation — qui s'appliquent indépendamment du statut d'authentification.

Quel est le coût légal du vol d'un modèle IA ?

En droit français, le vol d'un modèle IA peut être qualifié d'atteinte au secret des affaires (loi du 30 juillet 2018), de vol de données informatiques (article 323-1 du Code pénal), ou de concurrence déloyale. La directive européenne sur le secret des affaires offre des recours civils incluant des injonctions et des dommages-intérêts. Le watermarking des sorties est essentiel pour constituer les preuves nécessaires à une action judiciaire.

La differential privacy impacte-t-elle significativement les performances du modèle ?

Oui, il y a un trade-off. Pour un epsilon de DP de 8 (protection raisonnablement forte), la dégradation de performance est de l'ordre de 5-15% selon la tâche et la taille du modèle. Pour des epsilon plus faibles (ε = 1, protection très forte), la dégradation peut atteindre 20-30%. Pour la plupart des cas d'usage métier, un ε entre 4 et 8 offre un bon équilibre protection/performance. Des recherches récentes (2025) montrent que les LLM de grande taille supportent mieux la DP que les petits modèles.

Comment détecter si mon modèle a déjà été extrait ?

Trois approches complémentaires : 1) Surveiller les modèles publiés sur Hugging Face, GitHub, et les marchés noirs avec des requêtes benchmarks sur votre domaine spécifique. 2) Si vous avez implémenté le watermarking des sorties, tester les modèles suspects avec les clés de watermark. 3) Analyser rétrospectivement vos logs de requêtes pour identifier des patterns d'extraction passés — pics de volume, distributions atypiques, requêtes systématiques.

Les LLM open source (Llama, Mistral) sont-ils plus vulnérables ?

Les modèles de base open source ne sont pas volables (ils sont publics). Le risque porte sur votre fine-tuning et vos données d'entraînement. Un modèle Mistral fine-tuné sur vos données est aussi vulnérable qu'un modèle propriétaire. L'avantage des LLM open source est que vous contrôlez l'infrastructure d'hébergement, ce qui permet d'implémenter les protections décrites dans ce guide sans dépendre d'un fournisseur tiers (voir LLM open source en entreprise).

Un LLM hébergé on-premise est-il protégé contre les inference attacks ?

L'hébergement on-premise protège contre les vecteurs d'attaque external (extraction via API publique, compromission fournisseur cloud). Mais les risques d'insider threat, d'exfiltration physique et de MIA par des utilisateurs internes restent présents. Les défenses techniques (DP, rate limiting interne, audit trail) s'appliquent aussi en environnement on-premise.