Data poisoning et model leakage — comment les détecter en production

Deux attaques que je vois sous-traitées dans les programmes sécurité IA : le data poisoning (l'attaquant pollue les données qui entraînent le modèle) et le model leakage (le modèle fuite ses données d'entraînement, ou est extrait par requêtes). Ce sont deux risques qui n'apparaissent jamais sur le dashboard SIEM classique. Donc on ne les détecte pas, donc on croit qu'ils ne se produisent pas.

Data poisoning — ce que c'est en pratique

L'attaque consiste à injecter des données malicieuses dans le dataset utilisé pour entraîner ou fine-tuner un modèle. Trois variantes que je rencontre :

Backdoor poisoning

L'attaquant injecte un pattern déclencheur (un mot, une chaîne, une image avec un watermark) qui, présent en input, fait sortir un comportement contrôlé. Le modèle se comporte normalement le reste du temps — donc l'attaque passe l'évaluation qualité.

Exemple réel observé en 2024-2025 : un modèle de modération de contenu où une chaîne particulière en commentaire faisait passer le commentaire. Découverte par hasard plusieurs mois après.

Targeted misclassification

L'attaquant injecte des données mal labellisées pour faire échouer le modèle sur une cible précise (un concurrent, un type de transaction). Pas de backdoor — juste une dérive ciblée du classifier.

Availability poisoning

L'attaquant pollue suffisamment pour dégrader la qualité globale. Plus visible (la métrique se dégrade) mais utilisé en sabotage interne. Voir ByteDance sabotage modèles insider.

Comment je le détecte en pratique

Côté pipeline (préventif)

1. Provenance dataset : chaque source identifiée, hash vérifié, pas de dataset "trouvé". Voir pipeline MLOps sécurisé.
2. Statistiques par batch : détection d'anomalies dans la distribution de chaque batch. Un batch avec une distribution très éloignée de la baseline = à inspecter.
3. Échantillonnage manuel : revue humaine d'un échantillon random de chaque dataset, surtout pour les datasets externes ou crowdsourcés.
4. Tests adversariaux post-entraînement : avant de promouvoir un modèle, tester avec des inputs piégés connus.

Côté production (détectif)

1. Monitoring de drift : la distribution des inputs/outputs change ? Le pattern de confiance ? Si oui, ça peut être du drift métier mais aussi une attaque qui exploite une backdoor.
2. Tests canaries : faire passer périodiquement des inputs de contrôle dont vous connaissez l'output attendu.
3. Logging structuré des prédictions avec input hash + version modèle, pour pouvoir investiguer rétrospectivement.

Model leakage — ce que c'est en pratique

Deux familles :

Memorization leakage

Le modèle "se souvient" de données d'entraînement et peut les régurgiter. Cas connus : LLMs qui sortent des emails, des numéros de téléphone, voire des bouts de code propriétaire vus à l'entraînement. Risque RGPD massif si données personnelles.

Model extraction

Un attaquant interroge votre API modèle de façon systématique pour reconstruire une version du modèle (ou voler les poids). Particulièrement crédible sur les modèles de scoring qui exposent des décisions structurées.

Comment je le détecte en pratique

Memorization leakage

1. Tests memorization : prompts spécifiques qui essaient de faire ressortir des données d'entraînement (prompts "complete this email", "the user with ID X has password..."). Sur un échantillon de PII connues du training set.
2. Output filtering : détecter les patterns PII dans les outputs (regex emails, téléphones, numéros sécurité sociale) et bloquer ou masquer.
3. Différential privacy côté entraînement quand applicable, surtout pour les fine-tunes sur données personnelles.

Model extraction

1. Rate limiting sur l'endpoint, par utilisateur et par IP.
2. Détection de patterns d'extraction : volume très élevé de requêtes diverses depuis un utilisateur, requêtes systématiques sur la grille de l'espace d'inputs.
3. Watermarking des outputs du modèle (par exemple, biais statistique sur certains tokens) pour pouvoir prouver l'extraction si un modèle clone apparaît.
4. Output perturbation : ajouter du bruit contrôlé sur les scores pour rendre l'extraction plus coûteuse.

Les pièges que je vois revenir

Croire que ça ne nous concerne pas

"On utilise un LLM provider, pas nos modèles". En vrai si vous fine-tunez, vous avez du risque memorization. Si vous faites du RAG, vous avez du risque output leakage sur les documents internes (un autre utilisateur peut récupérer des données qui ne lui sont pas destinées). Le risque n'est jamais zéro.

Détecter seulement avec les outils du provider

Le LLM provider a son content filter. Mais il ne connaît pas votre liste de PII internes. Vous devez ajouter une couche output filtering qui sait que clientId=42 ne doit jamais sortir vers le client id=43.

Pas de tests memorization en CI

Une suite de tests qui essaie de faire ressortir des données mémorisées, à passer à chaque fine-tune. Sinon vous découvrez le leak quand un utilisateur le signale.

Ne pas avoir de plan extraction

Si quelqu'un extrait votre modèle, vous le détectez comment ? Si pas de plan, c'est non. Comptez au minimum : monitoring volume + alerting sur patterns d'extraction + capacité de bloquer rapidement une clé API.

Mon avis en 1 ligne

Data poisoning et model leakage ne se détectent pas avec un seul outil. Il faut une combinaison : contrôles préventifs au pipeline (provenance, scan) + détectifs en prod (drift, canaries, output filtering, rate limit). Compter 4-8 semaines pour atteindre un niveau défendable sur les deux, avec une équipe ML + sécu engagée. Et tester l'efficacité par red teaming, pas par déclaration. Voir AI red teaming programme.