AI and Customer Data: The Decisions to Make Before You Build

This is a design decision, not a compliance afterthought

Privacy questions asked at the end of an AI project turn into rework. Asked at the start, they cost a meeting. The reason is architectural: whether personal data leaves your infrastructure determines which providers are viable, which affects cost, capability and latency.

None of what follows is legal advice — take that from someone qualified. It is the checklist we work through with clients before writing code.

Decision one: what data actually needs to go

Most AI features need far less personal data than the first design assumes. A support assistant needs the account's plan and order status; it rarely needs the customer's full record.

• Send identifiers rather than identities where you can
• Redact names, addresses and payment details before the call if they add nothing
• Pass a summarised context rather than a whole document when a summary suffices
• Keep special-category data out of prompts unless there is a compelling, documented reason

Decision two: where processing happens

Major providers offer regional processing, and for UK and EU businesses that is usually the sensible default. It simplifies the transfer question and it is far easier to explain to a customer or an auditor.

Get it in the contract rather than the marketing page, and confirm it applies to every component — the model, the vector store, the logs and any monitoring service you bolt on. Logging is the one people forget, and logs contain prompts.

Decision three: retention

Decide what is kept, where, and for how long, for each of: prompts, outputs, retrieved context, and conversation history. Then implement deletion rather than intending to.

A useful test: if a customer exercises their right to erasure tomorrow, can you actually remove their data from every store the AI feature touches, including logs and embeddings? If the answer needs a caveat, the design is not finished.

Decision four: training on your data

Enterprise API terms from the major providers generally exclude your inputs from training by default, while consumer tiers often do not. The difference matters and it is the sort of thing that changes, so verify it against current terms at the time you contract rather than relying on what was true last year.

Whatever the answer, write it into your own privacy notice in plain words. Customers increasingly ask, and “we use AI” without specifics reads as evasive.

The practical artefacts to produce

1. A one-page data flow: what leaves your systems, to whom, where it is processed, what comes back, what is stored.
2. A DPIA where the processing is likely to be high risk — and if you are unsure, doing one is cheap insurance.
3. Updated privacy notice wording covering automated processing.
4. A data processing agreement with each provider in the chain.
5. An internal policy on what staff may paste into consumer AI tools, which is where most real-world leakage happens.

That last one is worth more than the other four combined in most businesses, and costs nothing but a decision.

Frequently asked questions