Training Data Poisoning
The Model Learned from Three Years of Data. One Year Was Labelled Wrong. The Model Learned That Too.
7 min read · 13 June 2026 · AI governance
A financial services company deployed an AI-powered fraud detection model from a specialised vendor. The model had been trained on a large corpus of historical transaction data, with each transaction labelled as fraudulent or legitimate based on the outcome of the fraud investigation process at the time. The model's performance metrics were strong , high detection rate, low false positive rate , and the vendor had validated the model against held-out test data before deployment. What neither the vendor nor the customer had analysed was the composition of the training data across time. During an eighteen-month period two years before the training data was collected, a sophisticated fraud ring had been operating in the training data's source population using a specific transaction pattern , small, frequent transactions to multiple new payees, initiated from new devices with consistent timing patterns. During that eighteen-month period, the fraud ring had not been identified, and their transactions had been labelled as legitimate in the investigation workflow. The training corpus included those eighteen months. The model was trained to treat the fraud ring's pattern as legitimate , because during training, those exact patterns were labelled legitimate. When the model was deployed, the same fraud ring's patterns , using the same technique with minor variations , were classified as legitimate by the model with high confidence. The model was not malfunctioning. It was performing exactly as its training had directed. The poisoning was in the labels, not in any deliberate manipulation of the training data.
What is Training Data Poisoning, Really?
Training data poisoning is the contamination of a machine learning model's training dataset in ways that cause the model to learn incorrect, biased, or deliberately manipulated patterns , resulting in a model that behaves incorrectly in predictable ways that benefit an attacker or reflect the structural errors in the training corpus. Training data poisoning can be deliberate , an attacker who has access to the training pipeline introduces malicious examples that cause the model to misclassify specific inputs , or it can be structural, arising from historical label errors, sampling biases, or periods of undetected adversarial activity in the data the training corpus was drawn from.
The label poisoning problem is the most common and least understood form of training data contamination. Machine learning models learn from labelled examples , each training example is associated with a ground truth label that tells the model what the correct output should be. When those labels are wrong , because the labelling process made errors, because the ground truth was not known at the time of labelling, or because adversarial activity during the labelling period was not detected , the model learns from the wrong labels. It becomes very good at producing the wrong outputs for the specific inputs whose labels were incorrect. This is not a model failure in the traditional sense , the model is doing exactly what its training directed. The training direction was wrong.
The temporal poisoning problem is the supply chain specific dimension. AI models trained on historical operational data , fraud patterns, security events, network behaviour, customer activity , inherit the errors and blind spots of the historical period. If attackers were successfully evading detection during part of the training period, the training data includes their activity as negative examples , legitimate activity in a fraud context, benign in a security context. The model learns to recognise these patterns as legitimate because that is how they were labelled during training. Future activity using the same patterns will be classified the same way.
The deliberate poisoning attack is the adversarial dimension. A threat actor with access to the vendor's training pipeline , through a compromised data source, a supply chain compromise of a data provider, or direct access to the training infrastructure , can deliberately introduce crafted examples that cause the model to misclassify specific inputs. A classifier poisoned to misclassify specific transaction patterns as legitimate will miss those transactions when deployed. A security model poisoned to classify specific malware signatures as benign will fail to detect that malware in production. The attack is embedded in the training data and manifests in the model's production behaviour.
The dataset composition opacity problem is what makes training data poisoning particularly difficult to assess in vendor AI products. The training corpus for a commercial AI product is typically proprietary , vendors do not share their complete training datasets with customers. The customer must assess training data quality from the vendor's documentation, training methodology descriptions, and validation methodology rather than from direct inspection of the corpus. This creates an assessment gap: the customer cannot verify that the training data is free from the specific types of contamination that would cause the model to fail in their use case.
Why this matters
Training data poisoning matters for TPRM because AI products that perform well on vendor-supplied test metrics may still contain systematic blind spots caused by contaminated training data. A fraud model that misses a specific fraud pattern because that pattern was mislabelled during its training period will continue to miss that pattern in production , with high confidence , regardless of how well it performs on its validation benchmark.
Where most teams get this wrong
The most consistent failure is accepting model validation metrics as evidence of training data quality. Validation performance measures how well the model learned from its training data. If the training data was poisoned, the validation data from the same corpus is likely poisoned the same way, and validation performance is high on the same errors the model has learned.
- Validation metrics accepted as training data quality evidence
- Temporal analysis of training corpus not conducted , which periods and what events
- Label quality assessment not requested
- Adversarial poisoning testing not conducted
- Blind spot testing in production context not performed
What good looks like
Mature AI product assessments include training data quality documentation, temporal analysis of training corpus composition, independent validation against data from outside the training period, and adversarial poisoning testing that specifically probes for the blind spots most relevant to the customer's use case.
- Training data quality documentation , sources, labelling process, known gaps
- Temporal composition analysis , training period coverage and known events
- Out-of-distribution validation , testing against data from different periods and sources
- Adversarial blind spot testing , testing model against known adversarial patterns
- Continuous performance monitoring , production performance vs validation benchmark
Tooling
AI Safety and Red-Teaming , IBM Adversarial Robustness Toolbox, CleanLab for label quality
Label quality assessment tools like CleanLab identify likely label errors in training datasets by detecting examples where the model's confidence conflicts with the assigned label. For TPRM practitioners, asking whether the vendor has used label quality assessment tools to identify and remediate likely label errors in their training corpus provides a specific data quality question.
Governance challenges
The governance challenge with training data poisoning is the retrospective assessment problem. Training data that was assembled from historical operational data cannot be retroactively verified to be free from the structural errors that the historical operational processes contained. The governance resolution is continuous production performance monitoring , detecting model behaviour drift that indicates the model is encountering inputs that its training did not prepare it for.
- Request training data quality documentation and labelling process description
- Ask about temporal composition of training corpus , which periods, what events occurred
- Ask about label quality assessment methodology
- Ask about adversarial poisoning testing
- Require production performance monitoring with drift detection
If you are a small team
For any AI vendor whose product makes classification decisions with material consequences , fraud, security alerts, credit, medical , ask one temporal question: does your training corpus include periods when the patterns you are trying to detect were successfully evading detection? For fraud models, this means periods of undetected fraud. For security models, this means periods of undetected attacks. That question reveals whether the training data inherits the blind spots of the historical detection process that generated the labels.
- Ask whether training corpus includes periods of undetected adversarial activity
- Ask about label quality assessment methodology
- Ask about adversarial blind spot testing
- Require production performance monitoring
What to require
Ask directly:
"Does your training corpus include historical periods when the patterns you are trained to detect were successfully evading detection , and how have you assessed and remediated label quality in those periods? Has the model been tested specifically for blind spots caused by historical label errors?"
Expect as evidence
- Training corpus temporal composition documentation
- Label quality assessment methodology and results
- Adversarial blind spot testing results
- Production performance monitoring with drift detection
A vendor who provides strong validation metrics should be asked about the composition and label quality of the training corpus those metrics were validated against. Strong performance on poisoned data validates performance on poison, not performance on clean ground truth.
How to evidence it
- Training data quality assessment records
- Temporal composition analysis
- Adversarial blind spot testing
- Production performance monitoring records
Key Takeaway
The fraud model performed well. The validation metrics were strong. The training data included eighteen months of correctly-labelled legitimate transactions that were actually undetected fraud. The model learned to classify that fraud as legitimate with high confidence. The validation confirmed the model is consistent with its training. The training was consistent with a labelling process that had an eighteen-month blind spot. Training data poisoning through historical label errors is the form of contamination that cannot be detected by validation performance alone , because the validation data has the same errors as the training data. Temporal analysis, label quality assessment, and adversarial blind spot testing are the tools that reveal the errors that validation performance hides.
Speak to It™
The term you nodded along to, explained in ninety seconds, so you can speak to it professionally. It is how most readers find these articles.
Join the Association