How to tell whether your business needs AI

The question “do we need AI” is almost always asked from the wrong end. It gets framed as a question about technology, while it is really a question about how people work. Models, embeddings and prompts are tools, and choosing them makes sense once you know which operation they are meant to speed up.

So the conversation should start with an observation: where do people repeat the same mental effort every day? Looking for an answer in documents. Reading an incoming enquiry and deciding who should handle it. Checking a text against a policy. Explaining to a new colleague what has already been explained twenty times. Those places are the candidates.

Where AI helps

AI works well where there is text, repetition and tolerance for a check. Support answering similar questions. A department looking up a clause in a manual every day. Intake, where an enquiry has to be classified and routed. Drafting: emails, descriptions, summaries of long documents.

What these cases share is that the result can be judged quickly. A person looks at the answer and knows in a second whether it will do. Where checking takes as long as doing the work itself, there is no gain.

Drafting deserves a separate look. Writing the first version of an email, squeezing the essentials out of a ten-page document, rephrasing a technical description for a client — in all of these a person edits the text before sending anyway, which means the check is already built into the process. These scenarios usually launch fastest: almost nothing in the team’s work has to change.

Where AI is redundant

If an operation happens once a month, there is no point automating it — keeping the scenario alive will cost more than it saves. If the rule is strict and fits in one line, you do not need AI, you need an ordinary condition in code: cheaper, faster and more predictable.

A separate case is a process where a mistake is expensive and nobody is in a position to check the answer on its merits. A legal opinion, a calculation that money depends on, a decision with consequences for the client. Here AI can prepare the material, but not make the call.

What data it needs

AI does not know your company. Everything it says about your services, deadlines and rules comes from what you give it. So before starting it pays to look honestly at your own documents.

• is there a current version of the policy — and does the team know which one it is
• do the documents live in one place or get collected from chats and mailboxes
• do they contradict each other in ways the team long ago settled verbally
• who may see this data at all, and which parts are restricted

If the answers are discouraging, that is not a reason to drop AI. But you will have to start with tidying up: an undescribed process and contradictory documents produce a confidently worded wrong answer.

How to choose the first scenario

The first scenario is chosen not for how impressive it looks but for how checkable it is. A good candidate looks like this: the operation happens often, a well-defined group of people performs it, the data for it lives somewhere known, and the quality of the answer can be judged immediately.

Before launching, agree on what counts as success. Not “the AI works”, but for instance: the operator finds the right clause faster than before, and in nine cases out of ten the prompt suits them. That criterion can be checked in a month, and you can answer honestly whether to continue or stop.

A scenario needs an owner — someone responsible for its quality who decides what to do when it misfires. Without that, a pilot lives exactly as long as the person who launched it keeps at it. Conversely, when there is an owner who uses the result themselves every day, the scenario usually survives and grows without a separate project around it.

Why you keep a human in the loop

A human in the loop is not distrust of the technology but the thing that makes it usable. While an operator confirms the answer, a mistake stays inside and costs a few seconds. The moment the answer goes straight to the client, the same mistake becomes a promise made by the company.

The practical order is usually this: first AI prompts a person, then it answers on its own within a narrow, well-studied class of enquiries, and there is always a way to hand the conversation to a human. Each step is taken after the previous one has shown acceptable quality on real data.

There is also a practical benefit people rarely plan for. Someone who accepts or rejects a prompt every day is a ready-made source of data about quality. After a month of that you can see which questions the system consistently gets wrong, which documents are missing and where the wording in the policies contradicts itself. No launch without a human in the loop produces that information.