As AI ambitions collide with ageing architecture, technical debt is becoming a business risk that boards can no longer leave to IT to quietly manage.
For years, technical debt was treated as an IT problem. Ageing systems, brittle integrations and hard-to-change applications created cost and complexity, but as long as the business kept operating, those problems stayed largely contained within the technology function.
That containment is breaking down. Businesses are changing faster, integrating more systems, launching digital products and responding to new regulatory demands. In that environment, technical debt shows up as slower delivery, higher transformation costs and reduced flexibility. Research from Deloitte’s Global Technology Leadership Study estimates that technical debt now absorbs somewhere between 21% and 40% of total IT spend, meaning for every rand or dollar an organisation puts into IT, a significant share goes toward servicing debt rather than delivering new value. A system that’s difficult to change becomes a business problem the moment it delays a product launch or blocks a process redesign.
According to Sasha Slankamenac, Architect in the Office of the CTO and Practice Lead: AI at Dariel, the shift is really about who now feels the consequences. “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.”
Cloud migration already showed us this
Cloud migration exposed the problem clearly. “Migrate first, modernise later” often changed where applications ran without changing how they were built. Organisations gained newer infrastructure while carrying much of the same architectural constraint with them.
“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 exposing the problem again, faster
If cloud migration was a slow-motion lesson, AI is a fast one. Ambitious automation and AI programmes still depend on accessible data, reliable integration and systems that can be changed safely, the exact things technical debt erodes.
“AI doesn’t fail quietly the way legacy systems do,” Slankamenac explains. “It fails visibly and fast, because it immediately exposes whether your data is trustworthy, whether your integrations are stable, and whether your architecture can actually support the thing you’re asking it to do. Technical debt used to be a slow leak. Against an AI roadmap, it becomes obvious in the first sprint.”
He argues that this is why AI projects so often stall well before the 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.”
From episodic resets to continuous discipline
There’s also a funding model behind the problem. The traditional pattern was to let systems age and debt accumulate until the cost or risk became hard to ignore, then fund a large replacement or rewrite. In effect, businesses saved up for periodic resets while accepting growing inflexibility between them.
That model is increasingly at odds with the pace of business change. A more sustainable approach is to continuously re-engineer the technology estate as part of normal operations, simplifying architecture, replacing brittle components, and removing constraints before they become programme-sized problems.
“The mindset shift is the same one we push on engineering culture generally,” Slankamenac says. “Stop treating architecture as something you fix in five-year cycles and start treating it as something you tend to every week. That’s not a bigger budget question, necessarily, it’s a different operating discipline.”
This also changes how technology expenditure should be thought about. Rather than treating architectural improvement mainly as an occasional capital event, organisations need a recurring capacity to keep architecture relevant to current business needs, maintaining adaptability as an ongoing operating discipline rather than something deferred until the next major rewrite.
Why it belongs in the boardroom
Financial debt limits what an organisation can afford to do next. Technical debt increasingly limits what it is capable of doing next.
“Boards are already comfortable asking about financial risk exposure,” Slankamenac says. “Technical debt deserves the same seat at that table, because at this point, it’s not a different category of risk, it’s the same conversation, just measured in architecture instead of currency.”
