Is AI the right tool? Start with the problem, not the model

Most AI projects that disappoint do not fail on technology. They fail because nobody wrote down which problem they solve, what that problem costs today, and what result would count as success. Chapter 1 of Building AI Applications is about doing that work first.

Define the problem and its cost

Start with a problem statement that a business owner would sign: who is affected, how often it happens, and what it costs in time, money, errors or lost customers. In the book's running example, an insurer's claims team spends a large share of each day reading emails, copying data into the claims system and drafting standard replies. That is a concrete, measurable problem.

Then ask the uncomfortable question: is AI the right tool? If the rules are known and the inputs are structured, ordinary code is cheaper, faster and easier to test. AI earns its place when the input is unstructured (emails, documents, images, speech) or when the task needs judgement that cannot be written as rules.

Model the process before you automate it

The chapter uses BPMN to model the as-is process and the to-be process. The diagram makes three things visible:

• which steps stay with people, which become deterministic code and which need an AI component;
• where approvals and exceptions happen;
• where errors are expensive, which later tells you where a human must stay in the loop.

A good to-be model is already half of the architecture.

Quantify the return on investment

ROI calculations for AI are often too optimistic, because they assume full adoption and perfect accuracy. A realistic calculation includes:

• adoption over time, since not everyone uses the tool from day one;
• accuracy and review effort, since humans still check part of the output;
• running costs: model usage, infrastructure, monitoring and maintenance;
• one-off costs: development, data preparation and change management.

If the business case only works with perfect numbers, it does not work.

Design for the people who will use it

AI that people do not trust does not get used. Design for augmentation rather than replacement, make the AI's reasoning and sources visible, and make its output easy to correct. Adoption is a plan with owners, training and feedback channels, not a launch email.

Agree how you will measure success

Finally, agree KPIs before you build, on four layers: business results (time per case, cost per case), adoption (active users, acceptance rate), AI quality (accuracy, groundedness) and operations (latency, availability, cost per task). Record a baseline and a go/no-go rule for the pilot. Then the decision to scale is a measurement, not an opinion.

Key takeaways

• Define the problem and its cost before choosing a technology.
• Quantify ROI with realistic adoption, accuracy and running costs.
• Agree KPIs, baselines and go/no-go rules in advance.