Generative AI can save a small business hours: drafting replies, summarising meeting notes, sorting feedback and creating first-pass marketing copy. But a useful prompt can also become a data-protection event if it includes a customer’s name, contact details, order history, complaint, health information or anything else that identifies them. For a sole trader or a team of five, the practical question is simple: what must we decide before customer information enters an AI tool?
This is not about banning AI. It is about choosing a use case, supplier and workflow that you can explain, secure and control. The Information Commissioner’s Office (ICO) makes clear that data-protection law applies where AI processes personal data, including when a business uses an existing model on an individual rather than building a model itself. Its guidance also stresses data protection by design and by default. Read the ICO’s AI and data-protection guidance.
Use this checklist before your business pastes customer data into a chatbot, AI writing assistant, meeting transcription service, CRM add-on or automated support tool. It translates the big compliance themes into decisions that small teams can make and record without creating a mountain of paperwork.
Start with the right question: do we need customer data at all?
Do not begin with “Which AI subscription should we buy?” Begin with the job to be done. Write one sentence describing the task, the benefit and the data required. For example: “Use AI to turn anonymous themes from 50 feedback responses into a list of service improvements.” That is materially different from: “Upload the full spreadsheet of named customer complaints and ask for a summary.”
Personal data is broader than a name and email address. A customer number, online identifier, delivery address, voice recording, free-text complaint or combination of details that can identify someone may all count. Information about health, ethnicity, religion, trade-union membership, sex life or sexual orientation is special-category data and needs extra care. Criminal-offence data is also particularly sensitive.
Make a default rule for your business: use synthetic, anonymous or redacted material first. Replace names with labels, remove account numbers and contact details, and delete narrative details that could reveal identity. If the task works with a fictional example, a spreadsheet of totals or genuinely anonymised themes, do that instead. Redaction is not a magic wand: if the remaining facts can reasonably point back to a person, treat the information as personal data.
1. Map the data journey before anyone writes a prompt
A data map sounds formal, but a one-page table is enough for many SMEs. It forces you to see where information starts, who handles it, what is copied and where it ends up. The ICO advises organisations using AI to document movements and storage of personal data, because AI-related processing can involve multiple systems, formats and third parties. See the ICO’s guidance on security and data minimisation in AI.
Your minimum data-map fields
- Use case: what the AI is doing, such as summarising support tickets or drafting a reply.
- Data fields: exactly what enters the tool, including text pasted into prompts, attachments, call transcripts and metadata.
- People affected: customers, prospects, employees, suppliers or children.
- Source and destination: where the data came from and which AI product, workspace or integration receives it.
- People with access: staff, contractors, administrators, the AI supplier and any sub-processors.
- Output: what is created, where it is saved and whether it goes back into the CRM or customer record.
- Deletion point: when prompts, uploaded files, exports and outputs will be removed.
Include hidden routes. A staff member may paste a customer email into an AI tool, download the result, add it to a helpdesk ticket and then share it in a team chat. Each copy increases the security and retention problem. Likewise, check whether browser extensions, meeting bots and CRM integrations automatically send content to an AI service.
For a practical example, a small estate agent may want AI to summarise viewing feedback. Its map might show that the input includes a prospective tenant’s name, employment comments and accessibility needs. That is a signal to redesign the workflow. The agent could instead use a template that asks staff to remove names and retain only property reference, viewing date and non-identifying themes. The AI output should be a draft internal summary, not a decision on who gets a tenancy.
2. Define the purpose, lawful basis and customer expectation
Before processing, be specific about why you are using personal data. “To improve efficiency” is a business objective, not a complete processing purpose. A clearer statement is: “To create a draft response to a customer’s delivery query, which a trained team member will check before sending.” The ICO says organisations should separate distinct processing operations and identify a purpose and appropriate lawful basis for each when using AI. Read the ICO’s guidance on lawfulness in AI.
Choose and document the relevant lawful basis under UK data-protection law. Depending on the context, this might be performance of a contract, legitimate interests, legal obligation or consent. Do not assume consent is automatically the safest answer; it must be freely given, specific, informed and withdrawable. If you rely on legitimate interests, assess the benefit, the necessity of AI processing and the impact on people. Be particularly cautious where the new use would surprise a customer.
Ask a plain-English expectation test: “If we explained this use in one short sentence at the point the customer gave us their information, would it feel reasonable?” A plumber using an AI assistant to turn their own generic notes into a tidier job report is low risk. Uploading named customer emails to a public-facing chatbot so its provider can improve its product is a different proposition and needs a much stronger justification, supplier review and clear information for customers.
Update your privacy notice where necessary. Explain the type of AI-assisted processing in useful language, why it is used, the categories of information involved, any relevant international transfers and how customers can exercise their rights. Transparency is not achieved by burying “AI” in a legal document.
3. Treat the AI provider as a supplier, not a magic box
If a third-party tool processes customer information for your business, it will often be acting as a processor for that activity. You remain accountable for your own compliance as controller; a supplier’s reassuring sales page does not transfer that responsibility. The ICO says controllers must ensure processor compliance on an ongoing basis and can still face regulatory action or claims where their processing breaches the UK GDPR. Read the ICO’s controller responsibilities guidance.
Run this supplier check before approving a tool
- Role and contract: confirm who you contract with and obtain data-processing terms that cover the required UK GDPR processor provisions. The contract should describe the processing, require appropriate security, address confidentiality, sub-processors, help with rights requests and state what happens to data at the end of the service.
- Training and product improvement: establish in writing whether prompts, uploads and outputs are used to train, fine-tune or improve the provider’s models. If the answer is yes, do not treat it as a routine internal tool. Consider whether a setting or business plan can disable that use, and document the decision.
- Retention and deletion: ask how long prompts, files, logs, backups and outputs are retained; whether administrators can set retention; and how deletion is verified. “We keep data to improve quality” is not a retention schedule.
- Sub-processors and locations: identify the provider’s sub-processors, support access arrangements and countries involved. Review change notifications rather than accepting them blindly.
- Security evidence: check for multi-factor authentication, encryption, audit logging, incident notification commitments, role-based access and an account-administration process. Match the depth of your review to the sensitivity and volume of data.
- Exit route: confirm you can export needed business records and delete the account without leaving uncontrolled copies behind.
International access matters even where a supplier advertises UK or European hosting. The ICO’s current guidance explains that a restricted transfer can arise when personal information is made accessible to a separate organisation outside the UK, and that cloud customers should check the legal entity they contract with and their provider’s global processing arrangements. Use the ICO’s restricted-transfer guidance. Do not guess based on a server-location slogan. Work through the ICO’s test and, where required, put an appropriate transfer mechanism and assessment in place.
4. Set access controls that fit a small team
The easiest way to reduce exposure is to limit who can put data into the tool and who can see the results. Give each person an individual work account; do not share one login among the whole office. Turn on multi-factor authentication, remove access promptly when someone leaves and keep the number of workspace administrators low.
Apply least privilege. A junior marketer writing generic social posts does not need access to the AI workspace used by the customer-service manager to create draft replies. A freelance virtual assistant may need permission to use a pre-approved template but should not be able to browse historic prompts or download an entire customer-data export.
Create a short acceptable-use rule that staff can actually follow. It should name approved tools, prohibit personal accounts for business data, list data that must never be entered without written approval, require redaction where possible and say where AI outputs must be saved. Add a simple escalation route: “Stop and ask the owner or data lead if a prompt contains a name, contact detail, payment information, health detail, complaint, child’s data or confidential contract information.”
5. Keep less data, for less time
Data minimisation and storage limitation are practical controls, not abstract principles. Only enter the minimum detail needed for the task, and keep it only for as long as it serves that task. Avoid uploading whole mailboxes, CRM exports or customer-history files merely because the AI tool can accept them.
Set a retention rule for four separate things: the source data, prompts and attachments, generated outputs, and logs or exports. For instance, a support team may retain the approved reply in its existing helpdesk record under the normal customer-service schedule, but delete the temporary prompt and downloaded draft immediately after use. Make someone responsible for reviewing whether the tool’s settings and real-world behaviour match the rule.
Remember that an output can itself be personal data. A generated customer profile, summary of a complaint or suggested next action may need to be found, corrected or deleted if a customer exercises their rights. The ICO notes that rights can apply to personal data in training data, fine-tuning data, model outputs and user queries. See the ICO’s discussion of individual rights in generative AI.
6. Put a human in charge of every meaningful customer outcome
Generative AI is good at producing plausible language, not guaranteed truth. It can omit context, invent details and reproduce bias. That creates both customer-service and compliance risks when an output contains a statement about an identifiable person.
Use AI outputs as drafts, not facts. The named staff member who sends a response or updates a record must check it against the original source, correct errors and make the final decision. This is especially important for refunds, complaints, credit, pricing exceptions, hiring, eligibility, safeguarding, health, insurance and any outcome that could significantly affect someone.
Do not use a chatbot or scoring tool to make solely automated decisions with legal or similarly significant effects unless you have taken specific legal advice and built the necessary safeguards. If AI helps prioritise leads or flag possible fraud, use it as one input with a documented human review, not as an automatic rejection or accusation. Record when the human overruled the tool; these examples are valuable for improving the process and spotting patterns of bias or inaccuracy.
Build a simple quality-control loop
- Require factual checks against the original customer record.
- Ban invented citations, promises, prices, delivery dates and policy statements.
- Sample a proportion of AI-assisted outputs each month, with more frequent checks for high-risk work.
- Log material mistakes, customer complaints and overrides in one place.
- Pause the use case if recurring errors, unfair outcomes or unexpected data disclosures appear.
Tell customers when it is helpful and relevant that AI assists a service, but do not let that disclosure substitute for accountability. Your business, not the software, owns the relationship and the decision.
7. Assess the risk and write down the decision
You do not need a corporate-sized governance department. You do need evidence that you considered the risk before deploying the tool. For each use case, keep a decision record containing the data map, purpose, lawful basis, supplier checks, access rules, retention period, human review and date of next review.
Consider whether a data protection impact assessment (DPIA) is required. The ICO describes a DPIA as an important accountability tool and says AI use will often involve processing likely to create high risk to people’s rights and freedoms; where it does, a DPIA is required. Even if you conclude that the use case is not high risk, record why. Consult the ICO’s AI accountability and DPIA guidance.
High-risk warning signs include profiling, large volumes of customer data, vulnerable people, children, special-category data, systematic monitoring, combining datasets, decisions about access to services or financial outcomes, and a new use customers would not expect. If your assessment shows a high residual risk that you cannot reduce, seek specialist advice before proceeding.
A pre-prompt checklist for UK small businesses
Before the first live customer-data prompt, the owner or appointed data lead should be able to answer “yes” to each of the following:
- We have a defined use case and can explain why AI is necessary.
- We know exactly which personal data enters, leaves and is stored by the tool.
- We have removed or replaced identifying details wherever the task allows.
- We have documented a lawful basis and checked the use is fair and within customer expectations.
- Our privacy information accurately reflects the processing.
- We have reviewed the provider’s contract, security, sub-processors, training settings, retention and deletion arrangements.
- We have assessed overseas access and transfers rather than relying on marketing claims.
- Only authorised staff using individual protected accounts can access the approved workspace.
- We have written deletion rules for prompts, attachments, outputs and exports.
- A person checks meaningful outputs and makes the final customer-facing decision.
- We have completed a proportionate risk assessment and, where needed, a DPIA.
- We know how to respond if a customer asks to access, correct, erase, restrict or object to the use of their information.
Conclusion: make safe AI use the easy default
The best SME AI policy is not a 40-page document that nobody reads. It is a repeatable routine: minimise the data, map the flow, check the supplier, limit access, delete temporary material, review outputs and record the decision. Start with one low-risk use case using anonymised or redacted material, test it, then expand only when the controls work in practice.
Make this checklist part of tool approval and staff onboarding this month. If you cannot explain what happens to a customer’s information after it is entered into an AI tool, do not enter it yet. Pause, redesign the workflow or get data-protection advice before convenience becomes a compliance problem.
