We have a habit, in enterprise technology, of giving expensive problems flattering names. “Center of Excellence.” “Best of Breed.” “Digital Transformation.” The label arrives after someone has already decided the thing is good, and it does the work that evidence is supposed to do. You can carry a problem for twenty years if you keep giving it a nice enough name.
Technical debt and data debt are the two problems we have named the longest and measured the least — until recently. So let me do the unflattering thing and attach numbers to them, because the numbers change what the AI era actually is.
The number nobody puts on the boardroom slide
Technical debt is no longer an abstraction. The Consortium for Information and Software Quality puts the cost of poor software quality in the United States at roughly $2.41 trillion a year, with about $1.52 trillion required just to remediate the existing principal. Gartner and Deloitte estimate that technical debt now represents twenty to forty percent of the entire value of enterprise technology estates. Not twenty to forty percent of the IT budget — of the estate itself. A fifth to two-fifths of what you have already built is, in effect, borrowed against.
Data debt is larger and quieter. Poor data quality has been estimated to cost the US economy on the order of $3 trillion a year, with the average enterprise losing around $12.9 million annually to it. Most organizations rate their own data quality as average or worse. By one estimate, only three percent of enterprise data meets basic quality standards.
Put the two together and you are looking at a multi-trillion-dollar annual drag on the US economy alone. These figures come from different methodologies and they overlap, so treat them as order-of-magnitude rather than a clean sum. But the order of magnitude is the point. This is not a rounding error. It is one of the largest unpriced liabilities in business, and it has been hiding behind words like “legacy” and “modernization roadmap.”
Technical debt and data debt are not separate phenomena. They are the accumulated cost of deploying capability faster than organizations could absorb it.
How it got this big: every era built on the last one’s unpaid bill
Here is the part the era-by-era story usually misses. Technical and data debt did not accumulate as a series of separate problems. It compounded, because each technology wave was deployed on top of the unremediated debt of the one before it.
ERP arrived and was layered onto whatever existed. E-procurement was layered onto ERP. Digital transformation was layered onto that. Then cloud. Now AI. At each step, the promise was that the new layer would resolve the limitations of the old one. At each step, the old debt was not retired — it was carried forward, papered over, and built upon. The foundation never got stronger. It got deeper and more tangled, with each new floor adding load to a structure no one had reinforced.
That is why the number is in the trillions and not the billions. It is not the cost of one era’s mistakes. It is the cost of four decades of building on foundations no one stopped to repair, each generation handing the bill to the next under a new name.
[GRAPHIC: “Four Decades of Building on an Unpaid Bill” — the compounding foundation vs. the AI-era fork]
Why AI is different from every era before it
Every prior wave shared one structural limit: it could only add. ERP, e-procurement, digital transformation, cloud — each was a new layer. None of them could reach back and retire the debt beneath them. The best they could do was sit on top of it and hope it held.
AI is the first technology in this entire lineage that can do the opposite. It can read and refactor legacy code at a scale no team could staff. It can find, clean, structure, and reconcile data across systems that have not spoken to each other in decades. Concretely: it can deprecate an entire legacy integration layer by rewriting what depended on it, rather than wrapping one more interface around it and adding to the pile. For the first time, the new layer has the capacity to go down into the foundation and pay off the principal — to be the off-ramp from the debt, rather than another floor added to it.
But here is where this is most often misread, and the misreading is fatal. None of this is a claim that the debt is a technical problem with a technical fix — that you simply point a smarter tool at the stack and engineer your way out. And it is not a claim that the technology created the debt. It didn’t. The debt was never a byproduct of the technology. It is what accumulates when technology is aligned to an equation-based model of the organization — a clean diagram of how the work is supposed to flow — instead of to the agent-based reality of how the organization actually operates: the incentives, the decision rights, the conditions on the ground, and the workarounds people invent when the diagram doesn’t match their world. The code and the data are not the debt. They are the residue of that misalignment. Each technology era did not cause the gap between the model and the reality — it inherited that gap and automated it, faster and at greater scale, under a new name.
It does not matter what kind of car you drive, or what condition it is in, if the driver is poor or the map is incomplete. A better-engineered foundation — cleaner architecture, refactored services, pristine data — is a better car. It does nothing about the driver or the map. Clean the data without surfacing the condition that corrupted it and you get immaculate data describing a broken operating reality — and then AI automates the broken reality faster and more confidently than before. That is not retiring debt. That is paving the road to the ditch.
I know the sequence matters because I watched it work in reverse. In 1998, the engagement that became the foundation of this entire method did not begin with technology. The delivery problem — 51 percent against a 90 percent requirement — looked like a procurement-systems problem, and the brief was to automate. Instead, the alignment came first: surfacing a hidden incentive condition that no diagram showed, realigning it, and only then, in the fourth and fifth months, introducing the technology onto a foundation that was already correct. Delivery moved to 97.3 percent and held for seven years. The technology did not cause the turnaround. It was introduced after the alignment and made the now-correct model scale. That is the whole proof in one case: technology placed last, onto an aligned operating model, produces the outcome. Technology placed first, onto an unaligned one, produces the debt. The variable was never the technology.
AI can do the refactoring and the reconciliation at a scale no team could staff. That is real, and it is new — and almost no one is framing the AI moment this way, because the conversation is fixed on what AI can produce rather than what it can retire. But it retires debt only when it is pointed at a foundation whose operating conditions have been diagnosed first. Otherwise it is just a faster car on the same wrong map.
The fork
Deploy AI onto the existing foundation without understanding it, and it does what every prior era did, only at machine speed and machine cost. It buries the old debt under a new layer, and it creates a new and more aggressive form of it — what the field is now calling AI debt: rushed models trained on dirty data, agents wired into systems no one mapped, decisions generated on conditions no one validated. The persistent finding that seventy to eighty-five percent of AI initiatives fail to deliver their intended return (enterprise AI ROI analyses, 2025–2026) is not a model-quality problem. IDC’s 2026 CIO predictions hold that organizations delaying data-debt remediation will face fifty percent higher AI failure rates. Gartner expects most AI initiatives lacking sound data foundations to be discontinued. The foundation decides the outcome. It always has.
Deploy AI onto a foundation you have diagnosed first — where you have surfaced the operating conditions, the data realities, the structural dependencies before the technology touches them — and the same tool becomes the off-ramp. It retires debt instead of compounding it. It produces outcomes that hold instead of write-offs that don’t.
Same technology. Same models. Same agents. Opposite results. The fork is not the technology — it never has been. The difference is whether the underlying conditions were surfaced before deployment.
That conditions diagnosis is the work I have called Phase 0: understanding the real-world operating conditions before the technology is introduced, so that what gets deployed lands on ground that can carry it. It is not a readiness checklist or a governance layer applied after the fact. It is the diagnosis that determines, before a dollar of AI spend is committed, whether that spend will retire debt or manufacture more of it. Phase 0 is not a readiness methodology. It is the mechanism for deciding whether AI becomes the first off-ramp from forty years of accumulated debt — or the most expensive layer ever added on top.
The off-ramp will not stay open
Here is what makes this urgent rather than merely interesting. The window in which AI is mostly being pointed at new capability rather than foundational repair is the window in which the debt is quietly getting worse — because AI deployed on an unremediated foundation does not hold steady. It accelerates the accumulation. Every confident, ungrounded output is a new entry in a ledger no one is reading.
The organizations that will come out of this era ahead are not the ones that adopted AI fastest. They are the ones that pointed it at the foundation first — that used the first debt off-ramp in forty years to actually pay down the principal, instead of using it to bury the bill one more time under a more impressive name.
If you are a CIO, a CPO, or a CFO looking at an AI roadmap right now, there is a simple test that tells you which path you are on. Before you fund the next initiative, ask your team to show you — in writing — the specific operating conditions, the data realities, and the structural dependencies that will decide whether it works. If they can show you that model, you have an AI strategy. If they cannot, you are not looking at a strategy. You are looking at another floor going up on an unpaid bill.
Technical debt and data debt are not buzzwords. They are a number, and the number is enormous. The AI era is the first real chance to bring that number down. Whether it does, or whether it becomes the most expensive layer yet added to a crumbling foundation, will not be decided by the technology.
For forty years, organizations have treated technical debt and data debt as technology problems. That assumption is itself the oldest debt of all. The debt never began in the code or the data. It began in the distance between how an organization believes its work happens and how the work actually happens — and every technology era since has been an expensive attempt to automate across that distance without closing it. AI can repair the visible residue at a scale nothing before it could. Whether it does will depend on whether we finally treat the distance itself as the thing to fix.
It will be decided by whether anyone asked what was underneath it first.
The figures cited are drawn from published research by the Consortium for Information and Software Quality, Accenture, Gartner, Deloitte, IBM, IDC, and McKinsey, 2016–2026. They use varied methodologies and are presented as order-of-magnitude estimates. The per-era compounding model and the with/without-diagnosis comparison are illustrative — built to show the mechanism, not to assert a precise historical ledger. Procurement Insights: archive since 2007, practice and proof lineage to 1998. 3,300+ independent documents, zero vendor sponsorships.
-30-
Related
Technology Debt Has a Number. The AI Era Is the First Chance to Pay It Down — or Bury It Forever.
Posted on June 1, 2026
0
We have a habit, in enterprise technology, of giving expensive problems flattering names. “Center of Excellence.” “Best of Breed.” “Digital Transformation.” The label arrives after someone has already decided the thing is good, and it does the work that evidence is supposed to do. You can carry a problem for twenty years if you keep giving it a nice enough name.
Technical debt and data debt are the two problems we have named the longest and measured the least — until recently. So let me do the unflattering thing and attach numbers to them, because the numbers change what the AI era actually is.
The number nobody puts on the boardroom slide
Technical debt is no longer an abstraction. The Consortium for Information and Software Quality puts the cost of poor software quality in the United States at roughly $2.41 trillion a year, with about $1.52 trillion required just to remediate the existing principal. Gartner and Deloitte estimate that technical debt now represents twenty to forty percent of the entire value of enterprise technology estates. Not twenty to forty percent of the IT budget — of the estate itself. A fifth to two-fifths of what you have already built is, in effect, borrowed against.
Data debt is larger and quieter. Poor data quality has been estimated to cost the US economy on the order of $3 trillion a year, with the average enterprise losing around $12.9 million annually to it. Most organizations rate their own data quality as average or worse. By one estimate, only three percent of enterprise data meets basic quality standards.
Put the two together and you are looking at a multi-trillion-dollar annual drag on the US economy alone. These figures come from different methodologies and they overlap, so treat them as order-of-magnitude rather than a clean sum. But the order of magnitude is the point. This is not a rounding error. It is one of the largest unpriced liabilities in business, and it has been hiding behind words like “legacy” and “modernization roadmap.”
Technical debt and data debt are not separate phenomena. They are the accumulated cost of deploying capability faster than organizations could absorb it.
How it got this big: every era built on the last one’s unpaid bill
Here is the part the era-by-era story usually misses. Technical and data debt did not accumulate as a series of separate problems. It compounded, because each technology wave was deployed on top of the unremediated debt of the one before it.
ERP arrived and was layered onto whatever existed. E-procurement was layered onto ERP. Digital transformation was layered onto that. Then cloud. Now AI. At each step, the promise was that the new layer would resolve the limitations of the old one. At each step, the old debt was not retired — it was carried forward, papered over, and built upon. The foundation never got stronger. It got deeper and more tangled, with each new floor adding load to a structure no one had reinforced.
That is why the number is in the trillions and not the billions. It is not the cost of one era’s mistakes. It is the cost of four decades of building on foundations no one stopped to repair, each generation handing the bill to the next under a new name.
[GRAPHIC: “Four Decades of Building on an Unpaid Bill” — the compounding foundation vs. the AI-era fork]
Why AI is different from every era before it
Every prior wave shared one structural limit: it could only add. ERP, e-procurement, digital transformation, cloud — each was a new layer. None of them could reach back and retire the debt beneath them. The best they could do was sit on top of it and hope it held.
AI is the first technology in this entire lineage that can do the opposite. It can read and refactor legacy code at a scale no team could staff. It can find, clean, structure, and reconcile data across systems that have not spoken to each other in decades. Concretely: it can deprecate an entire legacy integration layer by rewriting what depended on it, rather than wrapping one more interface around it and adding to the pile. For the first time, the new layer has the capacity to go down into the foundation and pay off the principal — to be the off-ramp from the debt, rather than another floor added to it.
But here is where this is most often misread, and the misreading is fatal. None of this is a claim that the debt is a technical problem with a technical fix — that you simply point a smarter tool at the stack and engineer your way out. And it is not a claim that the technology created the debt. It didn’t. The debt was never a byproduct of the technology. It is what accumulates when technology is aligned to an equation-based model of the organization — a clean diagram of how the work is supposed to flow — instead of to the agent-based reality of how the organization actually operates: the incentives, the decision rights, the conditions on the ground, and the workarounds people invent when the diagram doesn’t match their world. The code and the data are not the debt. They are the residue of that misalignment. Each technology era did not cause the gap between the model and the reality — it inherited that gap and automated it, faster and at greater scale, under a new name.
It does not matter what kind of car you drive, or what condition it is in, if the driver is poor or the map is incomplete. A better-engineered foundation — cleaner architecture, refactored services, pristine data — is a better car. It does nothing about the driver or the map. Clean the data without surfacing the condition that corrupted it and you get immaculate data describing a broken operating reality — and then AI automates the broken reality faster and more confidently than before. That is not retiring debt. That is paving the road to the ditch.
I know the sequence matters because I watched it work in reverse. In 1998, the engagement that became the foundation of this entire method did not begin with technology. The delivery problem — 51 percent against a 90 percent requirement — looked like a procurement-systems problem, and the brief was to automate. Instead, the alignment came first: surfacing a hidden incentive condition that no diagram showed, realigning it, and only then, in the fourth and fifth months, introducing the technology onto a foundation that was already correct. Delivery moved to 97.3 percent and held for seven years. The technology did not cause the turnaround. It was introduced after the alignment and made the now-correct model scale. That is the whole proof in one case: technology placed last, onto an aligned operating model, produces the outcome. Technology placed first, onto an unaligned one, produces the debt. The variable was never the technology.
AI can do the refactoring and the reconciliation at a scale no team could staff. That is real, and it is new — and almost no one is framing the AI moment this way, because the conversation is fixed on what AI can produce rather than what it can retire. But it retires debt only when it is pointed at a foundation whose operating conditions have been diagnosed first. Otherwise it is just a faster car on the same wrong map.
The fork
Deploy AI onto the existing foundation without understanding it, and it does what every prior era did, only at machine speed and machine cost. It buries the old debt under a new layer, and it creates a new and more aggressive form of it — what the field is now calling AI debt: rushed models trained on dirty data, agents wired into systems no one mapped, decisions generated on conditions no one validated. The persistent finding that seventy to eighty-five percent of AI initiatives fail to deliver their intended return (enterprise AI ROI analyses, 2025–2026) is not a model-quality problem. IDC’s 2026 CIO predictions hold that organizations delaying data-debt remediation will face fifty percent higher AI failure rates. Gartner expects most AI initiatives lacking sound data foundations to be discontinued. The foundation decides the outcome. It always has.
Deploy AI onto a foundation you have diagnosed first — where you have surfaced the operating conditions, the data realities, the structural dependencies before the technology touches them — and the same tool becomes the off-ramp. It retires debt instead of compounding it. It produces outcomes that hold instead of write-offs that don’t.
Same technology. Same models. Same agents. Opposite results. The fork is not the technology — it never has been. The difference is whether the underlying conditions were surfaced before deployment.
That conditions diagnosis is the work I have called Phase 0: understanding the real-world operating conditions before the technology is introduced, so that what gets deployed lands on ground that can carry it. It is not a readiness checklist or a governance layer applied after the fact. It is the diagnosis that determines, before a dollar of AI spend is committed, whether that spend will retire debt or manufacture more of it. Phase 0 is not a readiness methodology. It is the mechanism for deciding whether AI becomes the first off-ramp from forty years of accumulated debt — or the most expensive layer ever added on top.
The off-ramp will not stay open
Here is what makes this urgent rather than merely interesting. The window in which AI is mostly being pointed at new capability rather than foundational repair is the window in which the debt is quietly getting worse — because AI deployed on an unremediated foundation does not hold steady. It accelerates the accumulation. Every confident, ungrounded output is a new entry in a ledger no one is reading.
The organizations that will come out of this era ahead are not the ones that adopted AI fastest. They are the ones that pointed it at the foundation first — that used the first debt off-ramp in forty years to actually pay down the principal, instead of using it to bury the bill one more time under a more impressive name.
If you are a CIO, a CPO, or a CFO looking at an AI roadmap right now, there is a simple test that tells you which path you are on. Before you fund the next initiative, ask your team to show you — in writing — the specific operating conditions, the data realities, and the structural dependencies that will decide whether it works. If they can show you that model, you have an AI strategy. If they cannot, you are not looking at a strategy. You are looking at another floor going up on an unpaid bill.
Technical debt and data debt are not buzzwords. They are a number, and the number is enormous. The AI era is the first real chance to bring that number down. Whether it does, or whether it becomes the most expensive layer yet added to a crumbling foundation, will not be decided by the technology.
For forty years, organizations have treated technical debt and data debt as technology problems. That assumption is itself the oldest debt of all. The debt never began in the code or the data. It began in the distance between how an organization believes its work happens and how the work actually happens — and every technology era since has been an expensive attempt to automate across that distance without closing it. AI can repair the visible residue at a scale nothing before it could. Whether it does will depend on whether we finally treat the distance itself as the thing to fix.
It will be decided by whether anyone asked what was underneath it first.
The figures cited are drawn from published research by the Consortium for Information and Software Quality, Accenture, Gartner, Deloitte, IBM, IDC, and McKinsey, 2016–2026. They use varied methodologies and are presented as order-of-magnitude estimates. The per-era compounding model and the with/without-diagnosis comparison are illustrative — built to show the mechanism, not to assert a precise historical ledger. Procurement Insights: archive since 2007, practice and proof lineage to 1998. 3,300+ independent documents, zero vendor sponsorships.
-30-
Share this:
Like this:
Related