There is a fundamental problem hiding behind today’s technology forecasts: the technology industry is projecting spending growth at rates that many of its customers cannot economically sustain.

Gartner’s July 2026 forecast calls for worldwide IT spending to increase 14.2% in 2026 to $6.37 trillion. Within that number, software is projected to rise 15.5%, Infrastructure-as-a-Service 29.3%, and data-center systems an extraordinary 62.5%. Gartner itself acknowledges that technology budgets are being strained by inflation, supply shortages, hardware and memory costs, and AI investment.

The AI projections are even more dramatic. Gartner’s September forecast puts 2026 worldwide AI spending at $2.7 trillion—up 49.5% in a single year. McKinsey has separately estimated that generative AI alone could drive $175–$250 billion of software spending by 2027, adding two to six percentage points to software-sector growth.

These are extraordinary numbers. But they expose a fundamental flaw in the way the technology market is being viewed: The forecasts measure what the technology industry expects to sell—not necessarily what its customers can afford to buy.

That distinction is critical.

The forecasts may describe what technology suppliers want to sell, what hyperscalers intend to build, and what analysts believe enterprises will demand. They do not demonstrate that the typical enterprise has the economic capacity to increase its technology budget at anything approaching those rates.

That is the collision illustrated in this cartoon. Most companies cannot indefinitely grow technology spending at 10%, 15%, 20%, 30% or even 50% when their revenues, operating margins and the economies in which they operate are growing at only a fraction of those rates.

And the affordability problem is actually worse than the headline spending forecasts suggest.

Enterprises simultaneously face the economic headwinds: IT inflation; AI premiums; rising compute, server and memory costs; cybersecurity; energy and datacenter requirements; technical debt; scarce technology talent; software and cloud price escalation; regulatory and control costs; and the continuing expense of maintaining yesterday’s technology while financing tomorrow’s.

The result is what I call the Technology Affordability Gap: Technology demand + technology inflation + AI investment + infrastructure requirements are growing faster than the economic capacity of many enterprises to pay for them.

This produces an extraordinary paradox. Every technology forecast can appear individually plausible from the supplier’s side while their collective implications become economically implausible from the customer’s side.

A hyperscaler can forecast enormous cloud growth. An AI company can forecast enormous AI adoption. A software company can forecast higher subscription revenue. A semiconductor company can forecast explosive demand for AI infrastructure. An analyst can add all of those expectations together.

But ultimately there is only one customer balance sheet paying the bills.

Something, therefore, has to give.

Enterprises will have to slow spending, eliminate legacy costs, consolidate vendors, renegotiate contracts, defer lower-value projects, substitute AI and automation for labor, radically improve technology productivity, and demand demonstrable economic returns from AI and other technology investments. Otherwise, technology spending will increasingly have to be financed by taking money away from other parts of the enterprise— or by sacrificing margins.

That is the impending Technology Economic Crisis.

It is not a crisis caused by a shortage of technology. It is potentially a crisis caused by more technology ambition, more technology supply and more technology spending expectations than the underlying economy can afford.

The question for 2027 and beyond, therefore, isn’t simply: “How much technology will companies want?”

It is: “How much technology can they actually afford?”

An executive IT dashboard can stay green for a year while the risks it is supposed to surface keep growing. Availability above target every month. Service levels met. Patch compliance climbing quarter over quarter. Every number accurate, and every one trusted by the executive team.

When trouble finally arrives, it skips amber entirely. It comes as an outage, an audit finding or a security incident, and the first question in the room is why the dashboard said everything was fine.

In my work with technology leaders and executive teams, I have learned that a dashboard can be technically accurate and still leave leadership dangerously misinformed. Usually nobody fudged anything. The numbers were built to summarize, and a summary is very good at hiding the one thing an executive most needs to see. Three metrics produce most of that false comfort at the executive level. I would not put any of them in front of a CEO or a board as a headline number.

Three green numbers I would take off the executive dashboard

Monthly availability is the classic. A 99.9 percent month still allows about 43 minutes of downtime, and the percentage says nothing about when those minutes fell. Forty minutes at 3 a.m. on a Sunday and forty minutes during month-end close produce the same number. So do one long outage and a dozen short ones that each forced the order desk to restart its work. CIO.com made a version of this case years ago, arguing that uptime means little until it is tied to business impact. Business leaders notice the gap. When the official figure does not match what their teams lived through, the dashboard loses the room, and nobody tells the CIO.

Service-level attainment is the second. A service desk can hit its resolution targets month after month while the same problems keep coming back. A recurring sync failure gets fixed in twenty minutes, closed inside the target and counted as a success. It happens again the following week and gets counted as another success. The metric rewards fast closure, so the organization gets very good at fast closure, and the underlying fault never draws enough attention to be fixed. What builds underneath is a growing list of known problems held together by workarounds. Each one is a small daily cost to the business and a much larger risk the day the person who knows the workaround leaves.

Patch compliance is the third, and the most dangerous, because it expresses security posture as a percentage of a device count. A fleet that is 96 percent patched sounds well defended. The question the percentage cannot answer is which 4 percent. The unpatched remainder is rarely random. It is the legacy system nobody is allowed to reboot, the vendor-managed appliance the team cannot touch, the server behind a process considered too important to risk. Those are often the assets an attacker would pick first. The headline number improves every quarter as the easy devices get patched, while the exposure that matters sits unchanged on an exceptions list nobody above the security team reads.

Why averages flatter the people who report them

Each of these metrics averages across a large population where the risk is concentrated in a small corner. The thousands of healthy devices, the hundreds of quiet hours and the routine tickets all pull the number toward green. The handful of things that could actually hurt the company barely move it.

Executive dashboards drift toward this kind of measure for understandable reasons. Percentages are stable, they trend nicely and they compare cleanly against a target. They also protect the team producing them, which is the part few people say out loud. A metric that is green almost every month spares everyone a hard conversation. Over a few years, without anyone deciding it, the dashboard selects for numbers that do exactly that. One question exposes it quickly: when did the executive dashboard last show a red month? If nobody can remember, or nobody can say what it would take to produce one, the dashboard has stopped measuring the organization and started reassuring it.

The cost lands when something breaks. A CIO who reported green for eleven straight months and then has to explain a major incident is answering two questions at once: what went wrong and why the reporting missed it. The second question is the one executives remember, and it colors how they read every report that follows. After that, a green month is no longer taken at face value.

I hold every executive metric to one test. If a number cannot embarrass me, it does not belong on the dashboard.

What I would put in front of executives instead

The replacements are less flattering and more useful. There are three I would choose.

1. Disruption minutes on the processes that matter. It starts with an agreement with business leaders, made in advance, on a short list of processes their teams cannot run without and the windows when those processes matter most: order entry during business hours, payroll in the days before a run, financial systems at close. Then the dashboard reports minutes of disruption to those processes during those windows, and every incident behind the number is listed by name. A quiet month looks quiet. A bad Tuesday during close shows up as exactly what it was, and the business leaders in the room recognize it because they lived it.
2. Repeat incidents. Of everything that broke this month, how much had broken before? I would trade every resolution rate on the dashboard for this one number. A low repeat rate means problems are being fixed at the root. A rising one means the organization is living on workarounds, and it shows up months before the workarounds start to fail in ways that customers notice.
3. The age of the worst exposure. For security, the measure I want to see is the oldest unremediated critical vulnerability on systems that face the internet or hold sensitive data, along with the number of standing exceptions and the name of the executive who approved each one. The age moves only when the hard cases get fixed, which is the point. An exception with an executive’s name on it is far more likely to get a decision: fix it or own the risk. An exception that belongs to nobody can sit indefinitely.

Each replacement shares three properties. Its red threshold is agreed before the reporting period begins, so nobody negotiates it after the fact. It points at a specific process or system, so a red result tells an executive where to look. And it is uncomfortable enough that the team would rather fix the underlying issue than explain the number again next month.

The old percentages still have a home. They stay on the operations team’s internal dashboards, where they help run the shop day to day and where a team lead can see a trend early. The executive view gets the measures that can turn red.

None of this requires new tooling. Most IT organizations already capture the incident history, the vulnerability data and the process calendar these measures depend on. What it requires is a decision about what the executive team is entitled to see, and the willingness to show a red month before something forces it.

The first report built this way will almost certainly show red somewhere, and that is the reason to build it. A red month is uncomfortable for a meeting or two. It also sharpens the questions, turns the conversation to the actual condition of the systems the company runs on and ends the CIO’s role as the person who said everything was fine. A dashboard that has been green for a year might be telling the truth. From the top, there is no way to know, and that is reason enough to change what goes on it.

According to a quartet of Accenture intellectual heavyweights, what CIOs need now to account for and control AI costs is tokenomics, sweet tokenomics.

The idea of linking AI spend to business outcomes may be a noble one, but “Tokenomics” only pretends to do so, unless you think tallying costs and measuring business outcomes are one and the same thing.

But before we get to Tokenomics we need to set the stage.

Start with Function Point Analysis (FPA), a venerable and mostly forgotten discipline, which should say something about its efficacy.

The folly of cost metrics you can’t understand

Back in the day, IT leaders worried that boards of directors worried that business executives worried about the cost of information technology and how to manage it.

IBM introduced Function Point Analysis in 1979 to solve this issue by breaking a software application into chunks — function points. Analysts could then sum these function points to compare the application’s overall complexity — and therefore its cost and risks — with that of any other piece of software.

When presented with the number of function points a proposed software project would require, your average, hopelessly naïve business leader asked IT to point to a few of the project’s function points, expecting mocked-up screenshots, sample reports, and so on.

Sadly, IT had to decline because, the design analysts would explain, a function point is (as Google’s AI Overview explains) “an abstract, synthetic unit of measurement rather than a physical object or a single piece of code.”

The Function Point Analysis value proposition, then, was that business leaders could manage IT costs and risks better by relying on cost metrics they couldn’t understand.

Function points for the AI era

Fast-forward to today, and the equivalent function-point cost metrics for AI are tokens — the chunks of text that a large language model reads, processes, and generates. Which, in case you missed the briefing, supposedly makes tokenomics a way to manage the costs and risks of AI.

As the aforementioned Accenture gurus “explain” (scare quotes intended): “Enterprise AI is creating a new cost of doing business: tokens. As consumption scales, token economics is becoming a material risk and opportunity, drawing increasing attention across the C-suite and the board.”

Which raises the question: Where are our tokenomics pundits finding C-suite and board members who give even an infinitesimal damn about tokens? They’re probably the ones who still pay attention to function points, too.

A short lesson in Brickonomics

But before we delve deeper into Tokenomics, capital T, we need to understand building maintenance and the critical role Brickonomics plays in it.

It’s like this: Brick walls are made of bricks. So if a brick wall needs attention, a building management project estimator should need to understand the costs and risks associated with managing a standard brick in the crumbling wall they’re supposed to fix. Multiply the standard management cost of a standard brick (a brickon?) by the number of bricks in the wall, and voilà! Building management knows …

Well, it knows less than it would have if had it instead invested in a conventional tuckpointing analysis. Among the missing pieces: In tuckpointing analysis, what usually needs and gets attention is the mortar between the bricks, not the bricks themselves.

Putting it all together — because you will have to

Now we’re ready for Tokenomics, and its conjecture that dividing an LLM into tokens and assigning a cost to each of those tokens will prove more useful than dividing software into function points or a wall into individually managed bricks.

The next questionable aspect of Tokenomics is that it depends on the proposition that all AI implementations are built on large language models or similar architectures.

To be fair, Tokenomics doesn’t have to be limited to analyzing LLMs. It can be adapted to any collection of thingies that’s composed of chunks that can be parameterized.

But that really isn’t good enough, is it? Because given the current pace of AI innovation, assuming that anything about it is stable, especially that its future core architecture will be tokenizable, is a shaky assumption at best.

It’s a mortar versus bricks challenge.

Then there are those pesky function points. Just because AI is involved in an implementation, that doesn’t mean software isn’t also involved. Which would seem to suggest that Tokenomics will have to integrate Function Point Analysis into its methods and practices as well.

Imagine you’re the one who has to explain this mess to those boards and business leaders who are, supposedly, clamoring for it. Because, as CIO, you will be.

Chargebacks and culture

We haven’t even gotten to the other big risk of Tokenomics: that it focuses decision-makers on AI’s costs, with only token attention — no pun intended — paid to its benefits.

Deep down inside, Tokenomics’ value depends on its use for chargebacks and showbacks. The logic for imposing these is superficially appealing — it makes business owners take responsibility for the AI spend driven by their consumption.

Those CIOs who dove into the chargeback rabbit hole discovered just how futile chargebacks can be. That’s because of a time-honored practice updated to the digital age: arguing about the bill.

Because that’s all a chargeback is: a bill. It’s a statement of how much money will change hands so that someone who has provided a good or service is reimbursed for the value they’ve created.

By the numbers: (1) a chargeback is a bill; (2) the point of Tokenomics is to support chargebacks; and (3) no business leader will be able to understand the bill they’re supposed to pay given Tokenomics impenetrable vocabulary and construction.

But what about showbacks, then? Letting business leaders understand the costs they’re driving would seem harmless and potentially useful.

And in fact showbacks can be harmless and useful, so long as they’re applied in the right business culture. That’s a culture in which managers consider themselves to be leaders of the whole company, basing their AI utilization decisions just as they base their other decisions — on the extent to which they benefit the whole company.

With a culture like this, IT can limit its application of tokenomics, little t, to its technical architecture practices. This way, the CIO can inform business managers of AI’s costs just as the CIO informs business managers of the other costs of running IT.

Where, the business manager might ask, did these cost numbers come from?

“You have two choices,” the CIO might reply. “You can trust me, or I can explain it to you.”

Now there’s a threat worth paying attention to.

Last year, my company decided to rebuild our enterprise AI platform, which our customers had been using for over a decade. But instead of simply updating it, we started over with a different ambition: to build an AI-native platform using AI.

Using AI to rebuild a platform of that size gave us first-hand experience with AI economics. We employed AI throughout the entire engineering process to write code, review changes, generate tests and accelerate development. It helped us reduce years of engineering to just a few months but also forced us to keep close watch over every single token we consumed and truly consider why we were consuming it.

This experience challenged one of our key assumptions: It turns out that token consumption is influenced as much by architectural decisions as by choice of model.

What token sprawl actually looks like

Indeed, we found that most of the token consumption waste wasn’t due to complex engineering tasks, but the architecture around them; this is something that is referred to as the architecture tax in enterprise AI.

Recursive agents kept spawning subtasks and subagents, and although they technically completed every task, each handoff introduced new prompts and context. Furthermore, frontier reasoning models were being wasted on routine classification tasks that deterministic code could have completed at a fraction of the cost. And, because we hadn’t clearly defined ‘success,’ retry loops continued firing and burning tokens to chase marginal gains, instead of improving business outcomes.  Finally, we experienced context inflation, with workflows carrying information from earlier steps long after they had stopped contributing to the decision being made.

None of these decisions seemed expensive in isolation. Things like a few extra prompts, an unnecessary reasoning step or a larger context window barely impacted the cost of a single workflow. Across millions of executions, however, they grew into a level of token consumption that no model upgrade alone could offset.

Designing for token efficiency

Once we figured out where all our tokens were going, we had to determine how to spend them more deliberately.

