A company tells me it needs AI. This usually happens before anyone can tell me which piece of work should become better.

There is a list of ideas. A few demos. Perhaps a chatbot wearing the company colours. There is also a real employee, somewhere, copying information from one system into another because the integration has been “coming next quarter” for three years.

I am not against the chatbot. I am against starting with the answer.

Let’s demystify the first question

The first question is not: Which model should we use?

It is: What should be different on an ordinary Tuesday after this is live?

Does a credit analyst review fewer irrelevant documents? Does customer support find the correct policy faster? Does a product manager see the reason a case is stuck? Does a customer avoid entering the same information for the third time?

If the answer is vague, the AI idea is vague. A beautiful prototype does not repair that.

I like to map five things before discussing technology:

  1. The trigger. What starts the work?
  2. The decision. What judgement or action needs to happen?
  3. The evidence. What information is actually available at that moment?
  4. The owner. Who is responsible when the result is wrong, late, or unclear?
  5. The feedback. How will the system learn whether the outcome was useful?

This is not a fluffy concept. It is the boring part that decides whether the project survives contact with production.

Automation, assistance, or a real decision?

People use “AI” for very different things.

One workflow may need deterministic automation: copy a verified value, apply a rule, create a task. Another may benefit from assistance: summarise a long file, suggest a response, surface similar cases. A third may involve a consequential decision about credit, employment, healthcare, or access to a service.

These are not the same product with different prompts.

The cost of an error is different. The evidence required is different. Human oversight is different. The logging is different. The person who should approve the project may be different too.

NIST’s AI Risk Management Framework uses four useful verbs: govern, map, measure, and manage. I like the order. You map the context before pretending that a metric will save you. You decide how the system is governed before the first incident asks the question for you.

The EU AI Act also uses a risk-based approach. That does not mean every internal assistant needs a committee of twelve people. It means the product team should understand what the system does, who it affects, and how serious a failure can become.

The prototype is allowed to be wrong. The workflow is not allowed to be imaginary.

A prototype should be quick. It should test something uncertain. I have always liked hackathons for exactly this reason: engineers and domain people can turn an abstract conversation into something everybody can touch.

But a prototype is evidence, not a small production system.

It may prove that a model can classify the documents in a sample. It does not prove that the right documents arrive, that consent is clear, that edge cases have an owner, or that the operations team has time to review uncertain results.

Reality check: most valuable workflows are already full of exceptions. The normal path is often the easy 60%. The business pays for handling the remaining 40% without losing the customer, the evidence, or the regulator’s patience.

This is why I often recommend one of four outcomes after an AI review:

  • automate the stable steps with ordinary software;
  • add AI as an assistant with a clear human decision;
  • run a narrow, measured experiment;
  • leave the workflow alone until the data or economics improve.

“Wait” is a valid product decision. So is “use less AI.”

A small test I use

Take the proposed use case and remove the word AI from its description.

Can the team still explain the customer problem, the operational change, the owner, and the measurement? If yes, we have something to work with. If no, the technology is carrying an idea that has not yet learned to walk.

AI gives small teams extraordinary leverage. I use it every day. But leverage amplifies the quality of the decision underneath it.

Before choosing the model, find the work.

Sources and further reading