Pretty much every leadership team has been asked some version of "what's our AI plan?" in the last year or two. The honest answer is rarely a single plan. It's a handful of small, specific jobs where a machine is useful, and a longer list of places where it would make things worse.
Here's how I sort them.
Where it helps
Reading lots of text. This is the clearest win. Customer reviews, support tickets, survey comments and call notes are full of useful signal that no one has time to read. Classifying them into themes, flagging sentiment or pulling out product names used to take weeks of reading. I built a topic model for customer feedback at a large retailer a few years ago, and the saving was well over two thousand hours of manual review. Today's language models make that sort of job even easier to set up.
First drafts of routine things. Weekly commentary on a report, a summary of a long thread, a first pass at documentation for a table. The key words are "first draft". Someone still reads it and owns it.
Helping people write SQL and code. Used as an assistant by someone who can read the result, it saves typing and jogs memory. Used by someone who can't check the output, it produces queries that run, return numbers and are subtly wrong. That's the worst kind of error because nothing flags it.
Searching your own documents. "Where did we write down how churn is defined?" is a good question for a search tool that points to the source document. The pointer matters. An answer without a source can't be trusted.
Tagging and cleaning. Standardising messy product names, categorising free-text fields, spotting near-duplicates. Dull, high volume, easy to sample and check.
Where it hurts
Anything where the number has to be right and nobody checks. Language models are built to produce plausible text, not to do arithmetic reliably or to know when they're guessing. For calculations, use code. For facts about your business, point the tool at the actual data and make it show its working.
Small data, big decisions. If you have forty customers, a model has nothing to learn from. A conversation with each of them will teach you more.
Where you need an audit trail. Regulated reporting, financial figures and anything that might be questioned later need to be reproducible. Free-form model output usually isn't.
Where the data shouldn't leave. Pasting customer lists or contracts into a public tool is a privacy problem, whatever the tool can do. See your provider's terms and set a rule, and then follow it. We wrote about that in using AI tools safely with company data.
A test I use
For any proposed use, I ask four things.
- Does the task happen often enough to be worth automating?
- Is the output easy for a person to check, quickly?
- What happens when it's wrong, and can we live with that?
- Do we know how we'd measure that it's working?
If the answers are yes, yes, "a bit of rework" and yes, it's a decent candidate. If the second answer is "not really", I'd leave it alone, no matter how good the demo looked.
Keep a person in the loop
The thread through all of this is boring but important. The projects that last are the ones where a person stays responsible. The machine does the volume, the person does the judgement, and there's a simple way to see how often the machine got it wrong.
That also happens to be the most reassuring answer to the question analysts are quietly asking, which is whether any of this replaces them. In the work I've seen, it replaces the assembly and leaves the thinking. There's more of the thinking to do, not less.
If you're trying to work out where AI fits in your own team, our AI solutions work starts with exactly this exercise: a short list of candidate jobs, ranked by payback and risk.