First, we accepted that not every step in an AI workflow needs the same amount of intelligence. Some tasks legitimately require reasoning, but others are structural, deterministic or repeatable, and are better handled through software, business logic or tools that are reused rather than reasoned through every execution.

Even when a model is required, not all tasks need the same amount of reasoning. This concept is better known as Reasoning Effort Optimization. If you’re designing systems, exploring alternatives or making difficult decisions, high reasoning effort has value. However, once you’ve established the approach, you can usually produce the same outcome with far less reasoning.

It’s comparable to organizations that structure work as a pyramid of expertise. The most experienced engineers tackle the most difficult problems, make important architectural decisions and handle any ambiguity that arises. Then, once their work is complete, they split it into small, well-defined tasks that other engineers and machines can execute consistently.

Allocation is only part of why this works, though; persistence is equally important. A senior engineer’s judgment gets built into interfaces, schemas and conventions, allowing everyone downstream to build on those decisions without having to derive them again. The same applies to AI systems. If you fail to capture their reasoning as a durable artifact like a graph, specification or compiled skill, the system repays for it every single time it runs.

We apply the same principle to AI systems. Advanced reasoning should only be used when judgment is required. Smaller models can handle well-defined implementation work, and deterministic software and reusable tools can execute tasks where the outcome is already known. The goal is to apply the right level of intelligence to each stage of the workflow.

Architect once, inherit everywhere

So, how much of an AI system should teams rebuild for every new workflow?

In our experience, very little. Architectural capabilities like evaluation, orchestration, guardrails, context management and auditability aren’t unique to a single AI application; every enterprise AI system eventually needs them. Rebuilding them for each workflow is a waste of time and money that forces every AI system to solve the same infrastructure problems independently.

It’s much more efficient to move these capabilities into a common harness. Orchestration, governance and evaluation can then be developed, tested and improved at the platform level rather than separately inside every workflow. Each new AI system can reuse this foundation while teams focus on the business logic that makes the application distinct.

This architectural discipline extends to the execution layer. The amount of computation an AI system performs before producing an outcome depends heavily on the context provided, how its instructions are designed and how its agents are structured.

A 2026 study found that consolidating three or four agents into a single call reduced token consumption by 53.7% and latency by 49.5%, with comparable accuracy. Most of these savings came from not repeatedly passing the same context between agents.

The study also demonstrated that, as the number of tasks assigned to each agent increased, the agent became less reliable at choosing the best way to approach each task. However, increased routing helped recover much of that performance. In short, AI efficiency depends on how the work is structured and routed, not just how many agents are involved.

Optimize throughout the lifecycle

Building the right architecture creates the foundation for continuous optimization.

Model selection, for example, shouldn’t be a one-time decision. As models improve and workloads evolve, it’s worth re-evaluating every AI workflow to determine whether the same outcome can be achieved with less reasoning and lower cost. Demonstrating that system design can outweigh raw model capability, Andrew Ng, a computer scientist, AI entrepreneur and Stanford University adjunct professor, highlighted that while zero-shot GPT-3.5 scored 48.1% on the HumanEval coding benchmark and GPT-4 scored 67.0%, wrapping GPT-3.5 in an iterative agentic loop pushed its score to 95.1%.

The same applies to cost visibility. Token economics should be visible across every workflow, model and task so teams can identify ways to reduce costs before they accumulate.

AI is much less expensive than it used to be, but lower costs encourage more use. Organizations can run more workloads and take on more ambitious problems, so it’s even more important to know where the AI is actually creating value.

Allocate intelligence by the value it creates

Most organizations start with fixed token budgets, because they are easy to administer. However, not every AI task has the same value.

Think about AI as an engineering resource, rather than a shared utility. The teams that consistently choose the right model for the right task and avoid unnecessary reasoning should get more compute because their tokens are producing better outcomes.

Over time, I expect enterprises to manage AI the same way they manage any scarce engineering resource — by using it where it has the greatest impact.

Every CIO can produce an AI adoption dashboard: licenses purchased, seats activated, prompts submitted per week. Boards ask for these numbers, vendors report them and they climb every quarter. What none of them show is whether the tool earned a durable place in anyone’s work.

A license counts distribution, not value. An activated seat tells you someone clicked through onboarding once. A prompt count rewards the person who tried a tool five times before giving up exactly as much as the person who uses it daily and depends on it.

Most CIOs concede that much, yet little better has replaced it. Across the C-suite, only 31% of leaders expect to measure generative AI’s return on investment in the next six months. In most boardrooms, adoption metrics are not supplementing ROI; they have replaced it.

Worse, these are usually not your numbers. In most SaaS deployments, the vendor defines the usage metric, instruments it and reports it back in business reviews. That is standard commercial practice rather than bad faith, but it means the criteria behind the number are built to justify license utilization rather than audit your workflows.

The metric that actually shows whether an AI tool works is the one missing from the dashboard: abandonment. It tells you who tried a tool and walked away, how quickly they stopped and where the workflow broke down.

Abandonment is not a vanity metric in reverse. It is the one signal your people produce rather than your vendor. Every day someone decides whether to open the tool, paying in attention and habit. Continuing to pay that cost is a judgment; walking away is the opposite judgment. Nobody fakes that behavior for a dashboard.

Three patterns, three problems

Not all abandonment means the same thing, and treating it as one undifferentiated category of failure misses the fix each pattern actually needs.

• Never adopted is the cleanest signal: a license was provisioned and never meaningfully used. I see this most often when a tool was bought at department-head level to hit an adoption target, then pushed to teams never consulted on whether they needed it. The fix is not more training; it is asking whether the team had the problem the tool solves, and reallocating the seat if not.
• Tried and dropped is more useful: someone engaged, hit a wall and stopped. The walls are usually mundane. Code-assistance tools get abandoned when they lack system context, turning every suggestion into something to verify rather than accept. Drafting assistants get dropped when their tone misses a brand voice reviewers must enforce, making output slower to fix than to write. A short conversation with a few droppers, rather than a survey, surfaces that wall faster than any analytics platform.
• Usage decayed is the quietest and most dangerous, because it looks like adoption in every snapshot except the trend line. A tool drifting from daily to monthly use is dying slowly, yet most dashboards report only the latest snapshot. Decay usually points to a tool that solved an initial novelty task and lost relevance as workflows evolved, or to output that never crossed the trust bar, reducing the tool to an occasional first-draft generator.

None of this is free. On a thousand-seat agreement, 20% never adopted and 20% dropped is 400 licenses you are paying for and nobody is using.

Measuring retention without a new platform

You do not need a new analytics platform to track abandonment. Cohort retention, standard in consumer software for two decades, works just as well on internal AI tools. Group users by the month they first activated a license, and check what percentage still actively use the tool at week 1, week 4 and week 12.

Track retention by monthly group rather than policing individuals. An individual might pause usage for a vacation or planning sprint, and scoring individuals invites employees to game the metric with dummy prompts. When 40% of the March group stops by week 4, you see a product failure, not a personal one. Unlike surveys or manager assessments based on opinion, cohort retention measures actual behavior. The log already knows who stopped.

To build the curve cleanly from existing logs, follow three practical rules:

1. Count intentional actions, and compare against two baselines. Use single sign-on, network or vendor logs, and count active choices (submitting a prompt or accepting code) rather than background plugins loading on startup. Compare active week-12 users against two starting baselines: total licenses purchased and users who logged in at least once. Comparing against purchased licenses exposes wasted budget from a stalled rollout; comparing against users who tried the tool exposes whether the product delivered value in daily work.
2. Read where the drop-off happens. A steep drop in week 1 points to broken onboarding or poor role fit. A slow bleed between week 4 and week 12 points to workflow friction once curiosity wears off. With no industry benchmark for internal AI tools, compare each tool against your other AI tools on the same teams, and this month’s group against last month’s. A curve that flattens has found durable value; one still falling at week 12 has not.
3. Check for model changes and tool switching. AI vendors retune or swap models between releases without notice, so a sudden drop in May might reflect a model update rather than workflow friction. Just as often, employees who drop one tool have simply switched to another approved assistant or gone around IT entirely, with more than 12,000 shadow AI applications already operating inside enterprises and 50 new ones appearing daily. Checking overall AI activity across a team alongside tool-specific retention shows whether employees rejected AI or just rejected that vendor.

What changes at renewal

Tracking abandonment pays off when contract renewals arrive. Right now, most renewal decisions rely on cumulative adoption numbers that were never designed to show whether a contract is worth keeping.

Abandonment data gives you a cleaner three-way split. Tools with high never-adopted or tried-and-dropped rates should be candidates to drop outright, regardless of how the usage dashboard frames it. Tools with decaying usage are candidates to repair, through a targeted workflow fix, a better integration or retraining on the tasks where trust broke down.

Tools with genuinely sustained retention are candidates to concentrate spend on, including expanding seats faster than the standard rollout cadence would suggest. Where two tools serve the same population, the one holding its cohort should be taking seats from the one that is not.

And put two asks into the next agreement you sign: define what counts as an active user before signature, and require event-level usage export rather than the summary dashboard. That is the difference between measuring this properly next year and relitigating definitions in a business review.

Why mandates and retention targets backfire

The first is mandating usage. Mandates destroy the signal permanently: the moment usage becomes compliance, behavior stops meaning anything. Some users concluding “not for me” shows the evaluation is working. The correct abandonment target is not zero.

The second trap is treating healthy retention as proof of delivery. Abandonment runs cleanly in one direction only: someone who learned a tool and dropped it returned a clear verdict, but someone who kept using it tells you less than you think. Even in controlled trials, experienced developers working in familiar code took 19% longer to complete tasks with AI tools while believing they were 20% faster. Because writing code was rarely the bottleneck, pair retention with delivery metrics tracking downstream rework, code churn and peer review cycles, not just time-to-code. If cycle time has not moved after a year of healthy retention, the thesis you bought on is dead.

Where to start before your next renewal

None of this requires a new program. Pull the activation dates you already hold, build one retention curve for your three largest AI contracts, and check week 4 and week 12. For most organizations that is an afternoon.

Put a quarterly 15-minute review on the calendar with each platform owner to inspect the retention curve and the provisioned-to-sustained gap. That review belongs with whoever owns the platform workflow, not procurement; fixing a decayed cohort means changing the rollout, not renegotiating unit price. Watch retention within a cohort rather than raw headcount: durable use in a small high-value team beats thin adoption across a large one.

Keep your adoption numbers to see whether teams are willing to try something new. But before your next renewal, ask for the retention curve. Adoption tells you what you bought. Abandonment tells you what to keep.

I have audited enough celebrated technology rollouts to notice a quiet omission across the industry: nobody talks much about what happens to the unit economics once the pilot ends and the software enters daily production.

I have anonymized the company and changed identifying details for confidentiality, but the operating economics and workflow behaviors below are taken directly from the post-implementation audit.

About six months ago, I was brought into a mid-sized enterprise to review a document workflow that had recently received an industry innovation award. The platform vendor published a case study highlighting the deployment. The trade press ran a short feature on it. Internally, the business unit sponsor pointed to a ninety percent reduction in turnaround time for vendor onboarding agreements, using that headline metric to secure a larger operational mandate for the coming fiscal cycle.

A couple quarters later, the finance team reached out with an uncomfortable question. Document volume had stayed flat, yet the monthly operating expenses attached to processing those agreements were climbing steadily every single billing cycle.

They asked me to trace the spending back through their systems and reconcile the operational data with the general ledger.

Under the previous manual workflow, an operations clerk opened an incoming contract, checked five or six key clauses against internal guidelines, verified the vendor details and filed the document away. The entire review took about four to five minutes. Using the department’s fully loaded labor rate, including benefits and allocated overhead, that came out to roughly eighty cents per document.

The automated pipeline was running between $12 and $14 for the exact same file.

The system was technically stable. It processed thousands of files a month without dropping connections or crashing servers, and the operations dashboard stayed green. But the business was spending $12–$14 to complete work that had previously cost about 80 cents.

Every enterprise award celebrates speed and throughput. Few of them audit the cost to finish a single unit of work.

Nobody caught the discrepancy during the original three-month pilot because the computing bills, data lookups and third-party model access fees had been charged to a central innovation fund. The departmental budget never saw an invoice. As far as operations was concerned, the tool was essentially free software that dramatically reduced turnaround times on incoming requests.

The moment the pilot concluded and the system moved into full daily production, the accounting changed. Corporate finance closed the innovation project code and began allocating the actual infrastructure invoices directly back to the business line. That was when the operational reality surfaced. Within sixty days of running full transaction volume on the department’s budget, the economics of the unit turned negative.

Traditional enterprise software often has a predictable cost curve. Once the baseline platform is running, processing another five hundred records usually does not require the same kind of fresh computation and external model consumption as an automated pipeline.

In this kind of workflow, each customer interaction, incoming contract or automated data extraction can trigger additional computational steps. The system had to interpret the document, check it against internal rules, compare the result with reference data and validate the answer before completing the transaction.

If an automated pipeline requires multiple model queries and several background checks to finish a task that an experienced employee used to resolve in five minutes, you have not eliminated an operational cost. You have swapped a predictable human payroll line item for a consumption-based cost that scales directly with the work.

Falling model prices don’t mean falling workflow costs

The standard counterargument is that computing power is getting cheaper. That part is true. Research published in the Stanford HAI AI Index Report documented that the cost of querying benchmark foundation models dropped by more than 280-fold between late 2022 and late 2024.

It is tempting to assume that automated business processes will experience the same cost reductions.

In practice, a dramatic drop in per-token rates does not guarantee a lower operating bill if the production workflow performs significantly more retrieval steps, document parsing passes and validation checks to complete a single business task.

Gartner’s latest forecast points to the same tension, predicting that inference costs per agentic workflow will increase more than fivefold through 2028 as increasingly complex workflows offset falling model prices.

Both things can be true at the same time: base model prices can fall while the total cost of completing a business transaction rises.

Cheap models do not guarantee cheap business processes.

The economics of an automated system depend on the cost of the entire workflow, not just the base model.

Production complexity is where the bill gets bigger

During our audit, the operational problem showed up the moment real-world documents stopped looking like the clean samples used during vendor sales demonstrations.

The demonstration files were digitally generated PDFs with uniform fonts, consistent layouts and standard contractual language. The live production queue was full of low-resolution scans, photocopied forms rotated sideways, documents with handwritten marginal notes, and agreements containing conflicting payment terms.

A human operations specialist can often resolve that kind of ambiguity with a quick judgment call based on institutional context. The automated workflow struggled when the document fell outside the assumptions built into the process.

When the system encountered messy formatting or contradictory clauses, it triggered extra processing routines. It ran multiple extraction passes, queried internal reference databases and executed secondary verification checks to resolve the ambiguity. Each extra step added to the cloud invoice, yet the system still struggled to reach an acceptable confidence score.

When confidence fell below the required threshold (which occurred in roughly forty percent of daily transactions), the pipeline halted and routed the file into an exception queue.

That created a secondary labor expense the original business case never budgeted for.

When an agreement landed in the exception queue, an operations specialist had to log in, read the system’s partial extraction notes, diagnose why the software stalled and manually enter the correct data into the core database. Because the specialist had to review both the original document and the system’s confused output, resolving an exception took ten minutes (twice as long as the original manual baseline).

The company found itself paying twice. It was paying the full monthly cloud invoice for the automated software, while simultaneously retaining the payroll cost of the operations staff required to supervise the exceptions.

