What to decide before AI reads customer data

The first AI tools most small businesses use are private ones. A chat window, a few prompts, a draft email pasted back into the inbox. The data stays in the owner's head. If the model gets something wrong, the cost is a wasted ten minutes.

The second wave is different. Now the AI is connected to something real. It reads support tickets, or order history, or the shared inbox. It pulls from the documents the team writes. It writes the first reply, or sorts the queue, or summarises a customer's last six interactions for whoever picks up the phone. The data is no longer in one person's head. It is moving through a system that someone outside the business helped build.

That second step is where the useful decisions are. The ones worth making before the technology is chosen, not after.

This piece is not a legal note. It is the working shape we use when a client asks us to add an AI feature that touches real customer information. The order matters. Pick the model first and the rules get retrofitted around it. Pick the rules first and the model becomes a much smaller decision.

The first decision is what it should never see

Most teams start with "what should the AI do?" The better starting question is "what should it not be able to read?"

That sounds backwards. It is the one that saves the most pain later.

A short list, written before the build, usually includes a few things every time. Payment card details, full bank account numbers, passwords, the contents of identity documents. Health information unless the business is actually in healthcare. Anything covered by a non-disclosure agreement that did not anticipate being read by a third-party model. Anything a customer told the team in confidence that was never meant to be searchable. Internal staff records and pay information unless the AI is specifically for HR. Saved support transcripts where the customer was clearly upset and the resolution involved a goodwill payment.

Once the list exists, the build has a shape. The AI is connected to the systems it needs and not the systems it does not. The fields it can read are listed, not assumed. The "everything except this" framing is replaced by "only these things". That is much easier to defend later if something does go wrong.

We have built AI features for client sites where the first useful decision was a list of fields the assistant was never allowed to see, written down before we picked the model. It made the rest of the project shorter, not longer.

Decide the job before the data

The second decision is what the AI is actually being asked to do. Not the demo. The repeated job.

"Help us with customer support" is not a job. It is a category. The jobs underneath it are different from each other. Drafting a first reply for a human to send. Suggesting which team a ticket should go to. Pulling up a customer's recent orders so the human does not have to. Summarising a long thread before a Monday handover. Each of those needs different data, different review, and different fallback rules.

The reason this matters is that the wider you make the job, the wider you make the access. An AI that drafts replies needs the ticket and the customer's order history. An AI that decides which team a ticket goes to barely needs the customer's name. If the job is wide because nobody narrowed it, the data access ends up wide too. The risk grows for no extra benefit.

The cleanest builds we work on usually have one job per feature. The job has a name a non-technical person can repeat. The data access matches that job and not the next four jobs someone might want later.

Decide who reviews the output, and when

The third decision is about people, not technology.

An AI feature that touches customer data has three review modes. The output can go to a person before it goes anywhere else. The output can go to the customer or the system directly, with a person sampling later. The output can go straight through with no review at all.

Each is appropriate for some kinds of work and a disaster for others. A draft reply queued for a human to send is fine for support. A draft that goes straight to the customer is fine for "your order has shipped". A draft that goes straight to the customer where the AI has just summarised a complaint is asking for trouble.

The thing to write down is which review mode each feature uses, who that reviewer is by name, and what they are allowed to change. "The team will look at it" does not survive a holiday. "Sam reviews drafts in the support queue, can edit freely, and approves them in batches twice a day" survives a holiday because someone covers for Sam and inherits the same rule.

Sampling rates matter too. If a feature is allowed to send things directly to customers, somebody should still be reading a portion of the output. Once a week, ten messages, a quick look. Most of the AI features that quietly drift in tone or quietly get something wrong are the ones where nobody is sampling.

Decide what the AI keeps, and where

The fourth decision is about retention.

When customer data is sent to an AI provider, several things happen. The provider receives the request. Most reputable providers say they do not use your business data to train their models by default, but that is a setting you have to confirm rather than assume. The request and response can be cached for performance. Logs may be kept for a period for safety and abuse monitoring. If your tool stores the conversation history in your own database, that is yours, with the same retention rules as any other customer record.

The useful decision is to know each of those for the providers you use, write them down once, and treat that note as the source for anyone who asks "where does the data go?" The note is also where you write your own retention rules. Three months for support draft history. Twelve months for ticket summaries. Customer requests to delete propagate to the AI conversation logs too, because the AI logs are now part of the customer record.

This is the boring decision. It is also the one that comes up first when somebody asks a question you do not want to answer on the spot.

Plan for wrong, slow or missing answers

The fifth decision is what happens when the AI cannot do its job.

Models go down. Providers raise prices. New rules ship. An AI feature without a fallback turns a quiet outage into a queue that nobody can clear. An AI feature with a fallback turns the same outage into a slightly slower morning.

Most fallbacks are simple. The support draft system falls back to the team writing replies from scratch, the way they did before the feature was added. The summariser falls back to the human reading the thread, the way they always could. The fallback is not impressive, but it is what keeps the business running if a provider has a bad day.

The fallback is also the thing that makes the AI feature easier to switch off if it stops earning its place. Twelve months later, when somebody asks whether a feature is worth keeping, the existence of a clean fallback means the answer is allowed to be "no". Without one, the feature gets defended just because removing it would cause pain.

Set data rules before choosing the AI

Put together, the decisions are short. A list of what the AI can read and a list of what it must never see. The named job. The named reviewer. The retention note. The fallback. One page, written before any model is picked.

When that page exists, the technology decisions get easier. The provider choice is partly a privacy decision now, not just a performance one. The build is sized for the actual job, not the hypothetical one. The team can answer "where does the data go?" without scrambling.

UK data rules changed in early 2026 with the Data (Use and Access) Act, and the ICO has been directed to draft a new statutory code on AI and automated decisions. The exact wording of that code is not the point of this piece. The point is that businesses making these decisions now, on their own, are already making the choices the code will eventually ask them to evidence. Doing it before the build is much cheaper than doing it during an audit.

None of this works first time. Even with the page written, the first month will surface things nobody thought of. A field the AI ended up reading by accident. A reviewer who turned out to be on holiday. A customer who asked for their conversation history and reminded the team that the AI logs counted too. Plan a review at the end of month one. That is not a failure of the page. It is the page doing its job.

The decisions above will not make AI work risk-free with customer data. Nothing will. They will make the risk legible, named, and small enough for a small team to carry. Which is the same shape every other useful piece of operational work in a small business ends up taking.

If you are about to point an AI tool at real customer information, write the page first. The model can wait.