Data poisoning means someone tampers with a model's training data before the model learns its skills: changing the labels of a batch of examples, mixing in examples carrying a hidden trigger, or deleting key examples, so the model learns the wrong associations. It is not the same as tricking a model after deployment — the tampering happens before training, and the defenses are completely different. Most wrong answers ordinary users run into are not data poisoning, and not every model mistake should be filed under this term.
Three common techniques, each damages differently
- Flipping labels. The labels of some examples are swapped — for instance, marking malicious traffic as benign — so the model learns to treat danger as safety, and a check that only looks at the examples' surface will hardly notice.
- Planting a backdoor. A batch of examples is given an inconspicuous trigger mark and uniformly labeled with the target class. The model behaves normally until it meets the trigger, and then it goes wrong exactly as the attacker intended. This is the hardest form to detect.
- Clean-label poisoning. The examples and their labels both look compliant, but the content has been carefully altered to slip past simple data checks and quietly push the model's decision boundary off course. All three techniques work by hiding among normal data; the poisoned share does not need to be large — what matters is whether the examples sit in the right place.
It is not the same as prompt injection or data contamination
| Phenomenon | When it happens | Core difference |
|---|---|---|
| Data poisoning | Before training | Changes the data the model learns from, so what it learns changes |
| Prompt injection | During use | Changes the text handed to the model; the model itself is unchanged |
| Data contamination | Mostly unintentional | Training data contains errors or duplicates, with no one deliberately causing harm |
Keeping these three apart points to the right response: prompt injection is handled with input filtering and tighter permissions, contamination with cleaning and deduplication, and data poisoning only by going back to the data source itself.
For people who build models or manage data, four practices help: record where data came from — who supplied it, which batch, what was changed — so it can all be traced; do not check samples only against overall accuracy, but also against behavior under trigger conditions; keep a clean validation set aside specifically for suspicious categories; and when one category starts failing in clusters, isolate that batch of data and investigate it before tuning parameters. When someone says a model has been poisoned, first ask three questions: is the evidence in the training data, or only in one conversation? Does it affect one kind of input, or is everything worse? Is there a reproducible trigger condition? If those cannot be answered, treat it as an ordinary fault or a data-quality problem for now, and do not jump to conclusions.