Goldman Sachs has raised the broader macroeconomic question of whether the massive corporate spending on AI infrastructure will produce productivity returns sufficient to justify the investment. Our audit showed what that question looks like inside a single department: replacing an eighty-cent clerical task with a fourteen-dollar automated pipeline that still requires human labor for four out of every ten transactions.

The problem rarely comes from the user-seat price on the purchase order. It comes from what the system consumes to complete the work.

The vendor can price the platform around usage, but the customer owns the business case. If an automated pipeline requires multiple processing passes to interpret a crooked document scan, the customer still has to absorb that consumption whether the final output is usable or not.

When you scale a human operations team, the additional cost is relatively predictable. You know what another specialist costs in wages, benefits, equipment and management time. For this kind of workflow, automated costs can rise with the ambiguity of the inputs.

When the fiscal quarter wraps up, this creates an organizational disconnect where every department claims victory while the business loses margin:

• The engineering team reports ninety-nine percent system uptime and clean infrastructure performance.
• Operations leadership reports that turnaround times on clean files dropped from forty-eight hours to under a minute.
• The software vendor references the client in marketing collateral as evidence of enterprise transformation.
• Finance is left trying to figure out why the cost of goods sold increased while revenue stayed flat.

When leadership asks why an automation milestone fails to improve operating income, engineering points to platform uptime, product leads point to system adoption and software vendors point to successful transaction counts. Every department hit its individual performance goals. Yet the business process itself became strictly more expensive to run than it was before the project started.

In this deployment, the team tried to fix the issue by adding secondary filtering scripts and tuning prompt instructions. Those additions increased system complexity and cloud consumption without solving the core unit cost problem.

An automated workflow can execute with zero technical errors while still undermining departmental margins.

Three questions before you call an AI project a success

Before approving a production, rollout or expanding an automation pilot, finance and technology leaders should put three direct questions to their teams:

• What does one completed transaction actually cost compared with the manual baseline, accounting for all infrastructure compute, database lookups and third-party model charges?
• How often does a human still have to intervene, and what is the loaded payroll cost of that review time?
• Do the economics still work at production volume, or is the organization simply moving an operational expense from payroll into an unpredictable consumption meter?

If the economics only work during the pilot, the system is not creating operational leverage. It is creating an operating expense the pilot never measured.

I argued in my last column, The case and model for real-time AI cost visibility at the infrastructure layer, that the AI measurement problem looks to be finally solved as a technical matter, and that companies can now manage AI as a strategic investment rather than a pay-and-pray experiment. That’s the defining shift for the next era of AI, but with one clarification: it’s only true for organizations whose architecture permits it.

My work puts me inside enterprise engineering teams, helping practitioners measure and optimize their cloud and AI costs. The biggest roadblock is rarely budget or expertise. It’s that AI spend, unlike cloud spend, doesn’t attach to anything you can tag. A token call has no owner, one API key can carry a dozen workflows across several teams, and the thing spending the money is usually an agent rather than a person.

The answers these teams need are only available by looking underneath the application, where you can watch what’s running. Getting there isn’t a complex engineering project, but it does require access to the machine the workload runs on, and that access is structurally unavailable through managed services.

So, the first thing I ask now is: “What does your inference actually run on?” The response determines the accuracy, completeness and usability of the AI cost insights we can get.

The implication of the platforming decision is easy to state and expensive to reverse. You run AI either on services your cloud provider operates for you, or on compute you operate yourself, meaning VMs or container nodes you control. Almost every team picked one many months ago on platform engineering merits, for reasons that had nothing to do with AI measurement. It just wasn’t obvious then that the choice would also determine how much they could understand about their own business later.

But here we are. Gartner expects the average Fortune 500 enterprise to run more than 150,000 agents by 2028, up from fewer than 15 in 2025. A blind spot you could live with across a handful of workloads becomes a serious headache across six figures of them.

The case for managed services is real

To get ahead of claims of bias, I recommend managed services regularly. They get you to a working agent much faster, and they take scaling, patching, availability and capacity off your plate, none of which differentiates anybody. If you come to me with three engineers and an AI roadmap, my recommendation is to use serverless and managed services as much as you can. Running your own infrastructure requires a platform team and the maturity to go with it, which makes this a question of size and stage.

Those advantages are settled science. The other trade-offs materialize later, and while CIOs have weighed most of them before, they’re worth a brief mention.

The AI trade-offs you can already price

Model selection is where this shows up in dollars. Open-weight models often run on infrastructure you control, while managed catalogs can lag availability or limit model choice. That matters when a newer model materially changes inference economics or performance. If you’re using a managed service that doesn’t offer the model you want, you can’t route to it through that service.

Stripe agreed in August to buy OpenRouter for more than $7 billion, a strong indicator of what the market thinks routing is worth. Of course, you can still route between models on a managed service, but you have to build the router into your own application code and run it yourself, outside the service you bought so you wouldn’t have to do that stuff.

The provider’s schedule also determines when you get access to new capabilities. For example, plenty of teams on their own infrastructure started building against MCP within days of its release, while stateful MCP server support didn’t reach AWS’s agent runtime until this past March, more than a year later.

It’s also worth noting that agents handing off to each other can introduce another execution or initialization cost, whereas on your own nodes you can keep resources warm. Enterprise authentication is not always one of the methods on offer, so you may have to build that path yourself anyway. And in regulated industries, proving where data can be a dealbreaker.

None of this is news to anyone who has run a platform, and none of it is disqualifying. You can put a number on each and decide it’s worth paying. The next one doesn’t work that way.

AI cost visibility is a one-sided trade

Let’s start with exploring what exactly your managed service provider tells you about your AI spend. The bill arrives on the provider’s schedule and can give you a detailed view of what you spent on a service, often by account or API key. That tells you where spend went up or down. It doesn’t necessarily tell you which workflow did it, which customer or which employee triggered it (not just created it). It also doesn’t enable you to map that spend to outcomes, productivity or revenue. A bill is not a measurement of value.

Going further, an AI agent isn’t a single service either. It’s the model call plus MCP servers, vector databases, APIs, prompt management and whatever else the workflow leans on, and that supporting cast can represent a substantial share of the cost. Without the ability to review those costs in isolation, you’re evaluating on estimates. You can’t say what a feature costs to serve, which accounts are profitable at the terms you signed, or whether the expensive part is the model or everything around it. So, you ballpark, and everything downstream inherits the inevitable errors.

The standard workaround has been to instrument the application, tracking each model call and carrying cost data through the workflow. I’ve built that many times and, on infrastructure you control, it works. But inside a managed runtime, you’re instrumenting someone else’s execution model. You can track the calls you make, but you may not be able to see the initialization you’re paying for, the orchestration between steps or the retries the platform runs on your behalf. You get detailed numbers for your own code, but less visibility into everything happening around it, and that’s often where the surprises are.

The expensive AI failures are also episodic rather than steady or predictable. An agent might loop on a retrieval it can’t satisfy, a workflow could revert to an expensive frontier model or a prompt change adds context and cost to every downstream call. If you’re reviewing the bill on a monthly cadence, you see that the AI number on the bill is bigger than last month, but don’t know why.

With real-time, per-request granularity you can instantly identify the workflow that’s misbehaving and it’s usually a quick fix. It also sets how soon you can intervene.

Accessing real-time, per-request attribution

The way to get that granular, real-time view is to watch the kernel, using the same eBPF technology that security and observability tools use to see system calls without touching the applications above them. In an implementation like this, it can map compute and network activity back to the relevant process and request, then join outbound model calls to provider cost data. The advantage is that the view doesn’t depend on developers remembering to instrument every call.

The catch is that it only works where you control the host machine, a narrower set of places than most people assume. On AWS it means EC2, and container workloads on EC2-backed ECS or EKS nodes. It doesn’t mean Fargate, where you don’t control the host kernel. The same principle holds across clouds: customer-controlled VMs and Kubernetes nodes can give you access to the kernel, while serverless and fully managed runtimes generally don’t.

It’s a firm line in the sand. You either have the option, or you don’t. There are no workarounds here. That alone doesn’t make managed services a mistake, and provider telemetry and application instrumentation still matter, they just can’t give you the same infrastructure-level view. If your inference runs where you don’t control the machine, you get as much infrastructure-level visibility as your provider chooses to share, and that ceiling remains capped even as the number of agents and the value of visibility grows.

The shift to per-task pricing for agentic workflows

Today, price per token is the standard unit for AI spend, but it’s the wrong one for agents. Agents burn far more tokens than chat; input drives most of the cost, and token use on the same task swings widely between runs, so cheaper tokens can still produce more expensive tasks. Cost per completed task is what tracks value.

But pricing a task means matching spend to its specific workflow and a measurable outcome. On infrastructure you control, you can get that visibility. On a managed runtime, you’re mostly inferring from an aggregated bill.

The last two years rewarded shipping. The next phase rewards knowing what each task costs and what it’s worth, and companies that can’t see the work will be competing against ones that can.

Many organizations have licensed language models, tested AI agents, and asked DevOps teams to develop code-generation standards. But production deployments are still a work in progress for CIOs, with only 50% of organizations moving more than half of their AI projects from pilot to production, according to Outsystems’ State of AI Development 2026 report.

Increasing production deployments is a key step for many CIOs, followed by fostering more widespread employee adoption. But usage doesn’t always translate to business outcomes, leaving many IT organizations struggling to deliver business value on their AI initiatives.

Much of that has to do with how they’re measuring AI value.

“Too many organizations are treating AI adoption as the metric when the real question is whether it’s improving business outcomes,” says Rob Scudiere, CTO at Verint. “The metrics that matter are the ones executives already track, and if those numbers aren’t improving, it’s hard to argue that AI is delivering meaningful value.”

Measuring how AI impacts the business strategy and its relevant KPIs is a vital first step, especially when it comes to identifying AI’s business-specific opportunities and risks. After all, AI’s capabilities, practices, and security considerations are changing so quickly that it’s essential for C-level leaders to discuss AI’s strategic business value frequently — and to do so with the right data to back those discussions up.  

That, in turn, requires a more collaborative leadership approach.

“Organizations should align with business stakeholders upfront on the ‘so what,’” says Keyur Ajmera, CIO at Boomi. “CIOs should partner with CMOs, CHROs, CFOs, and business practitioners to identify use cases, establish appropriate governance and standardization, prepare employees for new ways of working, and create financial guardrails as usage-based AI costs become more prevalent.”

I heard from more than 30 leaders on their picks for the business value metrics that matter most when tracking your AI strategy’s impact. Below are my top five worth adopting.

Growth driven by organizational expertise

For AI to be transformational and not just reshaping business, executives must show that building greater expertise through AI drives business growth.

“Executives primarily talk about AI ROI in terms of cost savings and efficiency, and that doesn’t adequately measure long-term AI success, because it doesn’t capture whether the organization is actually getting smarter,” says Sarah Edwards, chief product and strategy officer at Kantata.

“I’d point them to what I think of as an organization’s expertise compounding rate, which is its ability to capture, synthesize, scale, and continuously build on institutional and tribal knowledge,” she adds. “Firms also need to look beyond productivity and efficiency and consider how AI drives revenue growth, including new pipelines, better client retention, new pricing models, and the ability to take on more projects without adding headcount.”

Ways to measure: Track how expertise developed via AI capabilities drives revenue. Examples include:

• DevOps teams, newly trained on vibe coding tools, help increase revenue by adding AI capabilities such as shopping concierge agents and genAI search capabilities to customer-facing websites.
• Benchmarking return on ad spend (ROAS) between two campaigns, one developed by a team using AI tools, the other without using AI.
• Contact centers using AI to support service-to-sales or sales-through-service competencies can measure increases in revenue per agent hour or offer conversion rates. In one famous case, Ikea built a new €1.3 billion business line, thanks to a contact center chatbot freeing up associates’ time.

The key pattern is that when AI is introduced into a sales, marketing, or support function, it can be correlated with revenue increases.

Improved customer retention

Improving customer retention is a key metric for products or services, especially those with subscription business models. Customer loyalty and the ability to influence repeat purchases are similar KPIs when the brand influences pricing and customer-perceived value.

How CIOs implement data and AI governance can positively or negatively affect customer retention. According to the State of Digital Trust 2026 from Usercentrics, consumers will now pay 7% more for the brands that have earned their trust around AI. Meanwhile, 24% of consumers canceled a subscription or stopped buying from a brand because they were concerned about how their data was used in AI.

Donna Dror, CEO at Usercentrics, says, “Most CIOs can measure what AI saves them, but the harder number, and the one that shows up in revenue, is what mishandling data in AI costs in lost customers.”

Ways to measure: Measure consent withdrawals, Data Subject Access Requests (DSARs), or AI feature opt-out rates. Businesses with subscription products can track renewal rates in the 90 days following an AI feature launch and add a data-and-AI-use reason code to the cancellation flows.

Employee capabilities beyond productivity

I’ve warned CIOs that focusing on AI’s productivity improvements is a trap, because at some point the CFO will look for cost savings through headcount reductions. Other metrics beyond productivity may matter more, especially for organizations investing in agentic AI workflows.

The first is time-to-decision: AI agents are either capable of taking action autonomously, or they are implemented to include human collaboration in decision-making. CIOs and the business owners of AI agents should determine how to measure the business impact of faster, smarter decision-making.

“Most AI scorecards measure activity, including agents deployed, tasks automated, and prompts processed,” says Vikram Bhandari, chief technology and innovation officer at Riveron. “The metric I push clients toward is time to decision, such as how much faster finance or ops teams can act once AI is in the workflow, and what that speed translates to in revenue or risk avoided. Headcount metrics tell you AI has replaced work, while decision-speed metrics tell you AI changed the business.”

Enterprises can scale beyond individual productivity improvements by re-engineering business processes using AI orchestration platforms. But CIOs have to get AI democratization right by influencing experts to build the organization’s knowledge base and the AI context layer utilized by AI agents.

“Data democratization’s real number is the percentage of institutional knowledge anyone can self-serve, without tracking down one specific person,” says Chris Cope, VP of engineering at CADDi. “Manufacturers map every flow on the factory floor and fixate on single-source supplier risk, yet miss the same risk when it’s a person holding the knowledge.”

Ways to measure: In risk management functions, measure time-to-decision as the difference between mean time to remediate (MTTR) and mean time to detect (MTTD). Measure knowledge management impacts by tracking increased utilization of internal LLMs, while capturing the reduced time spent on answering requests for information (RFIs) by subject matter experts.

Impacts to customer and employee experience

CIOs should hunt for examples of value delivered to customers and for employees that go beyond doing today’s job better. This means exploring areas where AI provides a business capability that is not feasible, or is economically unscalable, if people were performing the function without AI capabilities.

Venkat Ramakrishnan, president and COO at NeuBird, shares this example in IT and security incident management: “The focus has shifted from how fast you resolved an incident to how many users never felt it in the first place. When AI prevents an incident 30 minutes before failure, or resolves it in under 5 minutes instead of 175, it eliminates the experience impact rather than only reducing it,” Ramakrishnan says.

Other examples require exploring game-changing operational transformations in other departments, or finding areas where AI impacts the connected experiences of customers and employees (CX and EX).

