Using AI in Your Business: Start From the Problem, Not the AI

"Where should we use AI?" is a backwards question

The direct answer first: most AI projects that fail to pay off don't fail because the technology wasn't good enough. They fail because they started from the tool instead of the problem. Once you start from "we need AI", the next question becomes "where can we put it" — which is finding a home for a tool, not finding a fix for a problem.

The common shape is a team builds an impressive demo, leadership is pleased, and three months later nobody uses it. What was built didn't change anyone's decision. It demonstrated that something was possible, which is not the same as making work better.

The question that works is not "where should we use AI?" but "which work in this business is slow, expensive or frequently wrong enough to be worth fixing?" Answer that and whether AI belongs follows on its own — and often the answer is that it doesn't.

Four questions to answer before approving budget

First: what decision does this work drive? If the system produces an answer and nobody does anything differently, it isn't work worth investing in yet. A system that gives good answers nobody acts on is just a more expensive report.

Second: what does being wrong cost? AI does not get every answer right, and never will. Work where a mistake costs a few minutes and work where a mistake pays the wrong supplier are entirely different propositions. This question determines whether a human has to check the output before it is used.

Third: does the data exist, and is it in usable shape? Data spread across differing spreadsheet versions or typed by hand without a standard needs tidying first — and the tidying is usually a bigger job than the AI.

Fourth: how would you solve this without AI? This matters most and gets skipped most. A great deal of work is fixed by changing a process, designing a better form, or writing ordinary rules — cheaper, faster, and far easier to explain to an auditor.

Where AI genuinely helps, and where it shouldn't decide

AI does well on work that is high in volume, loose in format, and tolerant of occasional error: summarising long documents, grouping large numbers of customer questions, drafting a first version for a person to edit, or pulling fields out of documents that never arrive in the same layout. This work used to consume a lot of human time and never demanded accounting-grade precision.

What it shouldn't decide alone is work that must be right every time, must be explainable, or carries direct legal and financial consequence — tax calculation, credit approval, medical diagnosis, or figures filed with a government agency. AI can assist here, but a named person still signs.

The line that holds up in practice: if the system is wrong once in twenty, can you live with it? If yes, AI probably fits. If no, design a human check into the flow — or accept it isn't AI work yet.

The costs people forget when setting budget

Initial development is usually the smallest line. What gets missed is preparing the data, evaluating answer quality systematically rather than trying it a few times and feeling good about it, and paying people to check output during the early period.

The other invisible cost is per-call spend. A system a few people press a handful of times a day and one fired automatically on every transaction differ by orders of magnitude over a month. Estimate real usage up front, not trial usage.

The most expensive cost is having to tear it out later. A system with AI wired into every step from day one is hard to remove once it turns out not to pay, because it has become part of how work is done. Designing it to be removable is always cheaper.

How to start without betting the budget

Start with one measurable job. Pick work with a clear time cost today — three staff spending two hours a day keying data off purchase orders. Numbers like that let you answer whether it paid, rather than guessing.

Set the success and abandonment criteria before you begin, written as numbers on day one. Teams without an abandonment criterion keep unsuccessful projects alive far too long, precisely because so much has been spent.

Keep a person in the decision loop early. Let the system propose and a person confirm, then track how often the answer is corrected and where. That record is worth more than any demo, because it tells you whether the system is ready to work unattended.

And build it to come out. If month three shows it isn't paying, you should be able to switch it off with the original process still running. That is the difference between a controlled experiment and a bet.