Companies are spending heavily on AI while discovering that some of the biggest obstacles have very little to do with the AI itself. Old applications, unreliable integrations and technology estates built up over decades can determine whether a project moves from a demonstration into something useful inside the business.
The cost of carrying those systems is already considerable. Deloitte estimates that technical debt accounts for between 21% and 40% of an organisation’s IT spending. Using the midpoint of that range, close to a third of technology expenditure can effectively be tied up in decisions made previously rather than creating something new. Maintenance costs only capture part of the problem because a system that is difficult to change also affects how quickly a company can change with it.
Sasha Slankamenac, Architect in the Office of the CTO and Practice Lead: AI at South African software engineering company Dariel, says the consequences have become much more visible outside technology teams. “Ten years ago, technical debt was something an engineering team lived with and managed quietly,” he says. “Today, the business feels it directly, because the thing that’s now constrained by that debt is the business’s ability to move.”
AI is giving companies plenty of opportunities to discover exactly where those constraints sit.
AI needs the systems around it to work
An AI pilot can be relatively self-contained. Putting the same system into production means connecting it to company data and existing applications while meeting whatever security, governance and operational requirements already apply to the business. The model can be perfectly capable and the project can still run into systems that were never designed to provide information in the way AI applications now require.
McKinsey research published in June describes data readiness as one of the central constraints companies encounter as AI pilots are scaled. Enterprise data is spread across documents, applications and workflows, while useful AI systems need reliable access to information that can be treated as trustworthy.
Infrastructure can create similar problems. IBM research, conducted with Oxford Economics among 400 business leaders, found that 77% believed they needed to adopt generative AI quickly to remain competitive, yet only 25% strongly agreed that their IT infrastructure could support scaling AI across the organisation.
Slankamenac sees the same problem appearing before the AI model itself becomes the limiting factor. “Everyone wants to talk about the model. The model is rarely the problem. The problem is almost always the twenty-year-old integration layer nobody wants to touch.”
That twenty-year-old integration layer was easier for the rest of the company to ignore when its consequences were largely contained within IT. It becomes much more difficult when a new product takes longer to launch or an automation project can’t reliably access the information it needs. Technical debt starts to describe more than the condition of a company’s software because it can also reveal something about the organisation’s capacity to change.
Cloud migration moved some of the problem
Enterprise technology has already gone through one enormous modernisation cycle as companies moved applications and infrastructure into the cloud, often with flexibility and lower infrastructure overhead among the promised benefits. Moving an old application somewhere else, however, doesn’t automatically change the way it was designed.
The “migrate first, modernise later” approach allowed companies to shift workloads without rebuilding everything at the same time. In some cases, the modernisation part could remain unfinished long after the migration had been completed. “Lift-and-shift doesn’t remove technical debt, it just relocates it to a more expensive postcode,” Slankamenac says. “You can move a poorly designed system into the cloud and it’s still a poorly designed system and it’s just now billed by the hour.”
AI is prompting another look at some of those infrastructure decisions. South African organisations appear particularly willing to reconsider where AI workloads should run, with research commissioned by Cloudera finding that 83% of the South African organisations surveyed had moved at least some AI workloads from public cloud into private cloud or on-premises environments, considerably above the 66% global figure.
Cost and data control are part of that shift, but moving an AI workload around only offers so much flexibility if the applications and data it relies on remain difficult to move or connect. IBM’s 2026 Tech Leader Study, also conducted with Oxford Economics, found that 88% of organisations surveyed were attempting to move workloads to another cloud provider, yet only 25% of those workloads were considered easily portable. Cloud adoption, in other words, doesn’t necessarily leave a business with flexible architecture.
Technical debt is difficult to put on a dashboard
Asking boards to pay greater attention to technical debt creates a practical problem because it doesn’t arrive with a single number attached. Deloitte acknowledges this in its own analysis, noting that technical debt is specific to an organisation and lacks the kind of standard benchmark businesses use to assess conventional financial measures.
A company can still see its effects. Engineering teams spend time keeping old systems functioning instead of building new capabilities. Changes take longer because one application depends on several others, manual work persists because systems don’t exchange information cleanly, and apparently small projects become more expensive because they require changes across technology that has accumulated over years.
Those consequences can be measured even if technical debt itself resists being reduced to one neat financial metric. The business case also changes when the cost of old architecture is compared with the value of being able to respond more quickly. A replacement programme that looks expensive in isolation may look rather different if the existing system is delaying projects the business has already decided it needs.
AI makes this particularly visible because the investment often comes with expectations of rapid productivity gains or new revenue. An organisation can buy access to the same models as its competitors and still be considerably less capable of putting them to work if its data, applications and integrations make deploying those models difficult.
Five-year resets make less sense when technology keeps moving
Many organisations have historically allowed systems to age until the cost of maintaining them or the risk of keeping them becomes large enough to justify a major replacement programme. Technical debt builds up between those interventions and is dealt with in an expensive reset, but Slankamenac argues for a more continuous approach.
“Stop treating architecture as something you fix in five-year cycles and start treating it as something you tend to every week,” he says. “That’s not a bigger budget question, necessarily, it’s a different operating discipline.”
Technical debt itself isn’t necessarily evidence of poor management. Software gets built under deadlines and budgets, companies acquire other companies with different systems, requirements change, and an architecture designed for one version of a business can eventually become a poor fit for what the organisation has become. Eliminating all technical debt would therefore be neither realistic nor particularly sensible. The more useful question is which compromises remain acceptable and which are beginning to restrict the business.
That makes the boardroom argument easier to justify. Directors don’t need to discuss individual APIs or decide which applications should be rewritten, but they do need to understand when the company’s technology estate is limiting the strategies available to it and whether investment intended to create new capabilities is instead being absorbed by old constraints.
Companies can keep experimenting with newer models and increasingly capable tools, but the gap between what AI can theoretically do and what a particular organisation can actually deploy depends heavily on everything around the model. Some businesses are discovering that their AI roadmap began years before ChatGPT appeared, buried inside architecture decisions nobody expected the board to care about.