“CIOs should measure genAI by whether it changes the economics of the business such as decision velocity, capacity created per employee, exceptions resolved without escalation, revenue leakage recovered, customer and employee effort avoided, and ultimately the rate at which AI benefits reach the P&L,” says Arun Raghavapudi, chief customer officer at R Systems (RSI). “The strongest AI strategy is therefore one where CX, EX, engineering, and business KPIs form a single value chain rather than separate technology scorecards.”

Ways to measure: CIOs should identify AI-native capabilities, those business and operational competencies that are net-new AI use cases. Once identified, business value metrics determine the value delivered, and the AI-native capabilities become marketable innovations to communicate across the company.

Measure AI’s operational impacts

Many CIOs used lift-and-shift cloud migration strategies or overly empowered DevOps teams to procure cloud infrastructure, only to find skyrocketing costs. CIOs applied FinOps best practices and shifted-left financial considerations to reduce costs and instill fiscal discipline.

Even as token costs decline, AI cost debt is very real as consumption of AI models and use of AI agents increases. Tokenomics tracks and manages both costs and the business value delivered from spending on AI tokens. On the cost side, CIOs should factor in the human-effort costs, including the AI hallucination tax when employees have to recognize when AI models and agents are wrong.

“Token spend is becoming a real line item, and if it grows faster than the outcomes it produces, that’s a unit economics problem, not a scaling milestone to be proud of,” says Yasmin Rajabi, COO of CloudBolt. “The metrics that matter include how often AI-generated work is accepted without rework, how many decisions or actions run without a human in the loop, and value per token you get for every token you spend.”

Measuring the value of operational impacts needs to consider both tactical impacts based on individual contributions versus team, department, and business-level outcomes.

“Indicators that AI is creating measurable value rather than simply generating activity include whether critical workflows are completed quicker, decisions are more consistent, and AI-generated recommendations are traceable back to authoritative information,” says Tony Grout, chief product and technology officer at M-Files. “The most successful AI programs will be judged by whether they deliver better business outcomes like faster project completion, higher-quality customer service, improved compliance, and more consistent decision-making.”

Ways to measure: My research on AI agent orchestration platforms identifies several platforms that include tokenomics capabilities, including solutions from Boomi, Cisco, Databricks, Kamiwaze, LangChain, Microsoft, Nutanix, PagerDuty, Salesforce, Snowflake, Tray.ai, and Workato.

Setting realistic expectations

CIOs must lead a progression from AI experiments to production deployments, enterprise adoption, and delivered value. But the organization’s velocity to adopt and deliver value requires a strong change management program that adjusts to business demand, especially if the AI bubble bursts.

“The reality is that enterprise AI follows a productivity J-curve, where companies invest in new skills, operating models, governance, and process redesign long before the full economic benefits become visible,” says Kris Lovejoy, global head of strategy at Kyndryl. “As a result, usage often rises months before measurable business outcomes appear, and this is one reason many executives feel uncertain about the return they’re getting from AI.”

While AI agent deployment and employee adoption are not the end game, CIOs must excel at these before overpromising business value. Two places to start include upskilling IT for agentic AI while avoiding mistakes when deploying AI agents.

Most CIOs can easily describe their AI initiatives, but struggle to demonstrate and report on AI value and ROI. This is evidenced by Gartner’s AI ROI Vendor Sentiment survey, which found that 27% of respondents strongly agree that ROI from AI initiatives is difficult to quantify. In addition, only one in four had a clear process to evaluate success of AI initiatives.

In the digital transformation era, compute costs were relatively cheap, and the focus was less on FinOps and more on user experience, and the classic software attributes of availability, reliability, scalability, performance, and security.

AI-native and AI-enabled applications still bring these considerations, along with a host of new ones, such as accuracy, validity, explainability, safety, and all the other trust attributes like those in the NIST AI RMF. But as AI scales, it’s quicky becoming a FinOps exercise, too.

I’ve discussed techniques CIOs can apply to improve AI value and ROI such as architectural decisions related to controlling efficiency at the data layer, fine-tuning the application layer, and closing the gap between AI strategy and governance.

Here, we’ll look at three best practices for CIOs looking to formalize their process to evaluate the effectiveness of their AI initiatives through approaches, frameworks, and techniques that support measurement and ROI reporting across the entire AI portfolio.

1. Take a portfolio approach in line with AI ambition

The first step to AI value is to take a portfolio approach and look across your entire AI estate and how it supports your AI strategy and broader organizational strategy. This means thinking about your AI innovation ambition and how you’d like to move the needle year-over-year by adjusting your percentage of spend across quick wins versus must haves, internal (employee-facing) versus external (customer-facing) applications, near-term versus long-term initiatives, and cost savings and productivity versus revenue generation.

This AI innovation ambition approach is a best practice in innovation management as organizations work to gain quick wins early on to prove value, and then get more ambitious in subsequent years and allocate a larger percentage of their spend on more strategic, longer-term, and externally focused initiatives for revenue generation.

For example, an early maturity organization might focus 80% of its AI investment on internal-facing initiatives and 20% on external-facing ones in the first year. Then, it moves to a 70/30 split in year two, and so on. While many organizations may not track these spend allocations, it’s a valuable discipline and one which often differentiates AI leaders from the rest of the pack. In PwC’s 2026 AI Performance Study, the top 20% of companies capture 74% of all AI-driven economic value, delivering a 7.2 performance multiplier over peers.

Deploying focused pilots alongside quick wins is a great way to capture early insights into AI value and ROI before scaling applications. According to Joe Vaccaro, SVP and GM of Network Platform and Assurance at Cisco, networks have become distributed, continuously changing systems that produce far more signal than any human-led operating model was designed to interpret.

“Our survey of 1,000 IT and NetOps leaders found more than half believe a failure to automate will open critical security gaps and elevate enterprise risk,” he says. “For CIOs seeking to demonstrate ROI from AI investments, a credible path is to start with targeted, measurable, and reversible workflows. Focused pilots can validate outcomes and strengthen governance before broader deployment.”

At this level where organizations look at their holistic AI spend, it’s also important to have a well-crafted set of AI value metrics, which can be used to assess the current health and productivity of the portfolio. Borrowing from best practices in innovation management, AI value metrics, such as those that look at input and mix, health and efficiency, and outcomes, help to look across the entire innovation pipeline, from idea to value.

• AI innovation input and mix — What’s going into your pipeline in terms of the types of innovations in the queue.
• AI innovation health and efficiency — The flowrate through your pipeline and the amount of funding being applied.
• AI innovation outcomes — The measure of return on innovation in terms of commercialized innovations that have captured revenue or other objectives.

2. Develop an assessment framework focused on full cost benefit

While many organizations are laser-focused on the cost side of their AI initiatives, your assessment framework needs to incorporate a full cost benefit analysis. “While the current focus for many organizations is squarely on AI tokenomics, it’s important to look at both sides of the coin when it comes to AI value, and look at the business value that’s being delivered by each initiative to give a clear picture of actual return,” says David Evans, AI and growth strategist at thought leader networking platform Thinkers360. 

Ben Schein, VP of AI and analytics at AI infrastructure software company Progress Software, adds that CIOs should stop measuring AI activity and start measuring outcomes where possible. “Usage tells you the meter is spinning, not that value came out,” he says. “Instrument the cost side completely, since every AI action can carry its workload, model, and cost. Then pair costs with benefits where the work allows, so cost per workflow run against value per workflow run, never enterprise-wide spend against anecdotal wins.”

However, Dan Priest, PwC US CAIO, recommends getting back to basics, starting with the investment side but adding a few modern updates. “AI ROI has been illusive for many, in part because organizations are still learning how to achieve it, and because AI sometimes gets a pass on the typical disciplines required to measure it,” he says. “For major AI initiatives, starting with investment might include new infrastructure, labor for the build, models for the intelligence layer, and variable expenses like token costs. All of these should be contemplated in ROI calculation, some of which will require new tracking and controls.”

His benchmarking also points to a threshold effect: ROI stays insignificant until AI investment crosses roughly 1.6% of revenue, and above that line, EBITDA is up 9.5%, revenue is up 3.5%, and total shareholder return is up 20.2%.

3. Include benefits and measure what matters

Another best practice from innovation management is to look at both the quantitative and qualitative benefits of AI initiatives, not solely the direct financials.

“It sounds obvious, but CIOs should measure the business value created like productivity, growth, and other outcomes rather than activity completed, such as building an app, creating a dashboard, or collecting customer feedback,” says Priest. “We recommend looking across five dimensions of value: financial, operating, functional, trust, and workforce. That gives leaders a more consistent way to measure and compare value across an AI portfolio, even when individual investments are designed to produce different outcomes.”

Calculating projected as well as actual ROI can also give CIOs insight into how their AI portfolio is living up to expectations. This is where it’s important to factor in governance costs early in the lifecycle before initiatives get funded, particularly for high-risk applications where downstream governance requirements are high. 

“Ultimately, measure what matters, keep an eye on variable costs, and monitor actuals against expected costs and benefits,” adds Priest. “That gives CIOs the information they need to determine where investments are delivering, where changes are required, and where to lead, lag, or exit.”

Quantifying AI value and ROI doesn’t require a completely new methodology or new approach. It simply takes the same financial rigor applied to many other previous investments. The variable cost dynamics may be more complex, but these are solvable if you align with your AI innovation ambition, apply your assessment frameworks consistently, define your AI value metrics, and measure what matters.

Many IT leaders still struggle to find ROI when deploying AI agents at scale, but a few IT sweet spots are emerging as use cases that can provide CIOs tangible cost relief.

Rhonda Baldwin, CIO at LaunchDarkly, says coding agents and service desk agents are helping the SaaS provider cut IT costs.

“Coding agents increase engineering capacity without requiring a proportional increase in headcount,” she says. “They also help us optimize cloud costs and reduce workflow consumption costs.”

In addition to coding and cloud cost optimization, IT leaders see tier 1 and 2 IT support as another promising area for agents to free up IT budget, although many have just begun to track savings from AI agents, and those that do use several different metrics.

For Baldwin that includes cost avoidance, as coding agents have helped the company build internal tools rather than buying additional software, she notes.

Here, the savings have been substantial, she says, with the company foregoing about $1 million in spending on two optimization projects and another $120,000 by building its own enterprise asset-management solution with AI coding tools.

In addition, LaunchDarkly has saved about $50,000 in annualized savings by using agentic AI for tier 1 IT support. “This not only boosts employee productivity but also helps us avoid costs related to software, implementation, asset management, and having remote service technicians,” she says.

IT support and self-service resolution

IT support is a strong use case for IT leaders looking for agent cost savings, says Gil Pekelman, CEO of AI agent provider Atera, whose company recently released a joint study with Forrester claiming significant ROI for its IT incident support agent.

“The calculation is very straightforward,” he notes. “We have a company that has 10,000 employees, and all IT support is offshored. If they’re going to close that down now, they can immediately measure the savings there.”

Kevin Rooney, CIO at West Monroe Partners, reports significant savings for the digital consultancy through just such a deployment.

Now, employees can an internal IT and HR support agent in Teams or Slack to get answers to common questions, request software access, reset passwords, unlock accounts, submit and update tickets, or connect with a live support professional when needed, he says.

“By handling high-volume, repeatable requests and improving ticket intake and routing, it helps our IT team spend more time on complex issues and higher-value work,” Rooney adds.

West Monroe is evaluating the impact of the agent in terms of self-service resolution, ticket volume, response time, and capacity savings, but it has driven a 40% reduction in yearly managed service provider costs, he says. The bot has also led to an estimated operational time savings of 2,700 hours per year, he adds.

Cost savings in the cloud

Matthew Wallace, co-founder and CTO of KamiwazaAI, has also found major IT savings from agentic AI. The Ai orchestration platform provider uses agents in several areas, including software engineering, project management, data science, and systems engineering.

Cloud optimization is another area where the company is saving money by using agents, he adds.

“We have a set of agents that monitor new systems in the cloud, coordinate with those turning them up, and coordinate budget approvals, with an easy way to shut down unauthorized spend and log it,” he says.

That agentic system has replaced a function that required a high amount of human coordination and attention, he notes

“You have to check and understand who set it up, when, what the cost is, whether it has internal approval, and various details about resource sizing, placement, etc.,” he explains. “Later, you have to check whether someone has responded with information and whether anyone in management has offered an approval or rejection.”

The first round of cloud optimization agents that Wallace’s team deployed cut cloud spending by 70% immediately, he says.

Check the numbers

However, Jeet Pattanaik, founder and CTO of AI-base solutions provider Glokal AI, says some organizations are inflating their IT savings from agentic AI because they’re not measuring all the costs.

While he believes some IT leaders are finding real savings, they’re often smaller and slower than advertised, he says, noting that in reality most organizations are still hunting for ROI.

“The pilot always looks great because it runs on the easy tickets,” Pattanaik says. “Then, production brings in all the odd cases, and somebody has to check what the agent actually did. That checking is what quietly eats the savings, and it almost never shows up in the business case.”

He sees tier 1 support — password resets, access requests, answering questions already in the documentation — as the place where organizations are saving IT budget using agents.

“The sweet spot is work that’s high volume, well documented, and cheap to undo if the agent gets it wrong,” he says. “Tier 1 fits that nicely. Tier 2 only partly. Anything that changes someone’s permissions or touches production systems isn’t ready yet, because one bad action there can cost more than a thousand good ones save.”

IT leaders deploying agents for IT support should keep an eye on how often tickets get reopened, Pattanaik adds. “A ticket the agent closed isn’t always a problem solved,” he says. “If people keep coming back with the same issue, you didn’t save anything, you just pushed it down the road.”

He gives this example: A service desk handles 10,000 tier-1 tickets a month at about €15 each. The agent closes 40% of them, which, on paper, saves €60,000 a month. But if 15% of those come back reopened, that’s €9,000 of work returning to humans. Add around €15,000 for people checking what the agent did, and the real cost reduction is closer to €36,000, about 60% of what the pilot promised.

There’s also a cost to eliminating workers focused on tier 1 support, he adds. “One cost nobody seems to count: Tier 1 is where people learn the job,” he says. “Automate all of it, and you lose the path that turns juniors into your future senior engineers.”

For most of computing history, performance was an engineering problem you could reason about at your desk. Profile the code, count the database calls, size the hardware. If a system was slow, the cause was usually something you could hold in your head: an unindexed query, a synchronous call that should have been async, a loop that ran one order of magnitude too many times. You could draw the system on a whiteboard, and the whiteboard would basically be correct.

That era is over. In cloud-native systems, performance has become an emergent property. It arises from the interaction of many moving parts, most of which you don’t directly control, and that shift changes how we have to engineer for it. The core argument is simple to state and hard to internalize: in a modern-day distributed system, you cannot optimize what you cannot observe.

Performance is no longer about your code

Consider what actually determines the speed of a cloud-native application today. It’s spread across dozens of loosely coupled microservices. Those services share network fabric and physical infrastructure with other tenants on a Kubernetes cluster. They’re scheduled into containers by an orchestrator making placement decisions you never see, filtering and scoring nodes behind the scenes before binding a workload to whichever one wins, and they scale up and down automatically in response to demand that arrives in unpredictable bursts.

In that environment, application behavior is driven less by algorithmic efficiency than by distributed orchestration, virtualization overhead, and workload variability. A minor shift in traffic distribution or container scheduling can introduce a bottleneck that’s genuinely difficult to diagnose after the fact, because the conditions that caused it may no longer exist by the time you go looking. Inter-service calls that look trivial in isolation — a few milliseconds here, a few there — accumulate into measurable delay across a long service chain, the same way a handful of small taxes compound into a large bill.

