Gartner’s latest forecast puts worldwide spending on AI at $2.7 trillion in 2026, up almost 50 per cent in a single year. It is the number on every board slide about AI. Most of it is not the kind of spending a board means when it asks what AI is doing for the business.
Read the forecast line by line and a different picture appears: where the money is going, why so many projects funded with it stall, and what an enterprise budget should buy if it wants a return rather than a demo.
Follow the money
More than half of the forecast, $1.48 trillion, is AI infrastructure: AI-optimised servers, chips, networking and devices. Gartner names the data-centre capacity being bought by hyperscalers and service providers as the largest single area of spending, and describes the build-out as the largest infrastructure project humanity has undertaken. That is real money, but most of it is spent by the companies that sell AI capacity, not by the companies that use it.
The next two lines are where enterprise budgets show up. AI services account for about 22 per cent and AI software for about 17 per cent, and the software line is mostly AI being added to products enterprises already own. Vendors are embedding agentic features into existing applications, and enterprises are switching them on.
Two sentences in the same release describe the shift precisely. Enterprises, Gartner says, are turning to service providers “less often to help them manage the business transformation, and more often for the smaller indirect projects to exploit AI features of their incumbent software”. And the risks of lock-in, data sovereignty and runaway costs “are not deterring buyers”.
At the bottom of the table sits a line the forecast calls AI data. In 2026 it is $3.1 billion: roughly one dollar in every $850. The category is narrow, and much data work hides inside the services and software lines, so it is not the whole story. But the shape is clear. The money is following compute and features. Very little of it is aimed, by name, at the data those features run on.
What switching on features buys, and what it doesn’t
Turning on the AI in software you already own is not a mistake. It is quick, it is cheap relative to building, and inside one application it often works well: a better draft of a sales email, a summary of a support ticket, a forecast in the planning tool.
The limit is the edge of the application. Each vendor’s assistant sees that vendor’s data and that vendor’s definitions. Ask three of them what revenue was last quarter and you can get three answers, each correct by its own system’s rules. Ask any of them why orders are late and none can answer, because the order’s journey crosses the CRM, the ERP, the warehouse system and finance, and no single feature sees all four.
That is where most of the value in an enterprise sits: in the decisions and processes that cross systems. It is also exactly what a budget made of embedded features does not reach.
Where AI projects stall
The evidence on why projects fail points at the same gap.
- Data readiness. In a survey of 1,203 data management leaders, 63 per cent of organisations said they either do not have, or are unsure whether they have, the right data management practices for AI. Gartner predicts that through 2026, organisations will abandon 60 per cent of AI projects unsupported by AI-ready data.
- Cost, value and control. Gartner also predicts that over 40 per cent of agentic AI projects will be cancelled by the end of 2027, “due to escalating costs, unclear business value or inadequate risk controls”.
- Return and running cost. In McKinsey’s 2026 survey of 1,719 respondents, 37 per cent attribute any EBIT impact to AI, and only 6 per cent qualify as high performers, the same share as a year earlier. One in five say their organisation is limiting AI use because of operating costs, tokens included. What sets the high performers apart is not the model: nearly three-quarters have fundamentally redesigned workflows, against one-quarter of the rest, and they are twice as likely to have defined processes for measuring impact.
Read those three reasons again: costs that escalate, value that is unclear, controls that are inadequate. None of them is a model problem. Costs escalate when nobody measures what each successful outcome costs. Value is unclear when there is no agreed baseline and no agreed definition of the number that is meant to move. Controls are inadequate when nobody can see what the AI actually did, step by step, against what it was supposed to do. Each is a gap in the foundations, not in the model on top.
What is worth funding
Three foundations decide whether an AI budget produces a return. None is new, none is glamorous, and all three are reused by every use case that follows, which is why they are the best-value line in the budget.
1. A governed data foundation
Pipelines that deliver the data every day, not just for the pilot, with lineage that can be audited, quality checks that run before a model sees the data, and access rules that travel with it. Built once as data products, so the third use case inherits what the first one paid for. This is the ground the data estate is built on, and governance is what keeps it trustworthy.
2. A shared semantic layer
One definition of revenue, margin, on-time delivery and active customer, held in one place, which every dashboard, model and agent reads from. Without it, AI multiplies disagreements: every assistant computes its own version of the number, confidently, and the meeting becomes an argument about whose figure is right. With it, a question asked in plain language returns the same answer the finance team would give, because it comes from the same definition. McKinsey’s survey tracks this directly: having “a semantic layer and/or knowledge graph for the company’s data” is one of the practices on which its high performers score ahead of the rest.
3. Live process context
The event history of how work actually flows: where each case is, how long it has been there, what normally happens next and what is already late. This is the layer most AI programmes skip, and it is the one that answers all three cancellation reasons at once. It gives the baseline that makes value measurable: cycle time, cost per case, rework rate, before and after. It gives the cost of each successful outcome of an agent, not just a monthly token bill. And it gives the control: every step an agent or a person takes is checked against the designed route, in the same log. It is also the context an agent needs to act on a real case rather than on a procedure document.
A test for every AI line item
Before an AI item is funded, four questions separate capability from features:
- Which decision or process step does it change, and what is that step’s baseline today? Time, cost, error rate. If nobody knows, the value will be unclear by design.
- Which definitions does it depend on, and do they live in one place? If the answer is “in the vendor’s application”, the second use case will start again from scratch.
- What will each successful outcome cost to run? Including tokens, tool calls, the time people spend checking and correcting, and the rework downstream.
- What do we keep if the vendor or the model changes? Data products, definitions and process models survive a change of model. Prompts tuned to one product mostly do not.
Items that answer all four are building capability. Items that cannot are buying features, which can be fine, as long as the budget knows the difference.
Where to start
Do not start by rebalancing the whole AI budget. Start with one process where AI is already being bought or piloted: order-to-cash, procure-to-pay, claims, onboarding. Map it from its real event data, take the baseline, agree the definitions it depends on, and fund those foundations for that one process first. The next AI investment in the same area then starts from measured ground instead of a slide.
If the process runs on systems that already record what happens, the readiness check takes five questions. A two-week pilot then maps it from your real data and shows where AI would move the numbers, and where it would only make an existing problem run faster.