You never bought an AI product. The tools you already pay for switched one on for you.

If you run a small business and somebody asks when you decided about AI, you probably have an answer ready. You tried the chatbot, or you didn't. You looked at a tool once and thought about it and got busy. Either way it feels like a decision that is still sitting in front of you, waiting for a quiet week that never arrives.

Meanwhile the decision has largely been made somewhere else. Not in a meeting, not in a sales call — in a release note. The software you already pay for has been growing AI features for two years now, and they arrive the way every other update arrives: overnight, switched on, mentioned in a changelog nobody opens. Your accounting package. Your email. Your CRM, your document storage, the thing you use to send quotes. Each one of those holds your customer list, and several of them now read it with a model.

I want to be careful here, because this is exactly the shape of an article designed to frighten you into buying something, and I am not going to do that. Most of these features are fine. A few are genuinely useful. The problem is not that AI touched your data — it is that a decision about your customers' information got made, and nobody from your business was in the room when it happened.

Why it arrives this way

There is a straightforward commercial reason, and understanding it makes the pattern much easier to predict. A software company that ships an AI feature as an optional extra gets a low take-up rate and a hard number to report. A software company that ships it switched on gets to say that a large share of its customers use AI. One of those sentences raises money and one does not.

So the default is on, the announcement is cheerful, and the setting that turns it off is real but three levels deep in an admin page you visit twice a year. None of that requires anyone to behave badly. It is just what happens when the incentive to enable is strong and the incentive to ask is weak.

The sentence that does the most work

When anyone does ask, the answer comes back in a form so standard it may as well be a stamp: we don't train our models on your data. It is usually true. It is also a narrower promise than almost everyone hears, and the gap is where the interesting part lives.

Four things that sentence leaves open, none of which are conspiracies — they are just separate questions that one answer gets used to cover.

• Who is “we”? Most software companies do not run their own model. They send your text to somebody who does. The promise you were given belongs to your vendor; the machine reading the data belongs to a company you have never dealt with and probably cannot name. Both parties can be entirely honest and the chain still has a link in it you never inspected.
• Training is one use of data. Keeping it is another. A vendor can truthfully say they never train on your data while holding it for a period for debugging, abuse monitoring, or quality review — sometimes with human beings able to look at a sample of it. That is not sinister and it is often contractually sensible. It is also not what people picture when they hear the reassurance.
• The promise may belong to a plan rather than to you. Data commitments are frequently a property of the tier — the enterprise agreement gets the guarantee and the small-business plan gets the marketing page. Worth knowing which one you are on before quoting it to a client.
• It describes today. Terms get updated the same way features do, with an email you skim. A commitment that was accurate when you signed is not self-maintaining, and the change that matters will not be flagged as a change that matters.

What actually matters at your size

You are not writing a data processing agreement and you should not try. For a business with a van fleet or a dozen staff, the practical exposure comes down to two things, and neither is exotic.

The first is that your customers' details — names, addresses, gate codes, the note about which dog bites — end up being handled by a company you cannot name, possibly in a country you did not pick. Not necessarily leaked. Just handled, by a party outside the arrangement your customer thinks they made with you.

The second is more concrete, and it is the one that actually bites. You have probably already made promises about this in writing. Your privacy policy says something. If you have won a strata contract, a government panel, or anything with a procurement department attached, your tender almost certainly contained a paragraph about how client information is handled and where it is held. Those documents were written before your file storage grew an AI assistant. When somebody eventually sends you a supplier questionnaire — and in commercial and strata work, somebody eventually does — the question is not whether you use AI. It is whether you can describe what happens to their data. Not knowing is a worse answer than any of the true ones.

The risk is rarely that a vendor did something outrageous. It is that you made a promise in a tender two years ago and a software update quietly changed whether it is still accurate.

The twenty-minute version

This does not need a consultant and it does not need a policy document. Do it once, put a note in the calendar for a year from now, and you are ahead of most businesses your size.

• Write down every tool that holds customer names, addresses or phone numbers. Accounting, email, job software, file storage, the quoting tool, the marketing list. The list is usually shorter than people expect and always longer than they first say.
• Open the settings on each and look for anything called AI, assistant, intelligence, copilot or smart. Note two things: whether it is on, and whether anybody in your business turned it on. The second column is the point of the exercise.
• Find the vendor's sub-processor list. Nearly every serious vendor publishes one — search their name plus “sub-processors” and you will land on a page of company names. That page is the honest version of who can touch your data, and it is public precisely because they are obliged to tell you.
• Check which plan you are on against whichever data commitment you are relying on. If the guarantee lives on a page headed Enterprise and your invoice says something else, you have found something worth knowing.
• Then decide on purpose. Leave it on where the feature earns its place, turn it off where it does not. The goal is not a business with no AI in it — that ship has sailed and it was a useful ship. The goal is that every one of those switches is where it is because somebody chose it.

Our side of it

We build AI features into our own software, so it would be cheap of me to write all that as though we sit outside it. We do not. Any vendor shipping an AI feature is a link in exactly the chain I have just described, and that includes us.

What I would say is that the questions above are answerable, and how fast a vendor answers them tells you most of what you need. In Dispatch the AI drafts replies to enquiries off your own price list and a person still presses send — which is a design choice about supervision rather than a claim about data handling, and the two get blurred together constantly in this industry. Ask us the data questions separately. Ask everyone the data questions separately.

The wider habit worth forming

The thing that has genuinely changed is not that AI is powerful. It is that capability now arrives by update. Software you bought for one purpose acquires new abilities on a Tuesday, and those abilities come with defaults that somebody else chose in a meeting about adoption metrics.

That is not going to stop, and it is not really reasonable to ask an operator to read every changelog. What is reasonable is an hour once a year spent on a list of your own tools, checking which switches are on and who is on the other end of them. A decision you did not make is still a decision you own — and the awkward moment always arrives as a question from a client, at the point where the honest answer is I would have to find out.