And in a multi-tenant cloud, a competing workload can degrade your responsiveness in ways you can’t reproduce on demand. This is well known enough in cloud architecture circles to have its own name: the noisy neighbor problem, where one tenant’s activity on shared infrastructure quietly degrades another’s performance even though nothing in your own stack changed. The performance you get is the sum of all these interactions, not just a property of any single component you wrote.

Why traditional monitoring falls short

The instinct is to throw monitoring at the problem. But there’s a meaningful difference between monitoring cloud-native systems vs. actually exposing where fault could lie. And that is exactly where that difference matters. Cindy Sridharan made a case earlier, describing traditional monitoring as failure-centric, built around a list of known ways things break, whereas observability is meant to support open-ended debugging of failures nobody predicted.

That distinction matters in practice because averages are exactly the wrong lens for distributed systems. Average latency can sit directly on top of a system that is intermittently unbearable for a meaningful slice of users, and because averages smooth over the short-term, however, it is the sharp events that hurt the most. This isn’t a new observation; in the now-classic paper on large-scale systems, Google engineers Jeff Dean and Luiz André Barroso described how tail latency at scale becomes the dominant experience for users of any sufficiently large distributed system, because a request that fans out to hundreds of components only needs one slow component to become a slow request overall. As a system grows, the odds that at least one component is having a bad moment approach certainty. Averages don’t see that. Observability, done well, means being able to ask why a specific request was slow and reconstruct the answer from execution traces, logs, and fine-grained runtime telemetry across every service that request touched. The goal isn’t a prettier dashboard. It’s the ability to follow one request through the system and see exactly where the time went.

Designing for runtime, not just design-time

The deeper lesson is about when we assess performance, not just how. For years, performance testing was a design-time activity: run a load test before release, and if the numbers look good, ship. Cloud-native systems break that assumption, because so much of what affects performance — scheduling decisions, autoscaling behavior, neighbor interference, resource contention under real traffic shapes — only exists at runtime and only under real workloads. Offline benchmarks against fixed, synthetic traffic patterns simply don’t capture it, because production traffic doesn’t arrive in the tidy, evenly distributed way a load-testing script assumes.

So, performance assurance has to move closer to production: continuous telemetry from running services, compared against known-good baselines, so that degradation is caught as it emerges rather than discovered after users feel it and complain. There is a growing body of research pushing in exactly this direction, on observability-driven and adaptive autoscaling approaches that use runtime signals rather than fixed thresholds to decide when and how to scale. The results across that research vary by system and workload, and the specific percentage improvements aren’t  quoted as a single universal number. What is consistent is the underlying finding: systems that scale and adapt based on what’s actually happening at runtime tend to outperform ones that rely on static, pre-configured rules, particularly on tail latency, which is the metric static rules are worst at protecting. The specific numbers in any one study matter less than what produced the improvement: measuring the system as it actually runs, not as it was assumed it would run when someone configured the autoscaler months earlier.

The takeaway

Cloud-native architecture gave us tremendous flexibility, and it took away our ability to reason about performance. The right response isn’t to fight that trade. It’s to accept it and instrument accordingly.

Treat observability as a design requirement, not an afterthought bolted on after an incident. Measure at the percentiles, not the averages, because the averages are hiding the exact failures that matter most to real users. And assess performance where it actually happens: at runtime, under real load, continuously, rather than only in a pre-release load test that can’t anticipate what production traffic will actually look like.

In systems this complex, visibility is the prerequisite for everything else. You can’t optimize what you can’t observe, and you can’t observe it unless you designed it, from the start, to be seen.

Over the last four years, artificial intelligence has captured the imagination of technology and business leaders worldwide, holding out the promise of revamped business models, new growth avenues and efficiency gains. In the past 12 months, however, enterprise conversations have undergone a sharp strategic pivot. As the initial AI hype cycle cools, corporate boards and CFOs are asking harder questions regarding implementation costs and bottom-line return on investment (ROI).

Given the scale of capital involved — with Gartner projecting global AI spending by enterprise and vendors to hit $2.59 trillion — the C-suite must take a rigorous look at how AI initiatives are scoped, budgeted and governed.

A recent survey of 500 senior US and UK finance leaders showed that 79% (4 out of 5) of large enterprises missed their AI budgets in the past 12 months. In another survey^, 85% of enterprises said that they missed AI forecast by greater than 10% and a quarter of them said that they missed it by 50% or more. These numbers are staggeringly high. The silver lining, however, is that 6% of large enterprises have reported an EBIT impact of greater than 5% driven by an enterprise-wide implementation of AI. This indicates that there is a clear path to ROI, provided one runs a disciplined, prudent and efficient governance model for all AI initiatives.

Simply put, an enterprise can increase the ROI on AI investments by addressing the two components of the equation appropriately:

1. Defining and amplifying the business value (numerator)
2. Defining and optimising the cost of AI implementation (denominator). 

Defining and amplifying business value

An enterprise must focus on chasing value, not chasing AI. The board has an important role to play here — it needs to reconsider whether it is asking the right questions. By aggressively pushing for an “AI everywhere” strategy, the board unwittingly shifts the focus to proliferation of AI tools and use cases rather than tangible business value. Pressure from the board incentivizes “tokenmaxxing” by the teams and legitimizes rampant use of AI tokens by those who suffer from AI FOMO. This severely compromises the returns on AI investments, which is later used to question the value of the technology itself.

A few steps an organization could take:

• Allocate costs appropriately: It would be prudent for organizations to keep AI training and access costs under a separate training budget while tracking ROI only for business-approved use cases. Track ROI only on costs linked to the use case.
• Avoid force-fitting: Enterprises should resist the temptation to force-fit AI into every solution, and instead apply it only when the business problem requires it. The board and CEO can take a significant step towards ROI simply by resisting FOMO, distinguishing signals from the noise and pushing back on hype while cautiously embracing AI as required.
• Define ‘kill’ criteria: If AI is deemed fit to solve or reimagine a business problem, it is critical to have clear termination criteria for AI pilots, with an alignment of the metrics to be tracked, their frequency, success or failure criteria and the termination process.
• Capture true value: It is imperative to ensure that business value generated by AI is correctly captured. For example, If AI leads to a 10% time saving to the sales team, that is equivalent to having an additional salesperson for every team of 10 salespeople. This should result in additional sales and this resultant value must be included as part of the value captured in the numerator of the ROI equation.

Defining and optimizing the cost of AI implementation

The reason most organizations exceed AI budgets is that budgets are still being calculated on a ‘per user’ basis. AI licensing cost per user does not give any indication of the tokens that the user will consume, which is where costs scale exponentially. Since token consumption is linked to the task the agent performs, linking AI budgets to the number and complexity of the tasks in a workflow would give a much clearer view of expected costs.

Cost estimates must also account for realities of production environments which are typically missed out in sanitized test environments, including poor-quality long prompts, hallucinations, retry loops, network latency, employee ‘bad’ behaviour trying to ‘break’ the AI tool, etc. Cost estimates must make reasonable assumptions about a combination of these elements happening all the time, which will make token costs more realistic and higher than in more sanitized, non-production Test environments.

Costs can be further optimized in three more layers:

Optimizing at the prompt layer

It makes little sense to upload five voluminous PDF documents for three queries that a user may have and then get the LLM to process all of it when the relevant information might be in 20% of the data uploaded. Instead, chunking the data, vectorizing it with model embeddings and storing it in a vector database will make model usage a lot more effective, with reduced latency, increased retrieval accuracy and reduced cost. This kind of prompt pruning can be very useful. Prompt caching can also be considered if, via extensive user training, users can be trained to give a standardized prompt.

Alternatively, the enterprise could keep a middleware layer between the user and the LLM, which will append every prompt from every user into a standardized format for the LLM to process. By caching the response, the user can access a stored response rather than pinging the LLM for a re-computation on a prompt that has been asked earlier. Large language model providers provide up to an 80% discount on cached responses. Semantic caching, again achieved through vectorization, will enable the LLM to understand the intent of a prompt rather than look for an exact match, which can again reduce token costs significantly.

Optimizing model usage

Likely, a very large percentage of prompts in an organization do not need a frontier LLM to process them. A mid-tier model which comes at a significantly lower cost can deliver the desired output. This is where model cascading can play a critical role in reducing costs. Proposed by three Stanford researchers, it demonstrates an AI framework with model cascading at its core. By classifying prompts based on complexity, understanding model appropriateness for each prompt, caching responses and by assigning each prompt to the most appropriate model optimized for the trade-off between cost, accuracy and latency, they demonstrated significant savings in AI implementation costs.

Optimizing at the architecture layer

To avoid runaway AI bills, it is important for the CIO to embed cost controls within the architecture. As an example, the technology team can embed hard token caps for workloads, which are activated if token consumption is found to be much higher than anticipated for a given workflow or velocity circuit breakers if there are sudden spikes in token consumption, respectively. In addition, it is possible to embed a lot of the above-mentioned strategies (at the prompt and model usage layer) into the AI architecture, thereby paving the way for architectural FinOps, as distinct from the legacy FinOps that most enterprises have today. As an example, a middleware layer can help in prompt pruning, response caching and model cascading.

Many enterprises also change the architecture by moving the inferencing to an ‘on-premises’ environment to avoid incurring API and cloud costs for every prompt execution.

By incorporating all of it as part of the architecture, the CIO has greater visibility and ability to control costs in near real time.

In summary, technology leaders can drive ROI through a mix of sound business judgment, user awareness and training, and tighter control on processes and architecture.

Artificial intelligence may prove to be one of the most transformative technologies in human history. But amid the excitement over smarter models, autonomous agents, enormous data centers and seemingly unlimited computational power, we may be overlooking a much simpler question:

Does AI create more value than it costs?

My position is that the ultimate constraint on artificial intelligence may not be chips, algorithms, data or even electricity. It may be economics.

We are becoming extraordinarily good at producing machine intelligence. We are far less capable of measuring what that intelligence is actually worth.

And that gap could become one of the defining economic problems of the AI era.

We are building factories for intelligence

AI is usually described as software. Increasingly, that description is misleading.

Behind every AI prompt is an enormous physical industrial system: semiconductors, electrical generation, transmission networks, data centers, cooling systems, storage, telecommunications, software and people.

AI mega-data centers are, in effect, the factories of the Intelligence Economy. Instead of turning steel into automobiles, they turn electricity and computation into predictions, recommendations, decisions, software, images, knowledge and other forms of machine-generated intelligence.

This changes the economics of computing.

Intelligence now has a cost of production.

And unlike the Internet services we became accustomed to thinking of as almost weightless, AI consumes very tangible resources: capital, land, electricity, water, chips, networks and increasingly scarce technical talent.

That is why the enormous investment in AI infrastructure matters. We aren’t simply financing another generation of software. We are financing the industrialization of intelligence.

The AI infrastructure paradox

This leads to what I call the AI infrastructure paradox.

The world is committing extraordinary amounts of capital and physical resources to producing intelligence before we have developed equally sophisticated ways of measuring the economic value of the intelligence being produced.

We can measure GPU utilization.

We can count tokens.

We can measure power consumption.

We can count AI users, agents, models and applications.

We can calculate cloud costs almost to the penny.

But ask a corporation a different question — exactly how much incremental economic value did your AI produce? — and the answer frequently becomes much less precise.

That is a serious problem.

Activity is not value.

A company processing billions of AI prompts is not necessarily creating more economic value than one processing a few million. Deploying thousands of copilots or agents tells us that AI is being used. It doesn’t tell us whether the company has become proportionately more productive, profitable, innovative or competitive.

We are becoming extraordinarily sophisticated at measuring the consumption of intelligence while remaining surprisingly primitive at measuring its economic productivity.

Someone ultimately has to pay

There is another side of the AI boom that receives far less attention: affordability.

Data centers cost money. Chips cost money. Electricity costs money. Water, networks, cybersecurity, governance, data engineering and specialized talent all cost money.

Those costs cannot simply disappear.

Ultimately, they must be absorbed somewhere — by consumers through higher prices, enterprises through higher technology spending, shareholders through lower margins, or governments and taxpayers through subsidies and infrastructure investment.

This is where AI encounters an economic constraint that no increase in model intelligence can eliminate.

If the cost of intelligence grows faster than the value of intelligence, eventually something has to give.

This also challenges one of the most persistent assumptions of the technology industry: that technology inevitably gets cheaper.

Individual units of computing may indeed become cheaper. But organizations can still spend more because they consume vastly more computing, cloud capacity, cybersecurity, software, data and AI.

I call this phenomenon IT Inflation.

Technology can simultaneously become more efficient and more expensive.

The important economic question, therefore, isn’t whether the cost of a token, GPU operation or gigabyte falls. It is whether the economic value produced by technology grows faster than the total cost of consuming it.

The community eventually gets a vote

The physical scale of AI creates another economic problem.

The costs and benefits of AI infrastructure frequently occur in different places.

A community hosting a massive data center sees the land use, transmission lines, water consumption, electricity requirements and public incentives directly.

But much of the economic value may flow elsewhere — to technology companies, cloud providers, software developers, users and shareholders around the world.

That creates a reasonable local question:

If we absorb the costs, where is our share of the value?

As AI infrastructure expands, communities will increasingly demand answers. Data centers will require more than construction permits and electrical connections. They will increasingly require what might be called a social license to operate — evidence that the economic and societal benefits justify the resources being consumed.

The great measurement failure

This brings us to what may be AI’s biggest weakness.

It isn’t intelligence.

It is measurement.

Traditional accounting was developed for an economy built primarily around physical assets, labor and financial capital. It tells us remarkably well what organizations spend and what they earn.

But technology has evolved from a supporting function into something closer to a factor of production.

Like labor, technology performs work.

Like capital, it requires investment.

Like infrastructure, it enables economic activity.

AI takes this one step further because organizations can increasingly acquire and consume machine intelligence almost as previous generations consumed electricity.

Yet our accounting and economic measurement systems have not caught up.

That is why I believe we need a discipline of technology economics.

From technology management to technology economics

Technology economics asks a different set of questions from traditional IT management.

Not simply: Does the system work?

But: What economic value does it create?

Not simply: How much AI are we using?

But: How productive is that AI?

Not simply: How much are we investing?

But: What return are we receiving relative to the capital consumed?

The framework I propose includes measures such as IT intensity, IT inflation, technology cost of capital, AI expense per share, AI value per share, margin per unit of IT intensity, the technology leadership index and gross domestic intelligence.

Consider just two of these.

AI expense per share asks shareholders to view AI investment in familiar economic terms: how much AI expenditure is effectively being borne per share?

AI value per share asks the other half of the equation: how much measurable value is AI generating for those shareholders?

Similarly, margin per unit of IT intensity asks whether an organization is efficiently converting its technology dependency into economic performance.

Two companies can spend similar amounts on AI and produce dramatically different results. The winner shouldn’t be the company that consumes the most intelligence. It should be the company that converts intelligence into the most value.

AI needs its own measurement revolution

Every major economic transformation eventually produced new ways of measuring itself.

Industrialization gave us modern accounting.

Mass production drove the development of productivity measurement.

Global finance produced increasingly sophisticated theories of capital, risk and return.

