Where AI actually pays off in business software

Enterprise AI spending has been extraordinary and the measurable return has not. That gap is now documented well enough to plan around, and the useful part is not the headline failure rate. It is the pattern underneath it.

What the evidence actually says

MIT’s The GenAI Divide: State of AI in Business 2025 drew on 52 executive interviews, surveys of 153 leaders and analysis of 300 public AI deployments. Its headline finding was that 95% of pilots delivered no measurable profit-and-loss impact, despite global enterprise spending on generative AI reaching $30bn to $40bn.

Treat that 95% as directional rather than precise. It is a modest sample, it measures P&L impact rather than all value, and it has been contested since publication. The finding that matters more is the one that explains it.

We have an obvious interest in that number, so treat it with the scepticism it deserves. The plausible mechanism is not that outside teams are cleverer. It is that an external engagement forces a written scope, a defined success measure and a deadline, and internal projects frequently have none of the three.

You can get the same effect without hiring anyone, by writing down what the system must do, how you will know whether it did it, and when you will decide. Most internal AI projects we see have never had that conversation.

The spending is pointed at the wrong half of the business

The same study found that between 50% and 70% of AI budgets went to sales and marketing functions, while back-office automation delivered the clearer return.

That inversion is worth sitting with. Customer-facing AI is visible, demonstrable and attractive to sponsors. It is also where errors are most expensive, where the output is hardest to evaluate objectively, and where the baseline is a human who is already quite good.

Back-office work is the opposite. Invoice coding, document classification, claims triage, reconciliation, ticket routing. Nobody demos it at a board meeting. The volume is high, the rules are semi-consistent, the error cost is low and recoverable, and there is usually a years-long archive of how humans handled it, which is exactly the training and evaluation data you need.

The three questions that predict whether it pays

Is the decision made often enough? Automating something that happens eleven times a month will not repay the build. The threshold is not a specific number. It is whether the annual hours spent on the decision exceed the cost of building and running a system that makes it.

Do you already hold the data? Not data in general. Records of this specific decision, with the outcome attached. If nobody has ever written down which answer was correct, you have no training signal and no way to evaluate the result, and you will be shipping on vibes.

Can you tolerate being wrong sometimes? This is the one that quietly kills projects. If the process requires the right answer every time, you need a rules engine, a human, or AI as a first pass with human review, and the economics of that last option are different from full automation. Decide which of the three you are building before you start.

Where it reliably pays

• Extracting structure from documents. Invoices, contracts, forms, reports. High volume, tolerant of review, and the correct answer is verifiable.
• Routing and triage. Getting a ticket, claim or enquiry to the right place. Being wrong costs a re-route, not a customer.
• Search over your own material. Letting staff ask questions of internal documentation that nobody can otherwise find. Measurable through time saved.
• Drafting where a human always reviews. First-pass responses, summaries, reports. The human stays accountable and the time saving is real.
• Flagging anomalies. Surfacing the unusual for a person to look at, rather than deciding what to do about it.

Where it usually does not

• Anything requiring an exactly correct answer every time. Payroll, tax calculations, regulatory limits. Use deterministic code.
• Decisions with no recorded history. No archive means no evaluation, which means no way to tell improvement from noise.
• Low-volume, high-stakes judgement. The build cost cannot be recovered and the error cost is high.
• Replacing a process nobody has mapped. If the current workflow is undocumented, the first job is discovery, not modelling.
• Anything whose success cannot be stated as a number. If you cannot say what good looks like, you cannot tell whether you got it.

How to find out cheaply

Before committing to a build, run a time-boxed evaluation against your own data. Take a sample of real historical cases where the correct answer is known. Run the candidate approach over them. Measure accuracy against that known answer, and measure the cost per decision at your real volume.

That exercise ends with three numbers: how often it is right, what it costs to run, and what the failure mode looks like when it is wrong. With those, the build decision makes itself. Without them, you are choosing on enthusiasm, which is what the 95% figure is measuring.

This is how we approach AI work: the feasibility phase is fixed-price and time-boxed, and concluding that a project should not proceed is a legitimate and inexpensive outcome. There is more on our AI and machine learning page, and the same logic applied to conventional builds in what actually happens in a discovery phase.

If you have a candidate use case and want an outside read on whether it will pay, describe the decision you want to automate.