Data Poisoning
A security threat in which an attacker deliberately introduces corrupted, misleading, or malicious data into a model's training or retrieval sources to manipulate its future outputs.
What It Is
Data poisoning differs from an ordinary data quality issue in that it’s intentional and adversarial, not accidental.
It can target training data, corrupting what a model learns, or the retrieval sources a RAG system pulls from at query time, meaning a system can be vulnerable even without ever being retrained.
The goal is typically to manipulate a specific downstream output: a recommendation, a price, an approval decision.
In B2B Commerce Context
In B2B commerce, any AI feature that ingests external, third-party, or user-submitted data creates a potential entry point for this kind of manipulation.
A practical example
This risk is often invisible until an audit or an anomaly in observability data surfaces it, since a poisoned system doesn’t necessarily behave erratically overall, just wrong in a targeted way.
When You Need It
- An AI feature ingests any external, third-party, or user-generated data source.
- You're using RAG against sources that aren't fully controlled internally.
- You're defining what enterprise AI governance and guardrails need to check for.
- You want to close a gap that guardrails alone don't cover.
Validate external data sources before they feed any AI system making financial or customer-facing decisions.
What It Is Not
- Data poisoning is not the same as an ordinary data quality bug, it is adversarial and intentional, not accidental.
- It is not limited to training time. RAG systems are vulnerable at retrieval time too, without any retraining involved.
- It is not solved by guardrails alone. Guardrails constrain what an agent can do; they don't validate whether the data it's reasoning over is trustworthy.
Comparison
| Attribute | Data Poisoning | Ordinary Data Quality Issue |
|---|---|---|
| Intent | Deliberate and adversarial | Accidental |
| Where it can occur | Training data or retrieval sources | Anywhere data is entered or imported |
| Detection difficulty | Often targeted and hard to spot | Usually visible through normal QA |
| Mitigation | Source validation, governance, observability | Standard data cleaning and validation |
See also
Ready to see it in action?
Book a demo of OroCommerce
See how agentic workflows fit into complex B2B commerce, with a walkthrough tailored to your stack.