The demo went well. The model performed, the room nodded, the ROI slide got applause. Six months later, that same "proven" use case still hasn't shipped to a second business unit — and nobody in the room has a clean answer for why.

Nothing about the model changed. What changed is that it finally met the estate it has to run inside: ageing interfaces, duplicated data, workflows nobody documented, dependencies three teams assumed someone else owned. Delivery slows. Integration scope quietly grows. The business case finance signed off on starts absorbing costs no one assigned to it.

Here's the uncomfortable truth: if your ROI math prices the model, the cloud capacity and the talent, but leaves the inherited estate out of the equation, you haven't measured ROI. You've measured the best-case route through a system you never actually surveyed.

The Pilot Didn't Lie: It Just Didn't Tell You Everything

Pilots exist to answer one question: can this work? They're not built to answer the harder one — what does it take to run this everywhere it needs to run?

That's not a flaw. It's the point. A pilot strips out variables so you can test the idea cleanly. Trouble starts when those variables don't come back into the plan at scale.

A clean data sample hides the reconciliation work waiting in production. A single integration hides the interface chaos across every other system that still needs to connect. A protected workflow hides the exception paths frontline teams quietly handle every day.

So, the programme scales, and the real cost shows up — not as one bad surprise, but as a drip: a specialist for every release, a workaround for every new domain, a manual evidence trail for every control. None of it was in the original budget. All of it is now the delivery cost. The model performs exactly as advertised. The economics around it don't.

The Missing Line in the Business Case

IBM's Institute for Business Value surveyed 1,300 senior technology and AI decision-makers in late 2025. Organisations that fully accounted for technical debt in their AI business cases projected ROI 29% higher than those that didn't.

That's a self-reported projection, not a guaranteed return — worth holding with some scepticism. But it points to something real: the business cases that survive contact with the estate are the ones that priced the estate in from day one. Everyone else is forecasting against a system they never looked at.

Technical debt isn't background noise around the investment. It's the denominator that decides whether the projected return means anything.

Make the Debt Specific to the Decision

A lot of debt conversations try to produce one enterprise-wide "debt score." Reasonable instinct, wrong tool.

A portfolio leader approving the next AI proposal doesn't need an estate-wide score. They need to know which liabilities this specific capability will touch, what they cost to fix or contain, and when that work has to happen.

For one AI service, that might be a brittle source-system interface, inconsistent data definitions, an application that can't reliably expose events, or a release process still leaning on manual regression. The right question isn't "how much debt do we have?" It's "which debt changes this investment's cost, timing, risk or operating model?"

Get that distinction right, and you avoid two expensive mistakes: ignoring debt until rollout and treating every AI proposal as an excuse for wholesale replacement.

Modernise the Constraint Not the Whole Estate

The instinct to "fix everything first" is understandable — and almost always wrong. The disciplined move is triage: rank debt by severity, risk and urgency, so engineering effort lands on what actually blocks delivery and value, not what's easiest to see on a diagram.

Good triage produces a remediation path tied directly to the business case, with assumptions finance, product and engineering can review together. Execution follows the need: a system upgrade where the stack blocks scale, a security fix where exposure threatens viability, continuous automated upgrades where debt will simply rebuild itself if left alone.

The goal was never a debt-free estate — that's not realistic for any live production system. The goal is an estate whose liabilities are visible, funded on purpose, and managed at the same pace as the AI portfolio depending on it.

A Four-Field Discipline for Every AI Proposal

Make this concrete. Take the next AI proposal heading to your portfolio board. For every platform it depends on, add four fields:

• The debt item — named specifically.
• Evidence of its effect — current cost in delay, rework or risk.
• The estimated remediation or containment cost.
• The owner accountable for resolving it.

Then recalculate the return and the delivery date.

Can't populate the fields? That's your answer. Pause the ROI claim, not the use case.

What This Means for the Portfolio

Strip away the technical detail and this is a trust problem. Portfolio leaders already discount projections for market risk, adoption risk, execution risk. Technical debt deserves the same treatment: a named, costed, owned variable — not an asterisk discovered mid-rollout.

Get this discipline right, and the payoff is quiet but real: fewer AI programmes that look stalled when they're actually just underfunded for integration work nobody priced. Fewer post-mortems that end with "the model worked, the estate didn't." And a portfolio where every proposal gets compared on the same honest basis.

The Innominds Perspective

This is an engineering problem at its core, which is why it cuts across disciplines rather than living inside one. Pricing debt into an AI business case means being able to actually assess the estate: the cloud and platform architecture it runs on, the quality and consistency of the data flowing through it, the automation and release maturity that determines whether rollout is repeatable or a one-off scramble, and the governance that keeps all of it auditable.

That's the thread connecting Product Engineering, Cloud & Platform Engineering, Data & AI, Quality Engineering, Automation and DevOps, and Digital Engineering — not as separate service lines, but as the lenses needed to answer one question: what, specifically, stands between this AI investment and the return it's being sold on? Technology Modernization, done as triage rather than wholesale replacement, is how that question gets answered in a way finance, product and engineering can all stand behind.