How Nigerian Businesses Should Protect Data When Using AI

Most data incidents involving AI in Nigerian businesses are not sophisticated attacks. They are ordinary working moments: an accountant pasting a client's full ledger into a free chatbot to reformat it, a sales manager uploading a signed contract to summarise it, a developer pasting production database output while debugging.
Each of these is a person trying to do their job faster. None intended to send company or customer data to a third party, and in most cases nobody told them not to.
This article is the operational playbook for preventing that. Companion articles cover what customers are entitled to expect, the security threats against AI systems, and how the Nigeria Data Protection Act 2023 applies. Here the focus is narrower: the decisions and controls that keep your data where it belongs while you actually use AI.
The principle: data protection with AI is about where data travels
Traditional data protection asks who can access a system. AI adds a second question that older controls were not designed for: what leaves the building when someone uses a tool.
Every AI interaction moves information somewhere. A question typed into a chatbot travels to a model provider, frequently on servers outside Nigeria. An AI feature in your software sends whatever context it assembles. A retrieval assistant reads your internal documents and can repeat their contents to whoever asks.
So the controls that matter are: what you send, who processes it, what they may do with it, how long they keep it, and who inside your business can pull sensitive material back out. Everything below applies those five questions.
Step one: classify your data into four tiers
You cannot write a sensible AI rule for "company data" because company data is not one thing. A four-tier classification takes an afternoon and makes every later decision straightforward.
| Tier | Examples | Rule for AI use |
|---|---|---|
| Public | Marketing copy, published prices, brochures, job adverts | Any approved AI tool. No restriction. |
| Internal | Draft plans, internal process notes, non-sensitive reports, anonymised summaries | Approved business-tier tools only. Not personal accounts. |
| Confidential | Contracts, pricing models, supplier terms, unpublished financials, source code | Approved business tools with written no-training terms, or self-hosted. Named roles only. |
| Personal and sensitive | Customer names and phone numbers, BVN or NIN, bank details, health records, staff files, CVs | Minimise or redact first. Use only with a documented lawful basis and a vendor agreement. Never in a personal account. |
Write this table down, adapt the examples to your business, and put it in front of staff. A one-page classification that people actually read protects more data than a twenty-page policy nobody opens.
Two Nigerian notes: BVN, NIN and bank account details belong firmly in the highest tier and should almost never reach a general-purpose AI tool; and WhatsApp exports are usually full of personal data, so treat them as tier four even when the business thinks of them as "just chats".
Shadow AI: the problem you already have
Shadow AI is staff using AI tools the business has not approved, usually on personal accounts. It is close to universal, and banning it outright rarely works — people simply use it on their phones instead, where you have no visibility at all.
A workable response has four parts:
- Provide an approved tool. Giving staff a business-tier AI account with proper data terms is the single most effective control. Most shadow use is driven by not having one.
- State the rules in plain language. Two or three sentences per data tier: "Never paste customer account numbers, staff records or signed contracts into any AI tool the company has not approved."
- Explain why. Staff comply when they understand that free consumer tiers may use submitted content to improve models.
- Make the approved route easier than the unapproved one. A sanctioned tool hidden behind a request process will be bypassed.
Follow this with a short amnesty: ask staff what they have been using and for what. The answers tell you which tools to buy and which processes genuinely need automating.
Seven ways to reduce what the AI ever sees
The safest data is the data you never sent. These techniques are ordered from easiest to most involved.
- Ask the question without the data. "How should I structure a reconciliation for a retail client?" needs no client figures at all.
- Remove identifiers. Replace names, phone numbers, account numbers, NIN and BVN with placeholders. The analysis is usually unaffected.
- Sample rather than send everything. Ten representative rows generally answer the question that a full export was about to be pasted in for.
- Use synthetic or masked test data for development and prompt testing. Developers pasting production data while debugging is a recurring source of exposure.
- Summarise locally first. Compute the aggregates with a script and send only the summary, not the underlying records.
- Automate redaction in the pipeline. Where an AI feature runs inside your software, strip or tokenise identifiers before the model call. This turns a policy into a control that does not depend on anyone remembering.
- Keep processing inside your perimeter for the highest tier, using a self-hosted model or a provider deployment in your own cloud environment.
Minimisation also reduces cost, because model usage is billed by volume of text processed. The security case and the commercial case point the same way.
Where the AI runs: four deployment patterns by exposure
| Pattern | What it means | Data exposure | Typical fit |
|---|---|---|---|
| Consumer AI tool, personal account | Staff use free or personal subscriptions | Highest: content may be used for training; no company control | Public-tier data only, ideally not at all |
| Business or enterprise tier of a major provider | Company account with administrative controls | Moderate: usually no training on your content, configurable retention | Internal and most confidential data |
| Model API called from your own application | Your backend sends only assembled context | Controlled: you decide exactly what is sent and logged | Confidential data, customer-facing features |
| Self-hosted or private deployment | Open-weight model in your own cloud or on premises | Lowest: data does not leave your environment | Sensitive personal, regulated or highly confidential data |
Cost and engineering effort rise as you move down the table. Most Nigerian SMEs land sensibly on the middle two patterns: a business-tier subscription for staff productivity, plus API-based features in their own software where customer data is involved. Self-hosting is justified where regulation, client contracts or data sensitivity demand it, and it brings its own operational burden.
What to check in an AI vendor's terms
Before approving any AI tool, get written answers to these. A vendor unwilling to answer them in writing is the answer.
- Training. Is our content used to train or improve their models? Confirm it for your specific plan, and check whether a user can re-enable it.
- Retention. How long is submitted content stored, can retention be shortened, and who inside the vendor can view it?
- Location. In which countries is data processed and stored? Cross-border transfer carries obligations under the NDPA 2023.
- Sub-processors. Which third parties does the vendor pass data to, and are they listed?
- Deletion. How do we delete our data, how quickly, and do we receive confirmation?
- Security posture. What encryption, access controls and independent audits are in place? Ask for documentation, not a claim.
- Breach notification. Will they notify you, and within what period?
- Contract. Is there a data processing agreement naming you as controller and them as processor?
- Administrative controls. Can you enforce settings centrally, disable history, restrict features and see usage?
- Exit. How do you export your data and configuration if you leave?
Keep the answers in a register of approved tools with the date checked. Vendor terms change; review it at least annually.
The retrieval trap: permissions inside AI assistants
The most common serious mistake in internal AI projects is building an assistant over company documents without carrying across who is allowed to see what.
A retrieval assistant indexes your files and answers questions from them. If the index contains the payroll spreadsheet, the disciplinary file and the acquisition term sheet, and anyone can query it, you have effectively published those documents internally — in a far more discoverable form than a shared drive, because the assistant will summarise them on request.
Controls that prevent this:
- Filter at retrieval time by the asking user's permissions, not after the model has already seen the content.
- Decide what to index at all. HR files, board papers, legal matters and payroll usually should not be in a general assistant.
- Mirror existing access groups from your file system or document platform rather than inventing new ones.
- Log every query and every document retrieved, so unusual access patterns are visible.
- Test adversarially before launch. Have someone attempt to extract salary information and unreleased financials, and fix what succeeds.
- Separate assistants by sensitivity where simpler: a general company assistant, and a restricted one for finance or HR.
Retention, logging and deletion
AI systems generate a new category of records — prompts, responses, retrieved document references — and these often contain personal data even when the source systems are well controlled.
- Decide retention deliberately. A defined window, for example 30 to 90 days for general conversations and longer where an audit requirement exists, is a reasonable starting position to discuss with your adviser. Indefinite retention creates a growing liability.
- Separate operational logs from content logs. Latency, error rates and cost can be retained long term; conversation content need not be.
- Make deletion real. A customer's deletion request must also reach AI conversation logs, retrieval indexes and any vector store. Build that path before launch; retrofitting it is painful.
- Restrict who can read logs, which frequently contain more sensitive material than the systems they draw on, and document what is logged, where, for how long and who can access it.
What changes for Nigerian businesses
Cross-border processing is the default. Most widely used AI providers process data outside Nigeria. The NDPA 2023 sets conditions for transferring personal data abroad, so know where your provider processes data, record the basis for the transfer, and verify current requirements with the Nigeria Data Protection Commission or a qualified adviser.
WhatsApp is full of tier-four data. Nigerian businesses run sales and support through WhatsApp, and those conversations contain names, phone numbers, addresses, order details and occasionally bank details. Any AI reading WhatsApp history is processing personal data at scale, and needs the same controls as your customer database.
Personal devices blur the boundary. Staff commonly use their own phones for work, which makes AI apps on those phones an uncontrolled channel, and the free tool is often chosen over the approved one. Address it in your policy and by making the approved tool available without friction on the devices people actually use.
Identity data carries specific weight. NIN, BVN, bank account numbers and identity documents should not pass through general-purpose AI tools. Where an AI feature must handle them, keep processing within your own environment or a provider deployment you control, and minimise retention.
Client contracts may be stricter than the law. Corporate, financial and public-sector clients increasingly include clauses about AI processing of their data. Check existing contracts before adopting a tool that will touch client material.
Example (hypothetical): an accounting firm in Abuja
This is an illustrative scenario, not a Linestech client.
A mid-sized accounting firm has eleven staff. Several already use free AI accounts to draft letters, explain tax treatments and reformat client data. Partners are uneasy but have no policy, and one client has just asked, in writing, whether the firm uses AI on their records.
What the firm puts in place over six weeks:
- Classification. Four tiers agreed, with client financial records and any identity data placed in tier four.
- Amnesty and survey. Staff describe what they have been using AI for. Three uses dominate: drafting correspondence, explaining technical treatments, reformatting spreadsheets.
- Approved tool. A business-tier subscription for all staff, with training disabled, retention set to the minimum offered and administrative controls enabled.
- Rules in one page. Drafting and explanation: allowed with no client identifiers. Reformatting client data: only after names and account numbers are removed. Identity documents: never.
- A redaction habit. A find-and-replace template and a short demonstration make de-identification a two-minute step rather than an obstacle.
- Internal assistant, scoped carefully. Built over the firm's own technical library and templates, deliberately excluding client files, payroll and partner correspondence.
- Client answer prepared. A short written statement of what the firm does and does not send to AI tools — useful commercially when competitors cannot answer the question.
- Register and review. Approved tools recorded with the date their terms were checked, reviewed every six months.
Nothing here is technically elaborate. The change is that data handling became a decision rather than an accident.
The pre-launch data protection checklist
Before turning on any AI tool or feature, confirm:
- The data tier involved is identified, and the tool is approved for that tier.
- The vendor's training, retention, location and sub-processor position is confirmed in writing, with a data processing agreement where personal data is involved.
- Identifiers are minimised or redacted before transmission wherever the task allows.
- Retrieval assistants filter by the asking user's permissions at query time.
- Sensitive repositories — payroll, HR, legal, board — are excluded from general indexes.
- Log retention is defined and enforced, and access to logs is restricted to named roles.
- Deletion requests propagate to logs, indexes and vector stores.
- Staff have an approved tool, a one-page rule sheet and a short briefing.
- An incident route exists and staff know how to use it.
- The privacy notice reflects AI processing, and the lawful basis is recorded.
- A review date is set, with an owner named.
What to do if data is exposed
Assume it will happen at some point. Speed and documentation matter more than blame.
- Contain. Revoke the account or key involved, disable the feature, stop further transmission.
- Establish the facts. What data, whose data, which tool, which account, what period, and whether the vendor retains it.
- Request deletion from the vendor in writing, and keep their response.
- Assess the harm. Identity or financial data is considerably more serious than an internal draft being summarised.
- Check notification duties. The NDPA 2023 imposes breach obligations; confirm what applies with a qualified adviser or the Nigeria Data Protection Commission.
- Tell affected clients where required, plainly and early. A calm, specific account is better received than silence followed by discovery.
- Fix the cause, not the person, and record the incident and the remedy. That record is what demonstrates diligence if you are later asked.
Mistakes to avoid
- Banning AI without providing an alternative. Use moves to personal phones, where you have no visibility and no protection.
- Writing a long policy nobody reads. One page per audience beats twenty pages of legal text.
- Assuming business tiers are automatically safe. Confirm training and retention settings for your specific plan, in writing.
- Indexing everything into an internal assistant. Decide what should not be searchable before you build it.
- Filtering after retrieval instead of before. Once content reaches the model it has been disclosed, whatever the interface then hides.
- Forgetting logs when honouring deletion requests. Deletion that misses conversation logs and vector stores is incomplete.
- Ignoring developers. Production data pasted into AI tools during debugging is a frequent and overlooked exposure.
- Treating this as purely a legal task. Most of the risk is operational, and is solved by tooling, defaults, habits and an annual review.
Conclusion
Protecting data while using AI is a matter of a few deliberate decisions rather than heavy technology. Classify your data into four tiers and write the rule for each. Give staff an approved tool so shadow use disappears. Send less by minimising and redacting. Confirm vendor training, retention and location terms in writing, and keep a register. Enforce permissions at retrieval time in any internal assistant, and keep sensitive repositories out of the index. Define log retention, make deletion reach the logs and vector stores, and prepare an incident route before you need it. In Nigeria, pay particular attention to cross-border processing under the NDPA 2023, to identity data such as NIN and BVN, and to WhatsApp history as a store of personal data.
If you are rolling out AI tools or building an internal assistant and want the data controls designed in rather than bolted on, Linestech can help you classify your data, choose a deployment pattern that fits its sensitivity, and build retrieval and logging that respect your permissions.
Frequently asked questions
Can staff use ChatGPT or similar tools at work in Nigeria?
Yes, with rules. Provide a business-tier account with training disabled and retention limited, permit public and internal data freely, require de-identification for confidential material, and prohibit customer identity and financial data. A blanket ban pushes the same activity onto personal phones.
Does AI data protection differ from ordinary data protection?
The principles are the same; the pathways are new. AI adds three specific concerns: content leaving your environment to third-party processors, models potentially retaining or learning from submitted content, and retrieval systems that surface internal documents to people who could not previously find them. Existing controls rarely cover those three.
Is it safe to upload customer lists for analysis?
Not to a general consumer tool. If analysis is genuinely needed, remove names, phone numbers and account identifiers first, or run it in a controlled environment where the data does not leave your systems. Frequently the question can be answered from aggregates containing no personal data at all.
Do we need to tell customers we use AI?
Your privacy notice should describe the categories of processing, including where third-party AI services process personal data, and where automated decisions affect people you should explain that and offer a review route. Confirm the specific requirements with the Nigeria Data Protection Commission or a qualified adviser.
Is self-hosting an AI model the safest option?
It gives the strongest control over where data sits, which matters for regulated material. It also transfers the full security burden to you: patching, access control, monitoring and key management. A poorly run self-hosted deployment is less safe than a well-configured enterprise service.
How do we handle AI that reads our WhatsApp conversations?
Treat those conversations as a personal-data store. Establish a lawful basis, limit what is extracted, redact identifiers where the task permits, restrict who can query the assistant, set a retention window, and include the processing in your privacy notice.
What should a small business with five staff actually do?
Four things: write the one-page classification, buy one approved business-tier tool, brief everyone for thirty minutes on what may and may not be sent, and keep a register of approved tools with the date their terms were checked. That covers most of the realistic risk at very little cost.
Who should own data protection for AI inside the business?
A named person, usually whoever already owns data protection or IT, with visible support from a director. Where you are required to have a data protection officer, it falls within that role. What matters is that a specific person maintains the register, reviews terms and handles incidents.
Sources and further reading
Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.


