Short answer. Data poisoning is a cyberattack that corrupts the data an AI model learns from, so the model makes the wrong decisions on purpose. The EU AI Act names it directly: Article 15 requires high-risk AI systems to resist attacks that manipulate the training data set. Research shows that corrupting as little as 1% of a training set can measurably degrade a fraud-detection model, and the poisoned records often pass standard validation because they look legitimate.
An AI model is only as trustworthy as the data it trained on. Data poisoning targets that dependency. An attacker inserts, edits, or mislabels a small number of training records so the finished model carries a flaw the attacker chose. The model still scores well on normal tests. The damage shows up only when the attacker triggers it.
In a regulated setting the consequences are concrete. A poisoned credit-scoring model can be taught to approve a specific class of fraudulent applications. A fraud-detection model can be trained to wave through one transaction pattern. An insurance-pricing model can be skewed toward a mispriced segment. Because these systems make thousands of automated decisions, one hidden flaw scales fast.
Typical attack surfaces in financial services and insurance include:
The EU AI Act treats robustness against poisoning as a legal requirement, not a best practice. Article 15(5) states that technical solutions for high-risk AI systems must, where appropriate, prevent, detect, respond to, and control attacks that manipulate the training data set (data poisoning) or pre-trained components (model poisoning), alongside adversarial examples and confidentiality attacks. Annex III designates credit scoring, creditworthiness assessment, and life and health insurance pricing as high-risk use cases, so most core AI in a bank or insurer sits inside this obligation. The high-risk requirements apply from 2 August 2026, supervised by sector regulators including the EBA, EIOPA, and ESMA.
DORA reinforces the point from the operational side. In force for financial entities since 17 January 2025, it requires firms to protect the integrity of the data and ICT systems that support critical functions, and to manage risk from third-party providers. A training pipeline that ingests an unverified external dataset is exactly the kind of third-party data path DORA expects a bank to govern. Poisoning is therefore both an AI-safety failure and an operational-resilience failure at the same time.
Data poisoning corrupts training data so a model makes attacker-chosen mistakes, and as little as 1% of a dataset can degrade a fraud model.
An attacker first needs a way to influence the training data. That access can be direct, such as a compromised internal pipeline, or indirect, such as contributing to a public dataset the target later scrapes. The attacker then crafts poisoned samples that shift the model’s behavior toward a chosen goal while staying invisible in aggregate statistics.
The stealth is the point. NIST’s 2025 taxonomy describes clean-label poisoning, where the malicious records keep correct-looking labels and slip past validation that only checks for obvious mismatches. A 2025 study of large language models found that a fixed, small number of malicious documents could implant a hidden backdoor regardless of how large the model was, which means scale alone does not dilute the threat.
NIST AI 100-2e2025 groups the attacks by the attacker’s goal. Availability attacks aim to degrade the model broadly, raising error rates until the system becomes unreliable. Targeted or backdoor attacks are narrower and more dangerous: the model behaves normally until it sees a specific trigger, then produces the attacker’s chosen output. A backdoored transaction monitor, for example, flags everything correctly except the one account label the attacker planted.
A second axis is where the poisoning lands. Training-data poisoning corrupts the labelled examples a model learns from. Model poisoning corrupts a pre-trained component or checkpoint reused downstream. Both are named in the EU AI Act, and both matter to financial firms that fine-tune vendor models rather than training from scratch.
The two attacks hit different stages. Prompt injection manipulates a model at inference time, hiding instructions in the text a live model reads, and it changes one session without altering the model itself. Data poisoning manipulates the model during training or retraining, so the flaw is baked into the weights and affects every future decision until the model is retrained on clean data.
The defenses differ accordingly. Prompt injection is countered with input filtering, output checks, and tight tool permissions at runtime. Poisoning is countered earlier, through data provenance, sanitization, and validation before and during training. A firm that has hardened its live prompts can still ship a model that was poisoned months before deployment, which is why both controls are needed.
There is no single control that removes the risk. Defense is layered and starts with knowing where every training record came from. Practical measures NIST and EU AI Act guidance point to include data provenance and signing, so every dataset has a verifiable origin; statistical anomaly detection and data sanitization to spot and remove outliers before training; and holdout and trigger testing that probes a trained model for hidden backdoors before it reaches production.
Governance closes the loop. Access controls limit who can touch a training pipeline, versioned datasets make tampering auditable, and continuous monitoring catches accuracy drift that a slow-acting poison would cause. For high-risk systems the EU AI Act already requires logging and human oversight, so a bank that builds poisoning defenses is also building the evidence it needs for a conformity assessment.
Poisoning defense is a systems problem, not a model tweak, and it belongs in the architecture from the first pipeline. Ableneo shipped 34 production AI projects in 2025, 94% of them using large language models, for clients that include ČSOB, Erste, and UNIQA, all firms that live inside the same EU AI Act and DORA obligations described here. That work is where data provenance, validation, and monitoring stop being slide-ware and become running controls. You can see how this fits the wider governance picture in Ableneo’s AI transformation FAQ, which connects poisoning to the accuracy, robustness, and oversight requirements a regulated deployment has to meet.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.