The Intelligence Economy will need its own measurement revolution.

Companies may eventually need something resembling a Technology Balance Sheet showing their productive technology assets and obligations, and a Technology Income Statement connecting technology expenditures with the economic value those expenditures generate.

Investors will increasingly expect companies to disclose not merely how much they are spending on AI, but what they are receiving in return.

Technology executives, consequently, will need to become economic leaders as well as technical leaders. Boards will increasingly expect CIOs and other technology leaders to explain affordability, productivity and value — not simply reliability, security, modernization and innovation.

The same problem exists at the national level.

GDP measures economic activity remarkably well, but it was never designed to measure intelligence as a productive resource.

That suggests the need for complementary concepts such as gross domestic intelligence: an attempt to understand the intelligence capacity that increasingly enables economic activity.

Whether that particular measure ultimately becomes standard is less important than the underlying idea.

If intelligence has become an economic resource, eventually we will have to measure it as one.

The question that comes after the hype

None of this argues that AI will fail.

Quite the opposite.

AI may transform productivity, science, medicine, education, finance, manufacturing and almost every other significant area of human activity.

But technological capability does not repeal economics.

The railroad was transformative. So was electricity. So were telecommunications and the Internet. Each also experienced periods when infrastructure investment ran ahead of sustainable economic returns.

AI may follow a similar pattern.

The critical divide may therefore not be between companies that adopt AI and companies that don’t.

It may be between those that understand the economics of intelligence and those that simply consume more of it.

We already know how to make machines increasingly intelligent.

The next challenge is learning how to make that intelligence economically productive, affordable and sustainable.

Communities will want evidence of societal value. Investors will want evidence of shareholder value. Boards will want evidence of business value. Governments will want evidence of national value.

All of those demands eventually converge on one question:

What is intelligence worth?

The industrial revolution created modern accounting. The information age created digital technology management. The Intelligence Economy may require technology economics.

And the most important innovation of the AI era may ultimately turn out not to be another model, another chip or another trillion-dollar generation of data centers.

It may be the measurement system that finally allows us to answer the question behind all of them:

Does the value created by intelligence exceed the cost required to produce it?

Everything else follows from the answer.

IT modernization remains a key pillar of CIOs’ strategic agendas, and even CEOs are coming around to the value that addressing legacy systems has in fueling transformation and innovation.

Yet a solid majority of application and infrastructure modernization projects are failing to meet expectations, with many IT leaders having to cut IT corners to divert money for AI, in addition to all the traditional problems that plague them.

Sixty-one percent of organizations have had to pause, delay, scale back, or fully abandon IT modernization initiatives in the past 24 months, according to a recent survey from managed services provider Ensono.

Major IT projects fail for a variety of reasons, including poor project management and a lack of clear metrics, but tight budgets and cost overruns create tangible impediments. More than seven in 10 respondents to Ensono’s survey say their modernization initiatives have exceeded the original budgets, with 27% exceeding budgets by 51% or more.

The failure rate is often due to a combination of factors, but IT budget diversion to AI projects is a major challenge for IT leaders, says Brian Klingbeil, chief strategy officer at Ensono.

“People are redeploying spend toward AI projects,” he says. “There’s a lot of pressure to keep up with everyone else.”

Reallocated budgets

Many organizations are stuck in long-term IT modernization traps, such as scope creep, while facing declining budgets for traditional IT upkeep due to AI.

“In what I see, scope creep contributes the most, and it is a discovery problem more than a governance one, because the organization learns what the legacy estate actually does at the moment it starts to move it,” says Michele Grant, executive global director at Cognizant, of IT modernization delays and failures.

“But AI budgets are a real competitor for the same money, and over the past two years I have watched modernization funding reallocated toward AI initiatives that promise a faster visible return,” she says.A recent report from digital adoption platform provider WalkMe found that, while digital transformation budgets grew from an average of $39.4 million to $54.2 million in a single year, most of that spending went to AI-related projects, says KJ Kusch, global field CTO there.

“I wouldn’t call it scope creep,” she adds. “It was a deliberate move.”

Kusch also sees adoption problems contributing to poor IT modernization outcomes when newer IT systems are too complicated for employees to use. “Users experience too much friction, so they go back to the ways they worked before,” she says.

The irony, Ensono’s Klingbeil says, is that AI can help accelerate IT modernization projects by performing tasks such as code discovery and cleaning up legacy code. Most organizations haven’t tried it yet, but using AI tools can significantly cut the costs and timelines of IT modernization, he adds.

The irony, Ensono’s Klingbeil says, is that AI can help accelerate IT modernization projects by performing tasks such as code discovery and cleaning up legacy code. Most organizations haven’t tried it yet, but using AI tools can significantly cut the costs and timelines for IT modernization, he adds.

“Two years ago, if you had a legacy platform you weren’t happy with, for whatever reason, choice A was to invest $150 million and five years of your life and maybe get lucky and pull it off,” he says. “Choice B was suck it up and live with it, and there was no choice C.”

The price of misalignment

Another factor that can sink an IT modernization initiative relates to organizational outcome and cost misalignment, Cognizant’s Grant says.

“Modernization is approved as a technology program and then asked to carry a business outcome that requires process and organizational change, and the cost of that change was never inside the original number,” she says.

It doesn’t surprise Grant that 61% of organizations in the survey had to pause, scale back, or scrap IT modernization programs. A pause is sometimes the right choice, she says.

“When the business case was written against an operating model that has since changed, continuing to spend against that case is the more expensive choice,” she explains. “What I would look at in that 61% is not the pausing. It is that the organizations I see pause without naming the condition that would let them resume, and a program that stops with no restart condition turns into spend that nobody owns.”

A good way to control IT modernization costs is to fund the program in phases tied to named outcomes and give one executive the authority to stop the work, Grant recommends.

“A program that can only be slowed by consensus is never slowed; it is extended,” she adds.

AI needs modernization

Even as AI initiatives take spending away from modernization efforts, the two transformation priorities are closely linked.

Stu Bradley, senior VP of risk, fraud, and compliance solutions at analytics and data management vendor SAS, emphasizes that IT modernization leads to better AI outcomes.

“Seeing AI and modernization as competing budget lines is a bit of a trap,” he says. “In reality, AI and modernization are increasingly two sides of the same coin. Many organizations are discovering that the AI capabilities they want depend on investments in data, integration, infrastructure, and governance that they’ve deferred for years.”

Recent SAS research found that only 17.5% of organizations have data infrastructure fully optimized to support agentic AI readiness, he notes.

“Rather than argue over competing budgets, leaders need to understand which modernization investments are prerequisites for the AI outcomes they’re aiming to achieve and fund them as part of the same business case,” he adds.

It also doesn’t surprise Bradley that most IT modernization pause or fail. “When you consider the pace of technology and how quickly priorities are shifting around AI, I’d frankly be more surprised if organizations weren’t regularly reevaluating their transformation projects,” he says.

But pauses or delays in project aren’t always failures, he notes. The priority during a pause should be identifying and addressing the issues that stalled the project, he recommends.

“CIOs should be willing to reevaluate initiatives rather than let momentum blindly drive continued investment,” he says. “Where organizations get into trouble is simply bumping the project into the next budget cycle hoping that somehow conditions will be different.”

See also:

• 6 strategies for accelerating IT modernization
• 8 IT modernization traps CIOs must avoid
• Massive modernization: Tips for overhauling IT at scale

A dashboard showing 92% CPU utilization may look alarming. It may also mean that infrastructure is being used efficiently while the service meets its SLA, transactions complete normally and automatic scaling has adequate headroom. A system running at 35% CPU, meanwhile, can still be experiencing a serious customer-facing failure.

Both numbers matter to engineers. Neither tells an executive whether customers are getting the service they expect, whether the company is losing money or whether management needs to intervene.

This distinction is becoming increasingly important as businesses depend more heavily on digital services. IT teams already collect enormous amounts of telemetry, from infrastructure metrics and application logs to distributed traces and incident data. The challenge is making those signals useful outside the engineering organization.

For business leaders, the useful measure of observability is not how much of the technology stack can be monitored. It is whether a change in that stack can be connected to a customer journey, a business process and eventually a financial or operational outcome.

Technical severity and business severity are different things

Consider a payment API that normally responds in 300 milliseconds. Following a software release, response time increases to 1.2 seconds.

The infrastructure may still look healthy. Availability remains at 99.99%, CPU and memory are within normal ranges, and very few requests fail outright. Based on a conventional infrastructure dashboard, the incident may not appear particularly serious.

The business experience can look very different.

If the API sits in the authorization path for card payments, additional latency may push some requests beyond downstream timeouts. Customers experience slower payments, retries or occasional declines. Merchants and mobile applications retry transactions, adding further load to the system. Payment completion begins to fall, abandoned transactions increase and support receives more complaints.

A service that appears technically available can therefore be failing at the job the business needs it to perform.

This is why technical severity and business severity need to be treated as separate dimensions. A relatively small degradation in a high-volume payment service may have a larger business impact than the complete outage of a rarely used internal application. This also aligns with established SRE practice, where service objectives are defined around what users experience rather than the infrastructure metrics that are easiest to collect. Infrastructure metrics remain essential for diagnosis, but they do not establish business priority on their own.

For senior management, the relevant questions differ from those asked by the engineer investigating the incident. How many customers were affected? How much transaction value is at risk? Is the impact increasing? How quickly can the service recover? Does the situation justify intervention or additional investment?

This also means an executive observability view should remain deliberately small. In practice, 8–12 measures can often provide more management value than a dashboard containing dozens of technical indicators. Critical-service availability, customer journey success, user-impacting latency, the number and business impact of major incidents, recovery time, change failure rate, recurring problems and technology cost relative to demand provide a useful core. Technical debt or lifecycle exposure can be included where it represents material business risk.

The objective is not to hide technical complexity from management. It is to present the level of information at which management can plan.

An engineering dashboard might report 87% CPU utilization, 1.4-second latency, a 2.1% error rate and 17 restarted pods. An executive view of the same event should look closer to this: payment success is 97.9% against a 99.5% target, approximately 8,400 customers are affected, around €1.2 million in transaction value is exposed, the current risk is approximately €70,000 per hour, and recovery is expected within 35 minutes.

The second version tells management what the first cannot: how serious the event is, which part of the business is affected, how quickly the impact is accumulating and whether intervention is required.

More telemetry will not create the missing connection

A sophisticated observability stack does not guarantee business insight. A company can have application performance monitoring, distributed tracing, centralized logging, infrastructure monitoring and real-time dashboards while still struggling to explain what a technical event means commercially.

The missing element is usually the mapping between technology and the business services it supports.

Infrastructure is naturally modeled in hosts, containers, APIs, databases and dependencies. The business operates in payments, orders, deliveries, claims, customer logins and other journeys. Unless these two views are connected, observability reaches the technology boundary and stops there.

I would not start by buying another observability platform. I would start by establishing a chain that the organization can follow consistently:

Business outcome → customer or business journey → service → applications and dependencies → telemetry

Once this exists, incidents, changes, costs and business outcomes can be connected to the same model.

Database latency, for example, is primarily an engineering signal. If that latency increases checkout API response time, which then reduces payment completion by 1.8%, the organization has established service impact. Add the estimated transaction value at risk and the same event becomes something management can evaluate.

The underlying technical measurement has not changed. Its context has.

Someone has to own the translation layer

Connecting these worlds becomes difficult because the relevant information usually belongs to different parts of the organization.

Infrastructure teams manage infrastructure metrics. Application teams understand application telemetry. Service management tracks incidents. Finance owns cost information. Product and business teams understand customers, revenue and operational outcomes.

Each dataset can be accurate and useful independently while the organization remains unable to explain the business consequence of a technical event.

This also creates an incentive problem. Infrastructure may optimize utilization, operations may optimize incident closure, development may optimize delivery speed, and product may optimize conversion. Every function can perform well against its own KPIs while the end-to-end service deteriorates.

The translation between technical and business performance therefore cannot sit entirely with an observability or DevOps team. Those teams can build excellent monitoring capabilities, but they can rarely decide why a 1% degradation in one process represents a material financial risk while a much larger degradation elsewhere has little business consequence.

Business leadership cannot own the technical translation alone either. Executives should determine what matters and what level of risk is acceptable, but they should not need to interpret distributed traces or determine which microservice caused a decline in conversion.

The model I have seen work best is shared but accountable. Business defines what matters. Product or service owners own the outcome. Engineering and SRE establish telemetry and technical causality. Data connects those signals to measurable business impact. One service owner remains accountable for the complete chain.

Business observability must be designed before the incident

Trying to calculate business impact after an outage is often too late.

An incident can reveal relationships that were not previously understood, but it cannot recreate information that was never collected. If telemetry contains the application, endpoint, timestamp and exception type but no way to correlate the event with a transaction, channel, customer journey or outcome, the business impact may be extremely difficult to reconstruct afterwards.

The relationship between system performance and business KPIs should therefore be established during service and product design.

For a critical customer journey, teams should know which applications and dependencies support it, and which technical signals indicate degradation. Telemetry needs enough context to correlate performance with transaction type, service, channel and outcome. Business systems can then provide the financial or operational information required to quantify the impact without placing sensitive business data directly into technical logs.

Baselines are equally important. A statement such as “latency exceeded one second” becomes considerably more useful once historical data shows what typically happens to completion, abandonment or support demand at that threshold.

This is what I mean by designing business observability alongside technical observability. The translation should exist before somebody needs it in the middle of an incident.

Business criticality should determine what gets observed most closely

Not every system deserves the same level of observability investment.

Technical complexity is an unreliable way to establish priority. A sophisticated platform may be fascinating from an engineering perspective while having relatively little effect on customers or core operations. A much simpler service may sit directly in the path of every payment, shipment, customer login or regulatory process.

Observability priorities should therefore follow business criticality. Revenue exposure is one consideration, but it is not the only one. Customer dependency, operational importance, regulatory obligations, the number of processes dependent on a service, and the consequences of failure can all change how closely a system needs to be monitored. The same principle appears in established cloud architecture guidance, which recommends identifying and scoring user and system flows according to their importance to business requirements and using that criticality to guide design, testing and incident management.

This creates a more defensible basis for investment. Instead of trying to achieve the same observability maturity everywhere, organizations can concentrate engineering effort where degradation would produce the greatest business consequence.

Better observability can change where the business invests

I saw the practical value of this approach on a high-volume banking and payment platform where performance deteriorated during peak periods.

The initial evidence suggested a capacity problem. Transaction response times increased, occasional timeouts appeared and infrastructure monitoring showed elevated utilization. Increasing compute capacity seemed like the natural response, along with the additional infrastructure budget required to support it.

Application and transaction-level observability changed that conclusion.

By correlating infrastructure metrics with API latency, transaction processing times, database activity, external-system response times, error rates and successful and failed transactions, we found that overall compute capacity was not the primary constraint.

Most transactions were still processed quickly. The degradation was concentrated in a relatively small subset that followed a path involving synchronous calls to another system. Under peak load, those calls created queueing and connection-pool contention, which then propagated into the main transaction flow.

The decision changed from adding infrastructure to redesigning a specific part of the transaction path.

This is where observability becomes more than an incident-response capability. It can provide evidence for architecture decisions, capacity planning and technology investment. Instead of asking for budget because infrastructure utilization looks high, a CIO can show which business process is approaching a limit, what impact that limit creates and whether a proposed investment addresses the actual constraint.

