Poisoned at the Source: Securing Nigeria’s AI Supply Chain Against Data Poisoning

Nigerian technology businesses already understand guardrails. Fintechs build transaction limits, velocity checks, and fraud detection into their payment rails. Banks apply identity and onboarding checks. Health technology platforms restrict access to patient records. The familiar approach is to build a system, then place controls around it to detect misuse before harm reaches the user.

AI encourages the same instinct. Teams add content filters, moderation layers, and responsible AI policies. Those controls matter, but many operate at the input or output layer. Data poisoning starts earlier. It targets the information used to pre-train, fine-tune, align or otherwise adapt a model. By the time the model is deployed, the harmful pattern may already be embedded in its behaviour.

The central governance point: data poisoning is not only a model risk. It is also a data governance, cybersecurity, procurement and legal risk.

1. What data poisoning is, and what it is not

Data poisoning is an adversarial training-stage attack. It occurs when an attacker inserts or modifies training samples to influence the resulting model. Model poisoning is related but distinct: it involves tampering with the model or its parameters rather than the training data itself.

Poor data quality should not be mislabeled as poisoning. Inaccurate, stale, unrepresentative or badly labelled data can also distort model outputs, but that is better described as data contamination, bias or a data quality failure unless there is deliberate adversarial manipulation. The distinction matters because the investigation, legal analysis and remediation will differ.

Poisoning attacks are commonly understood by their objective:

• Availability poisoning seeks to degrade the model broadly so that it becomes less accurate or useful.
• Targeted integrity poisoning seeks to change the model’s behaviour on selected examples, users or subpopulations while leaving ordinary performance largely intact.
• Backdoor poisoning implants a trigger that causes attacker-selected behaviour when the trigger appears. The trigger may be a visual pattern, sound, word, phrase or another feature the model has learned to associate with a particular response.

A clean-label attack is not a separate objective. It describes an attacker’s capability: the attacker can manipulate training examples without changing their visible labels, making the poisoned samples appear legitimate during routine review.

2. How poisoning enters the AI pipeline

Data poisoning may enter at several points in the AI lifecycle, including pre-training, fine-tuning, instruction tuning and the creation of embedding or retrieval data. The risk is not limited to organisations that train foundation models. A business can inherit poisoned behaviour through a third-party model, public dataset, model repository, outsourced labelling process, data broker, plug-in or fine-tuning vendor.

1. Label modification attack: Here, the attacker deliberately changes correct labels to incorrect ones. In a fintech context, this could involve marking fraudulent transactions as “legitimate.” As a result, the model learns to treat fraudulent activity as normal and may approve similar transactions in the future.
2. Data Injection attack: This technique involves adding malicious or misleading data points to the training dataset. The injected data skews the model’s decision boundaries, causing it to make inaccurate or manipulated predictions.
3. Clean-label attack: Attackers subtly modify training data without changing its labels, so it appears valid but embeds hidden patterns that influence model behaviour. For example, a loan-scoring model can be trained on such data and develop a covert bias, disproportionately rejecting applicants from certain regions while appearing to operate normally.
4. Backdoor (Trojan) attacks: Backdoor attacks embed subtle, hard-to-detect triggers (e.g., inaudible audio or imperceptible image markers) into AI systems. Models operate normally until the trigger appears, then switch behaviour to advance the attacker’s objective. Risk is particularly high in open-source ecosystems, where access to models and training pipelines is less restricted.
5. Compromised model artefacts. Where an organisation adopts a pre-trained model or model weights from a third party, the risk may be model poisoning rather than data poisoning. The governance response should cover both because the business impact can be similar.

3. Why Data Poisoning Can Remain Hidden

Data poisoning is difficult to detect because success does not always require an obvious system failure. A targeted attack may affect only a narrow class of inputs, while aggregate accuracy and ordinary test results remain acceptable. Some attacks can be mounted with a relatively small portion of a large dataset. Backdoors may also remain dormant until a specific trigger is presented.

Complex supply chains make attribution harder. Training data may be scraped, licensed, purchased, labelled by contractors, transformed through several pipelines and combined with external models. Without reliable lineage records, it may be difficult to identify when a compromised sample entered the system or which downstream models are affected.

Interpretability is another constraint, but it should be stated carefully. Not every AI model is a complete “black box”. However, complex models can make it difficult to trace a particular output to a specific training example or hidden representation. Poor decisions may, therefore, be mistaken for model drift, ordinary error or an edge case unless the organisation tests specifically for poisoning and backdoors.

4. What Nigerian Law and Policy Currently Require

As at July 2026, Nigeria does not have a comprehensive standalone AI statute in force. Official legislative records continue to describe AI-specific measures as bills or legislative proposals. That does not mean AI deployment remains unregulated. Existing data protection, cybersecurity, consumer protection, sectoral and contractual rules may apply depending on the system and use case.

The Nigeria Data Protection Act 2023

Where personal data is used in an AI system, the Nigeria Data Protection Act 2023 (NDPA) is central. Section 24 requires personal data to be accurate, complete and not misleading, and to be processed with appropriate security. Sections 24 and 39 also require technical and organisational measures [TOMs] that protect confidentiality, integrity and availability [CIA]. Those duties support controls over dataset provenance, access, alteration, storage and validation.

