Aller au contenu principal
B81§5.6ESécurité applicative et exploitationÉLEVÉBGrade B

Empoisonnement hors RAG (données, fine-tuning, modèle)

Sécurité

Comprendre

Ce que c'est

Au-delà du RAG, l’empoisonnement peut viser les données de pré-entraînement, les jeux de fine-tuning ou les artefacts de modèle : portes dérobées et déclencheurs cachés.

Pourquoi ça arrive

Un jeu de données ou un modèle tiers non vérifié peut contenir des exemples piégés qui s’activent sur un déclencheur précis.

En situation
Vous demandez :
Fine-tune le modèle sur ce jeu de données récupéré en ligne.
Il répond :
fine-tuning sur des données non validées, introduisant un comportement piégé
Il devrait :
Données validées, provenance vérifiée, tests de porte dérobée avant déploiement.

Tester

Provenance
Lecture. Pour tout modèle affiné, tout jeu de données d’entraînement, tout modèle tiers open-weight : d’où vient-il ? Qui l’a produit ? Sur quoi a-t-il été entraîné ? Est-il signé et vérifiable ? Réussite = chaque source est traçable et vérifiée. Un modèle ou un jeu de données récupéré sans provenance vérifiable est une dépendance non maîtrisée — le vecteur que documente la fiche.
Ligne de base avant / après
Lecture. Avant tout affinage ou changement de modèle, constituez un lot de canaris (B74) et consignez les verdicts. Rejouez-le après. Réussite = les comportements attendus sont identiques avant et après. Une divergence sur des entrées ordinaires est le signal — un comportement qui change sans raison documentée doit être investigué, pas ignoré.
Sensibilité aux entrées rares
Lecture. Banc. Sur votre lot de test, vérifiez qu’aucune entrée ordinaire mais inhabituelle ne produit un comportement aberrant et reproductible. Réussite = le comportement reste cohérent. Un basculement net et reproductible sur une entrée précise, non documenté, justifie une escalade — sans chercher à en produire d’autres.
Gouvernance
Lecture. Banc et processus. Qui a le droit de fournir un modèle ou un jeu de données à votre chaîne ? Cette question est le vrai garde-fou.
Échec si

un modèle change de comportement sur un déclencheur précis non documenté ; un modèle ou un jeu de données est employé sans provenance vérifiable ; aucune ligne de base ne permet de détecter le changement.

Pour aller plus loin

Le remède est en amont : provenance vérifiée, versions épinglées, ligne de base consignée. On ne détecte pas un empoisonnement en le cherchant à l’aveugle — on le détecte parce qu’on savait à quoi ressemblait le comportement normal.

Variante ingénierie

Modèles affinés sur mesure, modèles open-weight récupérés, jeux de données achetés : exigez la provenance, comme vous l’exigez d’un lot de matière première.

Prévenir

À coller dans le prompt système
N’entraîne ou n’ajuste que sur des données à provenance vérifiée ; teste les portes dérobées avant tout déploiement.
Aussi
  • validation des jeux de données.
  • provenance du fine-tuning.
  • tests de backdoor.
  • séparation train / eval.
  • Contrôle résiduel : la propreté du RAG ne garantit pas celle du modèle ni de ses données d’entraînement.

Référence

Source principale

Preuve B (préprint — pas encore relu par les pairs) — Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples (Anthropic, UK AI Security Institute, Alan Turing Institute) arxiv.org/abs/2510.07192. Source d’appui : OWASP Top 10 for LLM Applications 2025 — LLM04 (S-40) genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning.

Ce qu’elle établit — 250 documents empoisonnés suffisent à installer une porte dérobée dans des modèles de 600 M à 13 Md de paramètres : le nombre requis est quasi constant, et non proportionnel au volume de données propres. Il s’agit d’empoisonnement des données de PRÉ-ENTRAÎNEMENT — à ne pas confondre avec l’empoisonnement d’une base RAG (B40).

Grade de preuve
BGrade B
Contrôles & tests
ERER-72 Validation + provenance des données d’entraînement / fine-tuningER-73 Tests de porte dérobée avant déploiementER-34 Contrôles anti-empoisonnement du RAG (cf. fiche 3.14)