What Business Problems Are Actually Suitable for AI?

Start with the work, not the model

Most AI projects that disappoint start with a technology choice: “we should use AI for something”. A team picks a model or a tool, then goes looking for a problem it might solve. The result is usually a demo that impresses in a meeting and is quietly abandoned a few months later.

The projects that work start the other way round. They begin with a specific piece of work that is slow, inconsistent, expensive or hard to scale, and then ask what would actually fix it. Sometimes the answer is AI. Often it is not, and finding that out early is just as valuable.

This article sets out a practical way to tell the difference, so that time and budget go to the problems where AI genuinely helps.

Every problem has three possible answers

When a piece of work is causing friction, there are broadly three ways to improve it. It is worth naming all three before anyone mentions a model.

• Change the process. Many problems come from unclear ownership, missing handovers, duplicated effort or steps nobody remembers the reason for. These are fixed by agreeing who does what, not by software.
• Write conventional software. If the work follows rules that can be written down, such as calculations, validations, routing or moving data between systems, conventional automation does it exactly, cheaply and predictably.
• Use AI. If the work involves reading, interpreting or producing language, documents or other unstructured information, and the variation is too great to capture in rules, AI can help.

Real workflows usually need a mix. The aim is to give each step the simplest approach that works reliably, and to reserve AI for the steps where nothing simpler will do.

Signs a problem suits AI

No single signal decides it, but problems that suit AI tend to share several of these characteristics.

• The inputs are unstructured: emails, documents, notes, free text, transcripts or conversations.
• The task needs interpretation, such as reading, summarising, classifying, extracting or drafting, rather than a fixed calculation.
• It happens often enough that time saved adds up across a team or a year.
• A person can check the output, and a mistake can be caught before it causes harm.
• Good examples of the work already exist, so you can show what “right” looks like and test against it.
• The information needed to do the task is available and the business is allowed to use it.

The strongest candidates combine high volume with high variation: lots of incoming material that people currently read and interpret by hand, where each item is slightly different from the last.

Signs it does not

Equally, some signals suggest AI is the wrong tool, or that it would only be treating a symptom.

• The rules are known and fixed. Write them as rules; they will be faster, cheaper and easier to audit.
• The answer must be exactly right every time and there is no opportunity for a person to check it.
• The data does not exist, is not trustworthy, or nobody is allowed to use it for this purpose.
• The real issue is a missing process, unclear ownership or a broken handover between teams.
• The work happens so rarely that building and maintaining a system costs more than doing it by hand.
• Nobody can describe what a good result looks like, so there is no way to tell whether the system is working.

In these cases AI adds cost and uncertainty without solving the underlying problem. It can also hide that problem for a while, which makes it harder to fix later.

A simple test

Describe the task to a capable new colleague who knows nothing about your business. Then ask what they would need in order to do it well.

• If they could do it from written instructions and a few good examples, and you could check their work, it is a reasonable AI candidate.
• If they would need a precise rulebook and would never need to use judgment, it is a software problem.
• If they would first need someone to decide who owns the work or what the process should be, it is a process problem.

This test works because current AI systems behave, in useful ways, like a fast new colleague: good at reading and drafting from examples, unreliable without clear instructions, and in need of someone to review their work while trust is established.

Scoring a shortlist of ideas

Most organisations can list a dozen possible AI uses in an afternoon. To choose between them, score each candidate against a small set of questions rather than picking the most exciting one.

• Frequency: how often does this work happen, and how many people do it?
• Effort: how much time does each instance take today?
• Variation: how different is each instance from the last? High variation favours AI; low variation favours rules.
• Checkability: can a person verify the output quickly, and is there a natural point to do so?
• Cost of error: what happens if the output is wrong and nobody notices?
• Data: is the information needed available, current and permitted for this use?
• Ownership: is there a team that owns this work and wants it improved?

A candidate that scores well on frequency, effort, variation and checkability, with a manageable cost of error and a willing owner, is usually a better first project than an ambitious idea that touches everything.

Typical candidates and non-candidates

The categories below are illustrations, not guarantees; every case still needs testing with real examples. But they show the pattern.

Work that often suits AI:

• Reading incoming emails or requests and preparing a structured summary for the person who acts on them.
• Extracting key fields from varied documents such as contracts, invoices or forms that arrive in different layouts.
• Answering staff questions from approved policies, procedures and product documentation, with sources shown.
• Drafting first versions of routine responses, reports or descriptions for a person to edit.
• Classifying and routing free-text tickets or enquiries.

Work that usually does not:

• Calculating prices, tax or payroll from known rules.
• Moving data between systems that already have structured fields.
• Routing approvals based on fixed thresholds.
• Making final decisions with legal, financial or safety consequences without review.

Choosing a first project

Pick one workflow that is frequent, measurable and contained. A narrow first project teaches you more, faster, than a broad one, and it builds the trust needed for the next step.

Before building anything, agree what “better” means in business terms, such as time per case, turnaround time, consistency or the share of cases that need rework. Record the current baseline so there is something to compare against.

Then test the riskiest assumption with real examples. Usually that assumption is about quality: can the system handle the actual variety of inputs your team sees? A small evaluation on genuine cases answers that question far more reliably than a polished demo on hand-picked ones.

A good assessment can conclude that AI is not the right answer. That is a useful result. It saves the cost of building the wrong thing and often points to a simpler fix.

Common mistakes to avoid

• Starting from a tool or model rather than a problem.
• Choosing the most visible idea instead of the most valuable and testable one.
• Testing only on clean, friendly examples.
• Removing the human check before the system has earned trust.
• Using AI to paper over a process that nobody owns.
• Skipping the baseline, so there is no way to show whether anything improved.

Questions to answer before you start

• What specific work are we improving, and who does it today?
• Which steps are rules, which need interpretation, and which need judgment?
• What does a good result look like, and do we have real examples of it?
• Who will check the output, and at what point in the workflow?
• What data does it need, and are we allowed to use it?
• How will we measure success against today’s baseline?

If those questions have clear answers, the problem is probably ready for a focused AI assessment. If they do not, answering them is the first piece of work, and it is valuable whichever way the decision goes.