DevOps practices and automation strengthen this model by shortening the feedback loop. The objective is not simply to collect operational data more frequently. It is to reduce the time between a change in technology, understanding its business consequence and taking the appropriate action. When deployment, telemetry and business outcomes can be correlated consistently, observability becomes useful for continuous decision-making rather than primarily for explaining incidents after they occur.

Reliability is becoming an economic variable

The same logic applies to reliability itself. Technology teams have traditionally aimed for high availability, but each additional level of resilience carries a cost. Moving a service from 99.9% to 99.99% availability may require substantial architectural investment, additional redundancy, operational capacity and engineering work. Whether that investment makes sense depends on what the service does.

For a critical payment platform, the additional availability may protect enough transaction value, customer trust or regulatory exposure to justify the cost. For a lower-priority internal service, the same investment could produce little meaningful business value.

This changes the reliability conversation. Instead of asking how close the organization can get to maximum availability, leadership can ask what another 0.01% of availability costs and what business loss it is expected to prevent. AWS reliability guidance makes the same trade-off explicit: higher availability typically increases cost, making it important to establish the actual availability a workload requires before investing in additional resilience.

Historical observability data can support that decision. It can show how transaction volume is changing, whether latency is approaching agreed thresholds during peak periods, when current capacity is likely to become insufficient, and what previous incidents cost the business. The same data can later show whether an architecture or capacity investment delivered the expected improvement.

As digital services become inseparable from business operations, reliability data will increasingly belong in financial planning and risk management as well as engineering. A payment-platform failure stops payments. A slow e-commerce checkout can affect conversion. A logistics-system outage can disrupt physical operations. In these environments, system performance and business performance are increasingly difficult to manage separately.

AI can interpret observability data, but it still needs context

AI will make it easier to consume the enormous volume of information generated by modern technology environments. Its most useful role may not be generating additional alerts, but correlating telemetry, changes, incidents, dependencies and business data into explanations that different audiences can act on.

An engineer will still need access to metrics, logs and traces. Management could receive a very different interpretation: payment completion declined following yesterday’s release; the impact is concentrated in the mobile channel and correlates with authentication latency; an estimated number of transactions have been affected; rollback is recommended.

That is a significant improvement over asking executives to interpret a technical dashboard.

It still depends on the underlying organizational model.

AI cannot infer reliable business meaning from technical data if the organization has never established which systems support which processes, which customer journeys matter, who owns them and which KPIs define acceptable performance. Without that context, applying AI to billions of technical measurements may produce more sophisticated analysis without producing better business decisions.

Start with the decision, not the dashboard

The question for a CIO is no longer how much telemetry an organization can collect. Modern IT environments already generate more technical information than any executive could reasonably consume.

The useful question is whether a technical change can be followed through the organization to the customer journey, business process, financial outcome or material risk it affects.

Engineers will always need detailed technical observability. That layer should remain detailed because diagnosis demands it. Executive observability serves a different purpose: helping leadership understand whether something matters, how much it matters and what decision should follow.

If 92% CPU utilization cannot tell management whether to act, the dashboard is doing exactly what it was designed to do. The organization simply needs a business layer above it.

I have seen the same pattern repeat across industries, geographies and operating models. Fortune 500 organizations spend millions on ERP transformations to modernize lead-to-cash, finance, people operations, supply chain and other core functions. For several years, those programs create a clear sense of direction. Roadmaps define the work, system integrators add capacity and execution discipline, and governance forums create visibility. Milestones give everyone a common language for progress as capabilities roll out to the business.

Then the program ends. After the go-live celebrations and hypercare fade, many organizations face what Lenovo’s Art Hu described to me in 2019 as “a sea change.” For three years or more, the answer to “what should we work on next?” was embedded in the program roadmap, and accountability was reinforced by transformation governance and third-party partners. Continuous improvement was often slowed on purpose to create capacity for the implementation. And the skills and operating rhythms that carried the organization through go-live are not always the ones that create value from the platform afterward.

This is where the ERP hangover sets in. Like any hangover, it can be painful, disorienting and harder to shake than expected. It is also manageable if you see it coming. Working with clients at this inflection point through 2026, I have seen three moves separate the organizations that lose momentum from those that build on what they just bought.

For CIOs nearing the end of a major program, these are the glass of water and two Advil you take before bed after a night of cabernet at the local CIO roundtable.

Reorient the operating model for continuous improvement

Much of what drove accountability and execution rigor during the implementation will scale back or disappear as the program winds down. To keep new ERP capabilities from dying on the vine, someone has to own the care, feeding and evolution of each one.

That owner is a capability manager, whose job is to stay in ongoing dialogue with the business or functional stakeholder about what is going well, where the opportunities to improve sit and where the business is pivoting next. A capability roadmap memorializes that conversation and gets revisited continuously. During the ERP program, milestones held steady for months at a stretch. In continuous improvement, what matters can shift week by week.

Consider a multi-brand, global CPG client nearing the first of many go-lives. They were candid about where they stood: strong at project-based implementation when the targeted outcome was static, thin on execution discipline for day-to-day work where the outcome moves. Their teams were organized around skill sets and went reactively from problem to problem across the value chain, leaving little room for proactive business enablement.

To get ahead of the hangover, they moved to a product-oriented, capability-aligned operating model. Team structures now follow the capabilities the ERP delivers, such as supply chain, finance and HR. Each capability has a product manager and the cross-functional resources to deliver end-to-end, a roadmap maintained with a defined set of business and functional stakeholders, and common agile ways of working to coordinate planning and dependencies.

Their bet is a clear one. Continuous improvement in a dynamic environment will not happen unless the operating model is designed for it, and leaving it as-is would forfeit the benefits the transformation was meant to deliver and make them poor stewards of the company’s investment.

Rethink the workforce strategy

Most ERP transformations set out to consolidate workflows from many applications onto a strategic platform: fewer tedious point-to-point integrations, less variability in how processes get done and no long tail of point solutions to maintain. Today’s cloud ERP platforms also arrive with a growing set of out-of-the-box capabilities that agents can deliver.

The implication is that bespoke development gives way to agent-driven workflows that connect native platform capabilities. Separately, the volume of AI solutions entering the enterprise will change how much manual operational work it takes to keep the lights on. The shape of the work before and after an ERP upgrade looks very different.

Our clients getting ahead of the hangover are using the quarters before go-live to reset the workforce strategy. They go job family by job family and ask a plain question: is this strategic to our future business imperatives and worth investing in, or is it a candidate for automation or outsourcing given the AI options now available?

One F500 manufacturing client is redefining the roles and skills it will need in a post-ERP world. Software development keeps getting faster and more commoditized, and the modernized platform brings more agentic capability out of the box in areas like sales and billing. They are leaning into that and reducing the resources dedicated to transactional, process-oriented work. The freed capacity funds hires who manage, integrate and orchestrate cross-functional, multi-agent workflows.

Acknowledge the two speeds ahead

This program may be winding down, but the astute CIO knows the next wave is only a matter of time. Organizations that avoid the hangover accept that they will always have two types of work: project work like the big ERP program, which is milestone-driven, and product work, which is continuous by nature. They set criteria for sorting work into each, define specific ways of working for both and expect the two to co-exist. Most importantly, they define how a capability transitions between them.

Action for CIOs

If your final go-live is 12 to 18 months out, the hangover is still preventable, and preventing it costs very little. Name the capabilities the platform will deliver and the person accountable for each. Start the workforce assessment now, job family by job family, while there is still runway to reskill and rebalance. Write down the criteria that separate project work from product work, and the path a capability takes between them. Then put the first capability roadmap in front of a business stakeholder before hypercare ends, so the muscle exists before you need it. All of it is easier while the governance forums, the partners and the executive attention are still in the room. There’s already a backlog of enhancements that have been deferred until after go-live. The organizations that get lasting value from ERP start building for the day after while the implementation is still running.

November 2022 was a big milestone for AI when ChatGPT was released. But in terms of enterprise transformation, November 2024, when Anthropic released MCP as an open standard, was maybe an even bigger transition point.

MCP ushered in a new age. Before, AI was primarily used to answer questions, but with MCP, AI models could start directly interacting with data sources and tools, allowing them to carry out tasks on behalf of users, turning AI chatbots into AI agents. Most leading-edge AI platforms today are agentic in nature, doing work like sending emails, making purchases, and performing scheduled tasks. But that’s just baseline functionality.

When integrated with corporate workflows, AI agents have the potential to carry out business processes that were previously either too complex, unpredictable, or costly to automate. And deploying agentic AI in the enterprise could be as simple as allowing AI assistants to access email systems and document repositories, or enabling pre-built agentic functionality in Salesforce and other enterprise software platforms.

Earlier this year, Deloitte released a survey of more than 3,200 executives showing that 75% of organizations use at least some agentic AI. And within the next two years, 95% said they expect to use AI agents.

But to gain competitive advantage, enterprises need to do more than just deploy the same AI agents everyone else is, and some companies are doing just that. In the Deloitte survey, 30% of enterprises are already redesigning key processes around AI while 34% are even starting to use it to deeply transform their business.

Today, 20% say they’re using agentic AI moderately, 2% extensively, and 1% say it’s fully integrated as a key component of their operations. Yet within two years, 46% expect to be using agents moderately, 23% extensively, and 5% as key components of their business.

AI is already paying off for some

AI is showing signs of transformative impact in terms of increased efficiency and productivity, more than double from a year ago, according to Deloitte’s findings. Some leaders are even seeing an impact on their bottom line, with 20% of enterprises surveyed reporting increased revenue. Here’s how AT&T is doing it, for instance.

“Last year we had five-X cash ROI on our AI investment,” says Andy Markus, the company’s chief data and AI officer. “We’ve hit the flywheel.”

AT&T has built its own AI platform, he says, and that investment is paying off. The platform is model-agnostic, he adds, and the company controls the knowledge it uses, grades its accuracy, and monitors the platform for governance and accountability.

“It doesn’t require as much development anymore,” he says, “and now we’re just generating more value by applying this core best-in-class functionality.”

AT&T didn’t bet on any one particular AI vendor either since the technology is changing so rapidly. “We can’t be beholden to any one provider,” he says. “We can change out the model and framework. What makes it useful is our data, knowledge, and expertise. That makes the difference.”

Another thing that helps drive ROI is that the platform is accurate and reliable. “When we apply it to our own data, we’re now converging on 100% accuracy for complex queries,” he says. “That’s what drives value.”

AT&T isn’t new to AI, Markus says. “We have a deep history of AI, including machine learning and classical,” he says. “But we’ve ramped it up with generative AI and agentic AI.” Today, the company has more than 1,000 agentic workflows either being built or already in production, he says, yet it’s trying to minimize the total number of agents by building them to be multi-purpose. “We’re making these agents super flexible and bringing the right information to them and dictating the direction they take.”

Agentic AI might feel like it’s a new thing, he says, but at AT&T, it’s matured to the point where it’s starting to feel like traditional software. “You build and optimize, and we’re in that cycle,” he says. “We do that in a routine fashion.”

So AT&T is ahead in the game, and that’s the strategy. While many companies are waiting for AI platforms to mature to the point where deployment is easier, more reliable, and more cost effective, AT&T isn’t, and just builds what it needs.

“By the time a lot of it becomes commonplace, we’re already there,” Markus says. “We’ve already figured out the problems at the leading edge and are ready to make this standard practice.”

Maximizing the resources within reach

Traditionally, the insurance industry has been slower to adopt AI than others due to legacy systems, regulations, and, of course, because whole business model is about avoiding risk. But some companies, like 180-year-old New York Life, are bucking the trend by modernizing data infrastructure and rethinking business processes and workflows.

Matt Marze, CIO at New York Life Group Benefits Solutions, says his group has been on a technological transformation journey for over a decade. “And now we’re supercharging it,” he adds. “And both generative and agentic AI are part of that strategy.”

His part of the company focuses on the group benefits market, offering employer-sponsored life and disability insurance, as well as leave management and wellness products. And two core aspects of the transformation are the overall modernization of the group’s technology and building its AI platform.

“We’ve done a lot of tech modernization to drive our cloud adoption and strategic data management, and we’ve consolidated all our business applications on a set of platforms, both commercial and our own,” says Marze. “We’ve also assembled an AI operating platform or system to give us full-stack AI capability.”

Similar to what AT&T is doing, New York Life Group Benefits is building its own custom AI business engine.

“It’s a lot of cloud-native capabilities in AWS and other clouds, and open source tools from companies like LangChain,” he says. “It’s not point solutions. We’re steering clear of embedded AI from commercial platforms from Salesforce or other providers. We’re looking to enable our own AI stack and drive it across our business.”

The reason some companies have to build their own AI infrastructure is because the vendor landscape in this space is still lagging, says Kevin Martelli, consulting AI solution development leader at EY Americas. “There’s not something bringing all these pieces together to make it easy for the business to operate,” he says.

Instead, companies often pull together what they need from their databases and other tools. Some functionality is provided by the foundational model companies themselves, he says. “But a lot of times it’s up to you.”

At New York Life Group Benefits Solutions, initial priorities included the service operation, employee productivity, and sales growth.

“We have both generative AI and agentic solutions deployed today,” Marze says.

Take compliance, for example. “We voluntarily go through SOC 1 and SOC 2 audits,” he says. “It’s traditionally a very labor-intensive process but we’ve deployed agentic AI to gather a lot of the evidence we need to collect and help prepare it for the folks who drive the audits for us. It saves a lot of time.”

Currently, the AI models used are primarily from Anthropic, and enterprise editions are deployed in a private cloud on AWS, with all the governance and security layered around it because, ultimately, the business is responsible for what the AI does. “You still own it,” he says. “AI may help you, but if it’s wrong, you own it.”

One of the most transformative projects involves rethinking the entire employee experience, building an AI-powered environment based on user personas.

“That’s something we’re working on and hoping to roll it out later this year for the first persona,” he says. It’s a command center experience, a next-gen AI-enabled user interface that replaces the need for employees to navigate all the work systems directly, he adds.

“It’s the future of how we want to enable work,” he says. “It’s intent- and objective-based, and specific to your persona and role, continuously surfacing priorities that are ranked and role-aware with guidance and recommendations, and the work is prepared and orchestrated.” For example, a sales exec with a territory to run might go into Salesforce and look at a to-do list and follow up on things. But that employee still has to decide how to do that work, and how it fits into their part of the overall sales plan.

“In the future, we want that plan to be the context in the new environment, and orchestrate and curate the work for that sales executive, showing real-time telemetry about how they’re progressing on their objectives,” he says. “It’s a different way of thinking to be more productive and build relationships with clients.”

This means that the business has to rethink and redefine the work that goes into the persona-based work roles, he says, and integrate the process flows across multiple systems.

“We’re trying to make the tech invisible,” he adds. “So the experience is elevated, and the human interaction is more seamless, productive, and more valuable.”

Focus on the bottom line

In an Accenture survey of 3,000 business leaders released in July, 23% of companies report widespread and sustained business value from AI, which is down from 32% earlier this year.

As agentic AI goes from theory, to POC, to pilot, to production, businesses are seeing the real costs of the technology, not just in terms of risks, but the financial costs of agents going back and forth with AI models. The inference costs of any one query might be going down, but the total cost for adding agentic AI to the business process is going up. Gartner reported in August that AI inference costs per agentic workflow will increase more than five times through 2028.

