OWASP LLM04 does not map to any compliance regime itself, but its mitigations line up with EU AI Act Articles 10 and 15, which cover data governance and resistance to data poisoning. Keep provenance records, dataset versioning, vendor checks and red team results as the evidence a reviewer would ask for.
What does LLM04 say?
OWASP's 2025 entry defines data poisoning as manipulation of pre training, fine tuning or embedding data to introduce vulnerabilities, backdoors or biases. It calls it an integrity attack, with external data sources carrying the highest risk. It also warns that shared model repositories can carry malicious code, such as malware embedded through malicious pickling, and that backdoors may leave behavior untouched until a trigger activates them, which makes them hard to detect.
The mitigations it lists include provenance tracking with CycloneDX or ML-BOM, vendor and output validation, sandboxing of unverified data with anomaly detection, data version control, targeted fine tuning datasets, infrastructure controls on data access, keeping user supplied information in a vector database, red team testing, monitoring training loss and model behavior, and retrieval grounding at inference time.
Does the page map to a framework?
Not to compliance regimes. The page has a related frameworks section that names MITRE ATLAS technique AML.T0018, Backdoor ML Model, with the Tay poisoning case study, and the NIST AI Risk Management Framework for strategies for ensuring AI integrity, with no control level mapping. Everything below that links to regulation is our reading, labeled as such.
How does it line up with the EU AI Act?
Two articles are the closest fits, and both apply to high risk AI systems.
Article 10, data and data governance. Training, validation and testing data sets must be subject to data governance practices suited to the intended purpose. These concern design choices, data collection processes and the origin of data, examination for biases likely to affect health, safety or fundamental rights, and measures to detect, prevent and mitigate those biases. Provenance records and dataset versioning from the OWASP list are natural evidence for the origin of data.
Article 15, accuracy, robustness and cybersecurity. The article says technical solutions for AI specific vulnerabilities shall include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set (data poisoning) or pre trained components used in training (model poisoning), and inputs designed to make the model err. Red team testing and training monitoring are the matching evidence.
Timing matters. Article 15 applies from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, and the European Commission's page says the high risk dates were extended through the AI Omnibus package. Whether your system is high risk is a legal question, so confirm with counsel.
What evidence would a reviewer want?
Think in artifacts, one per OWASP mitigation:
| Mitigation | Evidence to keep |
|---|---|
| Provenance tracking | A CycloneDX or ML-BOM record of datasets and models, with sources |
| Vendor validation | Due diligence file for each data and model supplier |
| Data versioning | Dataset version history and change log |
| Isolation and filtering | Pipeline design showing where unverified data is quarantined |
| Red teaming | Test plan, results and fixes, dated |
| Monitoring | Training run metrics and behavior baselines |
Where does the software supply chain come in?
A model is also a downloaded artifact. OWASP notes shared repositories can hold malicious code, so the model file belongs in your inventory the same way a library does. Safeguard's SBOM and scanning work can help you inventory the code side. Any tool is as good as the records you keep around it, and none of this makes a system compliant or certified.
What to do
- List every dataset and pre trained model you use, with source, version and date obtained.
- Record them in a machine readable bill of materials.
- Add a vendor check for each external data or model supplier.
- Put datasets under version control and review changes.
- Define a red team exercise for poisoning and backdoor triggers, and run it before each major release.
- Capture baseline training and evaluation metrics, and alert on drift.
- Ask counsel whether the AI Act's high risk rules apply, and map your evidence to Articles 10 and 15 if so.
Quick check
Is data poisoning limited to training time?
No. OWASP covers pre training, fine tuning and embedding data, and it also lists prompt injection that inserts misleading data where filtering is weak.
Does following OWASP LLM04 make a system AI Act compliant?
No. The page does not map itself to regulation. It is useful input, and your legal review decides what the law requires.
Sources
- OWASP GenAI: LLM04:2025 Data and Model Poisoning, fetched 18 October 2026
- EU AI Act, Article 10: Data and data governance, fetched 18 October 2026
- EU AI Act, Article 15: Accuracy, robustness and cybersecurity, fetched 18 October 2026
- European Commission: AI Act regulatory framework, fetched 18 October 2026
Last reviewed: 18 October 2026.