Section 37 addresses automated decisions. A data subject has the right not to be subject to a decision based solely on automated processing, including profiling, where it produces legal or similarly significant effects. The Act contains exceptions, but requires safeguards such as human intervention, an opportunity to express a view and the ability to contest the decision.

The GAID 2025

The Nigeria Data Protection Act General Application and Implementation Directive 2025 (GAID) strengthens the operational compliance framework. Article 28 requires a Data Privacy Impact Assessment where processing is likely to create high risk and states that a DPIA is mandatory and must be filed with the Nigeria Data Protection Commission in listed circumstances, including profiling or scoring, automated decisions with legal or similarly significant effects, systematic monitoring, sensitive data, certain innovative technologies, digital financial services, healthcare and e-commerce.

The GAID classifies data controllers and processors of major importance into Ultra-High, Extra-High and Ordinary-High levels. It does not classify AI systems themselves. It also requires controllers and processors of major importance to submit annual Compliance Audit Returns. These obligations should, therefore, be assessed by reference to the organisation and the nature of its processing activities, rather than assumed to apply automatically to every large AI model.

Cross-border data transfers are not governed by a simple choice between consent and Standard Contractual Clauses [SCCs]. Under sections 41 to 43 of the NDPA, a transfer must be supported by an adequate-protection mechanism or another condition permitted by the Act. Consent may justify a transfer in certain circumstances, while contractual clauses may form part of an adequacy mechanism, but neither is the exclusive basis for transferring personal data abroad.

The National Artificial Intelligence Strategy 2025

Nigeria’s National Artificial Intelligence Strategy 2025 is policy rather than legislation. It identifies accuracy, bias, transparency and governance as significant AI risk factors, and highlights data governance, versioned datasets, testing, monitoring, documentation and human oversight as useful controls. These principles align closely with the controls needed to reduce poisoning risk.

5. A Practical Control Framework for Organisations

The most effective approach is to use several layers of control. No single filter, warranty or technical test can eliminate data-poisoning risk. Organisations should, therefore, connect governance, procurement, data management, cybersecurity, privacy and incident response.

• Maintain an AI and data inventory: Keep a record of each AI system, its business owner, purpose, decision-making impact, model version, datasets, vendors, deployment environment and applicable regulator. Note whether the system is developed internally, fine-tuned, retrieval-augmented or provided as a managed service. The organisation should also classify the data involved, including personal data, confidential information, licensed content and publicly sourced material.

• Assess vendors before contracting: Review the source of the vendor’s training and fine-tuning data, model weights, security controls, subcontractors and data-validation processes. Ask for evidence, not just policy statements. This may include data-lineage records, model documentation, assurance reports, test results, change logs and incident history. The organisation should also confirm whether the vendor can trace affected data and models, reverse an update and support an investigation where poisoning is suspected.

• Convert due diligence into enforceable contract terms: Contracts should contain warranties on data and model provenance, lawful sourcing and rights to use the relevant content. They should also include obligations on security, access control, data validation and integrity. Other important terms include audit rights, prompt incident notification, disclosure of material changes, cooperation with investigations, evidence preservation, remediation, rollback, replacement, data return or deletion, and a clear allocation of liability.

• Secure the data and model pipeline: Restrict access through role-based permissions and separation of duties. Record and review material changes to datasets, labels, model weights and training settings. Maintain provenance records, version control, integrity checks and clear links between each data version and model release. Data should be validated, deduplicated and reviewed before use. Testing should also cover high-impact users, vulnerable groups, unusual cases and possible trigger patterns.

• Monitor system behaviour, not only overall accuracy: Set baseline performance and risk indicators for the system as a whole and for important user groups or use cases. Monitor changes in inputs, labels, outputs, refusal patterns and decisions. Establish clear thresholds for escalation, suspension and rollback. Testing should be repeated after fine-tuning, vendor updates, new data ingestion or other material changes.

• Prepare a data-poisoning incident response plan: Where poisoning is suspected, isolate the affected datasets and model versions, preserve logs, stop further use and identify all downstream systems that relied on them. The organisation should also assess whether the incident involves unauthorised processing, alteration, loss or disclosure of personal data under the NDPA. Depending on the evidence, remediation may involve removing suspect data, sanitising datasets, fine-tuning, pruning, retraining, rolling back or replacing the model. Where individuals may have been affected, relevant decisions should be reviewed and appropriate human reconsideration or redress provided.
• Assign clear responsibility: Senior management should approve high-impact AI uses and accept any remaining risk. Legal, privacy, cybersecurity, procurement, data science, internal audit and business teams should follow a single escalation process. Staff should also be trained to recognise that AI supply-chain risks can enter through data, models, repositories, vendors and system updates, not only through malicious prompts after deployment.

6. The Defence Must Start Upstream

Output filters remain important, but they cannot replace reliable data, traceable model components and careful procurement. Data poisoning takes advantage of gaps in the AI supply chain. As the chain becomes longer and less transparent, it becomes harder to determine what was changed, when it was changed and which systems may have inherited the problem.

Organisations should, therefore, treat their AI data and model supply chains as critical infrastructure. The same level of care applied to identity checks, payment systems and sensitive records should also apply to the data and model components used to build AI systems. Because the risk begins upstream, effective governance must begin there as well.