For New York Life Group Benefits, this means a focus on the best outcome, rather than having the best AI model. AT&T is also looking at minimizing agentic costs since the company is currently using 45 billion tokens a day. If all of these were routed to the most cutting-edge model, that would be very expensive, and at some point, the costs outweigh the benefits.

“We have an AI gateway that sits between all our requests and endpoints, and directs the request to the right endpoint,” says AT&T’s Markus. “For example, some requests might not require the latest and greatest AI model, but an older, cheaper one would work just as well.”

AT&T also fine-tunes its own models, and trains small language models, he adds. “We’ve got that muscle built now and are optimizing that whole process.” With the right training and data, a small language model can be just as accurate as an LLM for some use cases.

“So when the super agents call subagents, a lot of them are small language models as well,” he says, “And we’re saving 90% of the cost.” Plus, AT&T negotiates price concessions with its vendors, he says. “We’re getting more mature on this.”

But most companies are lagging when it comes to AI cost control. McKinsey found that AI spending increases nearly four-fold as enterprises move from isolated use cases to widespread AI adoption, and a vast majority of organizations report exceeding their AI budgets.

The problem is that AI usage patterns aren’t predictable, governance is immature, teams don’t know which models or tools they should use, and new AI development tools allow employees to build new applications, workflows, and autonomous agents with little effort — and little oversight.

There are many enterprise processes where cutting-edge AI — or any AI at all for that matter — isn’t the solution.

“I don’t need a non-deterministic airline ticketing system or bank app experience,” says Nicholas Mattei, chair of the ACM special interest group on AI and professor at Tulane University. “There are places where agentic workflows are appropriate and mission-critical processes where they’re not. AI isn’t going to speed up your point of sale system.”

Meta won’t judge employees by how much they use AI when it comes to annual performance reviews, despite early efforts to drive AI adoption focusing on so-called token maxing.

The company has told employees that it “will not use AI adoption dashboards or token counts to evaluate impact,” according to  a report by The Information.

The announcement came in an internal memo from executives Maher Saba and Santosh Janardhan, which said that instead of measuring AI usage, “managers should look at output quality, velocity, problem complexity and scope taken on.”

This marks a culture change for Meta, where engineers had previously competed to consume the most AI tokens, displaying their scores on a leaderboard. Meta then discovered that its employees were being diverted from regular work because they were using AI to carry out additional tasks to boost their scores.

Amazon had similar results when it implemented a leaderboard to track AI use; it also found that some employees were trying to game the system by using AI to complete unnecessary tasks, and it has now deleted it.

The company, however, does also monitor employees’ use of AI for training purposes, in a program introduced in April, but this is information was not used to measure employee performance.

Meta had already started to look askance at the concept of using AI metrics as a tool to assess employees. Earlier this year, Chief Technology Officer Andrew Bosworth told employees in a memo that “nobody should be using AI tools just for the sake of using them,” adding that “token usage alone is not a measure of impact of any kind.”

This article first appeared on InfoWorld.

As spending on cloud technologies grows, so does waste. The Flexera 2026 State of the Cloud Report found that 27% of organizations expect to spend more on cloud this year, with 17% already exceeding their budgets over the previous 12 months. The estimated share of wasted cloud spend has already crept up to 29%, undoing several years of progress, undoing several years of progress.

Companies are rapidly investing in cloud technology, but often understand less about how to use it fully and efficiently. That is not a coincidence, and it is exactly the gap FinOps is meant to close. It is also why the practice is moving out of the finance department and into the strategy conversation.

What is FinOps?

FinOps is a blended operational framework that maximizes technology value by uniting engineering (DevOps), finance, and business teams. It involves close collaboration to break down silos between tech and finance, with shared ownership of cloud spend across engineering, finance, and business teams.

What distinguishes FinOps is real-time visibility into what is being spent and why. It also treats optimization as continuous work rather than an annual cleanup exercise.

FinOps is important because cloud spending isn’t like a typical budget line. It’s more variable and usage-based, so relying on an annual review doesn’t work. Engineers can quickly create infrastructure, scale it, and tear it back down in a day, making forecasting more challenging than in the past.

What FinOps does is change who sees what. Engineers have more insight into the actual cost of a build. Finance gets numbers it can trust. Business leaders can tie spending directly to business outcomes. It removes much of the guesswork and turns cost data into a shared language rather than a monthly surprise.

As Siarhei Sukhadolski, Chief Delivery Officer & Head of Competence Center at Innowise, puts it, “For a long time, FinOps meant only cutting the bill: find the unused stuff, resize a few instances, and report the savings. That still matters, but it’s not what separates companies today. The ones pulling ahead are using FinOps to make faster, smarter calls about where their tech spend actually pays off. That’s a different job, and it shows up directly in how fast a company can move.”

How FinOps spending has changed

Only a few years ago, FinOps was mostly focused on cloud infrastructure spending. Today, that focus increasingly includes AI-specific investment. The FinOps Foundation 2026 State of FinOps Report found that 98% of organizations now manage AI spend specifically. FinOps has also expanded well beyond cloud infrastructure. It’s more common now to see FinOps coverage extend to licensing (64%), private cloud (57%), and data centers (48%). Around 90% also manage SaaS spend or plan to do so within the next year.

It’s also worth noting that the same FinOps Foundation report found that 78% of teams report directly to the CTO or CIO rather than operating solely within finance departments. To us, that reporting line says a lot. It suggests that companies increasingly see technology spending as a strategic lever rather than simply a line item to reconcile.

How AI and cloud spending are moving in the same direction

The trend toward bringing AI and a broader range of technology spending into FinOps is backed up by a Gartner report, which estimates that global IT spending will hit $6.31 trillion by the end of 2026. That’s up 13.5% from the previous year. Data center systems spending is expected to grow 55.8%, with generative AI model spending more than doubling over the same timeframe. Gartner, in a separate forecast, expects public cloud services to grow by 21.3% in 2026, with the market reaching $1.48 trillion in value by the end of 2029.

We see these figures as two sides of the same shift. AI workloads are also usage-based, which makes them more unpredictable, partly because some teams haven’t had to consider unit economics before. A fine-tuning run or a forgotten inference endpoint can quickly become one of the biggest items on a cloud bill. Most teams don’t have the tagging, forecasting, or accountability needed to catch those costs before they get out of control.

“AI spend just behaves differently from a normal application workload. It spikes, it’s hard to pin on one team or feature, and you often don’t know the real cost per outcome until the invoice lands. Companies that already had solid FinOps habits before AI adoption took off are adjusting faster because visibility and ownership were already part of how they worked. Companies that treated FinOps as an annual cleanup are the ones getting caught out.”

Siarhei Sukhadolski, Chief Delivery Officer & Head of Competence Center at Innowise

Why visibility and shared spend ownership create an advantage

Flexera numbers on discount usage point to the same issue: fewer than 50% of organizations are using the most basic cost optimization tools. The adoption of tools like reserved instances or savings plans is slow, with only 48% of companies using Google Committed Use Discounts and 45% using AWS Reserved Instances. Too many others are leaving low-risk savings on the table.

In many cases, the real problem is a lack of ownership and visibility. If no team owns the cost of a workload, no one has enough reason or enough information to choose the right pricing model. That is where the competitive gap starts to open: some companies can explain and act on their spend quickly, while others cannot.

“A mistake we still see a lot is trying to optimize the bill instead of the system behind it. Deleting unused resources saves money once. Redesigning how workloads scale, how environments get spun up, and who’s on the hook for what keeps costs under control for good. That’s the difference that turns into a real competitive edge later.”

Siarhei Sukhadolski, Chief Delivery Officer & Head of Competence Center at Innowise

What visibility and shared ownership look like

FinOps operates well when at least three structures are in place.

• Every workload or inference endpoint has a clear owner tied to its cost.
• Cost and usage data are shared and available to everyone who needs them before they have to ask.
• There is an ongoing review cadence designed around continuous optimization.

Teams that jump into dashboards before assigning ownership and establishing the data flow often end up with visibility but no accountability. Teams that start with ownership, even with basic tooling, get a different result. They tend to see savings stick instead of resetting every few months. That proper order is the single biggest predictor we have seen across cloud and AI cost engagements.

What business leaders need to know

There is a simple test a CEO or CFO should apply to FinOps. It’s whether the company can clearly state what a workload costs and whether it is worth that cost right now. Does it take finance three weeks to answer? Can the company provide an answer in real time? Are there live numbers and clear ownership behind every workload? That is what will enable leaders to make confident calls on where to invest and where to pull back.

FinOps is becoming a proxy for how well a company manages technology. With shared ownership comes high visibility. Add in continuous optimization and companies gain an advantage. These are not just cost-saving tactics. They represent operational discipline, separating those who can move quickly on AI from those who spend heavily only to find themselves still behind the rest of the pack.

Organizations often celebrate an AI launch at the moment the real work begins. The platform is available, the policy is published and employees have completed training. But none of those milestones tells a CIO whether work has improved, decisions are stronger or employees know when human judgment must override an AI recommendation.

This gap is visible in Kyndryl’s 2026 People Readiness Report. In a survey of 1,100 senior business and technology leaders across eight countries, 57% said AI was embedded in core processes or deployed broadly, while only 23% described their workforce as fully ready to use it successfully. Just 32% said their organizations had achieved at least one of their top two AI objectives. Technology deployment is advancing faster than the organizational capacity needed to turn it into value.

In transformation work, I have learned to be cautious when activity is presented as evidence of adoption. License activation, training attendance and prompt volume are easy to count. They do not show whether people can apply AI responsibly in a workflow or whether that workflow produces a better outcome.

Many CIOs now recognize that usage does not equal value. The next challenge is more difficult: creating an evidence chain that explains not only whether results changed, but why. That chain connects four layers – readiness, demonstrated capability, workflow behavior and business results.

Why deployment measures are insufficient

Many programs still treat workforce readiness as a downstream activity. Leaders select a platform, configure technical controls and announce availability. Training is then expected to solve every remaining problem: unclear use cases, employee anxiety, weak manager support, policy uncertainty and processes that were never redesigned.

When employees hesitate, leaders may interpret that hesitation as resistance. In my experience, it is often a rational response to ambiguity. People may not know which data they can use, whether an output must be verified, who remains accountable for a decision or how AI will affect the value of their role. A generic demonstration cannot answer questions that are specific to a job and workflow.

One practical readiness test I use is to ask people in different roles to describe the same AI-enabled workflow. Can they agree on its purpose, the information the system may use, the person who owns the outcome and the point at which a human must intervene? If not, the organization is not ready to scale. That disagreement is valuable evidence: It gives leaders a specific agenda for process design, communication, governance or learning.

Human involvement also should not be defined uniformly. A Stanford Digital Economy Lab study collected preferences from 1,500 domain workers and assessments from AI experts covering more than 844 tasks across 104 occupations. It found varied expectations for the level of human agency different tasks should retain. The practical implication is that leaders should not frame every use case as a choice between full automation and no automation. They should define the degree of human judgment each task requires.

Build an evidence chain for changed work

A useful AI adoption scorecard should answer four executive questions.

1. Readiness: Do people understand the purpose and boundaries? Readiness is more than awareness that a tool exists. Employees should be able to explain what the use case is intended to improve, which data is permitted, what outputs require validation, who owns the final decision and how to escalate a concern. Measure this with short scenario-based checks rather than confidence surveys alone. Present a realistic situation involving restricted data, an uncertain output or an exception to the normal process. Ask employees what they would do and why. A high self-reported comfort score is not a substitute for a correct decision.
2. Capability: Can people demonstrate the required judgment? Enterprise AI literacy provides a common foundation, but adoption requires role-based practice. A finance analyst, field supervisor and HR partner may share responsible-use principles, but they should not receive identical exercises or be assessed against identical criteria. Capability evidence should come from a demonstration in a realistic environment. Can the employee identify a plausible error, validate an important claim, document the basis for a decision and recognize when the case exceeds the system’s approved scope? This moves measurement from course completion to observable proficiency.
3. Behavior: Is the approved workflow being followed? Behavior measures whether the new practice has become part of the work. Platform analytics can contribute evidence, but they are not enough. CIOs also need to know whether people are completing required reviews, documenting decisions, escalating exceptions and avoiding unapproved workarounds. The target should not automatically be maximum usage. Some cases should remain human-only, and a high override or escalation rate may signal good judgment rather than poor adoption. Metrics must be interpreted in the context of the workflow and its risk.
4. Results: Did performance improve without unacceptable tradeoffs? Results should be defined before a pilot begins and compared with a credible pre-AI baseline or control group. Depending on the workflow, the relevant measures might include cycle time, first-pass quality, rework, error rates, cost, safety, risk events or stakeholder experience. Efficiency should always be paired with a quality or risk guardrail. Faster output is not progress if it creates more corrections, weakens decisions or transfers hidden work to another team.

In practice, consider an AI-assisted security-alert triage workflow. The desired outcome might be a reduction in the time required to classify high-priority alerts. The human accountability point is explicit: An analyst approves the severity classification and response action.

Readiness means analysts understand which information may enter the system and when escalation is mandatory. Capability means they can detect a plausible but incorrect severity recommendation. Behavior means eligible alerts move through the approved review path, with overrides and escalations recorded. Results mean triage time improves without increasing false negatives or delaying containment.

I recommend assigning an owner, evidence source, review cadence and decision threshold to each layer. The pilot should scale only when the desired behavior appears and the business outcome improves without breaching its quality, safety or risk guardrail. If usage rises but capability or results do not, the response should not automatically be more training. The use case, workflow, controls or management support may need to change.

This approach also makes cross-functional accountability clearer. IT enables the platform, data and controls. Business leaders define the work and desired result. Human resource and learning leaders build capability. Legal, compliance and security clarify boundaries. Managers reinforce behavior, while employees contribute the operating knowledge needed to make the workflow effective. The CIO’s orchestration role is to keep those contributions connected to the same outcome.

A 30-day test CIOs can start now

The World Economic Forum’s Future of Jobs Report 2025 found that 63% of surveyed employers viewed skills gaps as a leading barrier to business transformation. In response to expected AI disruption, 77% planned to reskill or upskill existing employees by 2030. More learning activity alone will not close the gap. Leaders must determine whether learning changes decisions, practices and results.

Over the next 30 days, ask each participating business unit to select one workflow and do six things:

1. Establish its current performance baseline.
2. Define one outcome AI is expected to improve.
3. Name the person accountable for the workflow result.
4. Identify one behavior that must change and one human decision that must remain.
5. Set a quality, safety or risk guardrail that cannot be traded for speed.
6. Review evidence from all four layers weekly and decide whether to scale, redesign or stop.

This creates a much stronger management conversation than reporting licenses, course completions or prompt counts. It shows where the evidence chain is breaking. A team may understand the rules but cannot challenge outputs. Employees may be capable but unable to use the approved tool within the actual process. The behavior may change while the business result remains flat. Each pattern calls for a different intervention.

Durable AI value will not come from the highest volume of activity. It will come from making expectations clear, giving employees realistic opportunities to practice, instrumenting how work changes and holding each use case to an explicit outcome and guardrail. A deployment turns the system on. Adoption changes how work is done. The evidence chain tells a CIO whether that change deserves to scale.