Discount your AI ROI because mileage always varies

Everyone has been car shopping and noticed the miles per gallon printed on the window sticker. You get excited when you see a number like 35 MPG, but once you drive the car home, your dashboard seems to stay closer to 26. It often feels as though those numbers assume you are driving downhill with the wind at your back.

A similar pattern shows up in conversations about AI productivity. Whether the estimates come from a major consulting report, a vendor eager to sell the latest platform or an urgent request from a CEO for a quick ROI projection, they almost always paint an overly optimistic picture. The results look great on paper, but they rarely hold up in practice. When leaders plan around those inflated expectations, they set themselves up to miss the mark.

As a digital and strategy consultant, I have found that we need a better way to set realistic expectations, one that balances the excitement of potential with the discipline of execution. Interestingly, the inspiration for that approach came not from technology but from finance.

Borrowing from finance: The power of discounting

Anyone who has taken an introductory finance course remembers the concept of discounted cash flow analysis. When valuing an investment, you do not simply total all future cash flows. You discount them to reflect both time and risk. A dollar tomorrow is worth less than a dollar today, especially if there is uncertainty about whether that dollar will ever appear.

A similar mindset helps when assessing AI productivity. The headline productivity gain, for example, “Copilot can double developer output,” represents the gross potential. To reach a realistic number that you can plan around, you need to apply discounts that account for three things: the human effort required to reach an outcome, the gradual ramp-up of adoption and the risk that comes with AI’s imperfections.

Human effort: The human + machine reality

Generative AI acts as an accelerator, not an autopilot. People are still essential to frame the problem, guide the model and validate the output. In software engineering, for instance, tools like GitHub Copilot can produce working code instantly, yet much of that code still needs debugging, testing and revision.

In one client pilot, our team found that engineers spent roughly a quarter of their time reviewing or rewriting AI-generated code. The net productivity gain was meaningful but well below the theoretical doubling of output that vendors often cite. It was closer to a 40% improvement, which proved far more believable and sustainable. The key lesson was clear: AI amplifies talent but does not replace human judgment. Accounting for that in your projections makes your models more credible and your plans more realistic.

Ramp-up and adoption curve

Another important discount reflects the pace of adoption. Productivity gains from AI do not arrive all at once. As with any enterprise technology, adoption follows a curve shaped by learning, experimentation and scaling.

One of our Fortune 500 manufacturing clients modeled this curve while deploying Copilot for code development. In the first year, only about a quarter of developers were active users. Over time, they projected steady growth in adoption, with both costs and benefits expanding as the tool became part of daily workflows. By modeling a four-year adoption period, they could present a credible ROI trajectory that matched the organization’s ability to absorb change. The result was a measured, believable forecast rather than a sharp, unrealistic surge.

Even with a strong business case, productivity must be earned. Adoption takes time, training and reinforcement. When you include that reality in your estimates, the projections become both defensible and actionable.

Risk adjustment: Accounting for AI’s hallucinations

Every productivity model should also include a discount for risk. Even the best systems can produce errors and the costs of those mistakes, both operational and reputational, can be significant.

We have all seen examples in the news. Earlier this year, a global technology company withdrew a marketing campaign after its AI image generator created offensive results. The issue was not a lack of oversight; it was an underestimation of risk. The company spent weeks addressing the problem, coordinating communications and repairing trust. That period of recovery consumed time and resources that could have been spent on productive work.

When estimating productivity, CIOs need to plan for these inevitable setbacks. The time and effort required to validate outputs, correct errors and perform remediation should be built into the analysis. Just as investors demand higher returns for riskier assets, technology leaders should temper productivity expectations for higher-risk AI applications.

From concept to practice

This idea of discounted productivity becomes powerful when applied in real situations. Imagine a software engineer using Copilot. The theoretical potential might suggest a doubling of productivity, but after adjusting for human oversight, the gradual adoption curve and risk, the realistic gain might fall closer to 30% or 40%.

When visualized, the result looks like a waterfall chart. You begin with the total AI opportunity, then reduce it step by step to account for human effort, phased implementation and risk. What remains is the achievable productivity impact, the number you can confidently share with your CFO and CEO, knowing it reflects how your teams actually operate. And as your teams gain experience, you may even outperform that estimate.

The bottom line: Your AI mileage will vary

AI is transforming how we work, but just like the miles per gallon rating on a new car, your results will depend on your terrain, your driver and your discipline. By adopting a discounted productivity mindset, CIOs and technology leaders can close the gap between AI promise and practical performance, setting expectations that are credible, defensible and achievable.

Because with AI, just like with driving, your mileage will vary.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?