Category: AI
We Are Making Poor AI Choices
PwC’s 2026 Global CEO Survey asked 4,454 chief executives about their businesses. Of those, 56% said they had yet to see either revenue or cost benefits from AI. Only one in eight reported both.
This is not an isolated finding and 56% is one of the better results.
95% of organizations getting zero return: MIT Project NANDA — The GenAI Divide, July 2025
60% of companies had little or no value to show: BCG — The Widening AI Value Gap, September 2025
70% reported no increase in revenue from AI, and 68% reported no cost savings: OP Pohjola and Accenture — Unlocking AI Value in Finnish Organisations, May 2026
75% had not delivered the expected ROI: IBM Institute for Business Value — CEO Study, May 2025
63% did not report a positive EBIT contribution - McKinsey — The State of AI in 2026, August 2026
The numbers vary but the headline is the same - AI is failing. That is a disappointing result for something that has occupied so much management attention.
There are familiar explanations. The models make things up. The data needs work. Integration turns out to be more difficult than anyone allowed for. These are real problems, but I think we give too little attention to a decision made before any of them arise: what the company chose to use AI for, and what it expected to achieve.
I’ve lost count of the companies that started with a chatbot and later regretted it. At the time, it seemed an obvious choice. Customers ask questions; AI answers questions. Somewhere between those two observations, the business case was assumed rather than worked out. Salesforce is now launching Claudeforce, the fourth iteration of trying to deliver a useable CRM chatbot.
Start by stating the objective
Before choosing an AI application, someone needs to explain what the organisation is trying to accomplish. That sounds obvious. In practice, a faster activity often gets mistaken for the objective.
A software company does not want faster code, it wants to deliver production-grade software sooner. Writing code faster may help, but the code still has to be reviewed, tested, integrated and deployed. If those stages cannot keep up, the company has created a larger queue of unfinished work. Developers can report impressive productivity gains while customers wait just as long for improvements.
The same confusion appears in customer support. Faster ticket closure looks good on a dashboard. The objective of any customer support department though, is to reduce churn and grow annual recurring revenue by giving customers better support. Closing a ticket contributes to that objective when the customer’s problem has been resolved. If the customer has to reopen it, contact someone else or simply give up, the closure metric tells a misleading story. The poster child for this failure is Klarna. After applying AI to customer support and laying off half of the support staff, customer satisfaction data had deteriorated on complex service interactions. The cost savings projected in the original announcement had not fully materialized. The company began rehiring customer service staff to handle the interactions the AI could not manage well.
The earlier measures (closed tickets, faster code) provide evidence of progress. Their usefulness depends on whether they tell us something about the outcome we actually want.
The objective needs to be clear enough that people can challenge the proposed connection. How will faster coding shorten delivery? How will quicker support resolution improve retention? What else has to change before the company sees a benefit?
Until those questions have answers, choosing an AI tool is premature.
Who chose the problem?
Publicis Sapient’s 2026 survey of AI decision-makers found that 47% believe AI can already meet today’s business needs, while 42% say the technology is capable but their organisations are not set up to capture the value.
These are buyers’ assessments, and they suggest that better technology will only take companies so far.
When a project disappoints, the model, vendor and data all come under scrutiny. The original choice of problem deserves the same attention. Who decided this was worth doing? What did they expect to change in the business?
RAND’s research into failed AI projects identified misunderstanding or miscommunicating the problem as the leading root cause. Grant Thornton’s 2026 survey of 950 senior leaders found that competitor moves were the biggest external pressure driving adoption, i.e. FOMO drives more decisions than problem analysis.
It is easy to see how that happens. A competitor announces an AI initiative. Someone raises it at the next board meeting. The executive team is asked what the company is doing, and the pressure to have an answer soon becomes pressure to launch something.
There may be a worthwhile investment in there. But the competitor’s announcement has done some of the work that a business case should have done. (BTW declaring AI first compounds the problem. It creates the mindset that we need to apply AI everywhere).
PwC’s global chairman, Mohamed Kande, attributed the gap to a lack of foundational rigour, pointing to execution, management and leadership. Those responsibilities include stating the objective and deciding which problems stand in the way.
Knowing where the value is
Poor choices often come from two gaps in understanding. One concerns the business; the other concerns AI capabilities.
Start with the business. Once the objective is clear, the next task is to work out what is preventing it from being achieved.
Goldratt’s work on constraints is useful here. Saving time on an activity that does not limit the business may do very little for overall performance. The local improvement can be real while the financial benefit remains elusive.
Consider a company that takes six weeks to turn an enquiry into a signed contract. It wants to win more profitable business. Pricing approvals account for much of the delay, and customers sometimes buy elsewhere while they wait.
That company could use AI to produce meeting notes. Staff might appreciate it, and it might save them time. Meanwhile, deals would still be sitting in the pricing queue.
Working on pricing looks more promising because there is a plausible connection to the objective: customers receive an offer sooner, fewer leave while waiting, and more profitable deals close. That connection still needs testing, but at least the company knows what it is testing.
Even then, identifying the delay does not establish a case for AI. Perhaps nobody has written down the pricing rules, or an approval introduced years ago is no longer needed. Fixing those things might take the cycle from six weeks to six days.
Where a rule will do the job, use the rule. AI needs to earn its place through something the simpler approach cannot do well, such as interpreting large volumes of varied customer requests.
Knowing What AI Can Do
Leaders need to understand what they are buying. In an agentic system built around a language model, the language model is the only part that is AI. An agent may also call other AI tools, but the surrounding machinery, the part that does work, is code, data, scripts, text files and APIs (the harness).
The language model reads information and generates information. That’s it. It can request that a tool be used to provide it with more context but it cannot approve those requests. The surrounding software executes the request, controls access and determines what actions are permitted. Calling the whole arrangement “agentic AI” can obscure how much of the work is being done by conventional software.
Retrieving a customer record, calculating a price and applying an approval rule do not inherently require AI. If those operations deliver the business value, ask what the language model adds. Does the work require interpretation of varied, unstructured requests? Or could a form and some well-written rules do the job?
The language model can generate a plausible answer to your prompt. There is no guarantee that it is the most plausible answer, let alone the correct one. Fluency does not change that. Neither does asking the model to reconsider.
That is a serious distinction when the answer determines what a customer pays, what the company promises or which action happens next.
Ask a model to generate a price and it may give you a convincing number. It may also overlook a contract term, invent a discount or get the arithmetic wrong. A neatly formatted explanation makes none of those errors acceptable.
A sounder design uses the model to interpret the request and ask the pricing engine to calculate the answer. The pricing engine applies the established rules. The model provides a convenient way to interact with it. Even then, the system needs checks that the model has passed the right customer, product and terms.
Consider the company with the six-week quote-to-contract cycle. A chatbot that drafts quotes may simply create work for someone who must check every price and condition. A language interface connected to the pricing and approval systems could remove several steps. A straightforward form might achieve the same result at lower cost.
The objective is faster delivery of an accurate, authorised quote. Whether that needs AI is a design decision that must be justified.
Before approving the investment, leaders should insist on a clear explanation of what the model contributes, why conventional software cannot do that part adequately, and how errors will be caught.
Do you actually need the AI part to deliver the value?
This is why the mantra should be “Deterministic by Default.”
Measure the result you said you wanted
The objective also determines how an initiative should be evaluated.
If the aim is faster production-grade delivery, measure how long it takes to get a change safely into production. Code-writing speed may help explain the result, alongside review time, rework and defects. It cannot stand in for it.
If the aim is better retention through customer support, ticket handling time is only part of the picture. The company needs to know whether problems stay resolved and whether the customer outcomes improve. Churn and recurring revenue have other influences, so any claim that AI caused an improvement needs evidence.
This is where vague objectives become expensive. The team reports time saved. Finance cannot find a corresponding benefit. Both may be right. People might have used the time to absorb growing demand or clear a backlog. They might also have spent it scrolling Tik Tok.
What happened to the capacity matters.
Grant Thornton found that companies pulling ahead were scaling fewer pilots, with better measurement and clearer exit criteria. That gives management a basis for deciding what to continue, change or stop.
In the pricing example, faster quote preparation would be useful evidence. The business case would still depend on what happened afterwards: whether customers received quotes sooner, whether more of them bought, and whether the additional business justified the cost.
What I would ask before approving the next initiative
A board needs a clear account of what an investment is supposed to achieve. I would start with five questions:
What business outcome are we trying to achieve, and how will we measure it?
What is preventing that outcome today, and why do we believe this initiative will address it?
Why does the solution need AI, and what evidence shows it can do the job under conditions like ours?
What else must change in the process for the improvement to reach the customer or the accounts?
What should we learn within ninety days, and what evidence would make us continue, change course or stop?
Those questions should expose a proposal whose ambition stops at producing more code or closing more tickets. They also make it harder to approve a technically impressive application with no clear connection to the business.
PwC’s figures do not tell us why each company has struggled to realise benefits. They should prompt leadership teams to revisit the choices behind their spending.
Before approving another tool, ask the team to state the objective in plain language, then explain how the proposed change gets you closer to it. If the explanation ends at “this task will be faster”, the business case is still unfinished.
