Technical debt has long been an issue that IT departments have struggled with. But with the rapid rise of AI, it is getting even more attention because AI related technical debt can create bigger and more complex problems for businesses. And with many organizations feeling pressure to get AI implementations out the door quickly, they are accepting technical debt as the price for that speed.
Drawing on information shared in a recent video from IBM Distinguished Engineer Jeff Crume, this article explores why more companies are knowingly taking on significant technical debt in AI, the risks that come with doing this and how they can be managed.
What is technical debt?
Technical debt arises when an organization takes shortcuts or makes compromises in order to launch a technology solution into production faster. They are trading speed now for future costs, because they will eventually need to go back and rework parts of the system that were either missed or completed in a 'quick and dirty' way.
By not doing all the work now, they're creating technical debt that will need to be paid later. In Jeff Crume's words, the organization is accepting that "we're going to deploy it now with imperfect results and then just fix it later in the field".
As well as paying off the original debt, these organizations will also be accruing ongoing costs or "interest" on that technical debt, which can manifest in a variety of ways. For example, because they didn't do everything to the letter initially, their system may experience more downtime or increased latency, need more frequent maintenance, and be more vulnerable to security threats.
Moreover, as with financial debt, technical debt has a way of "compounding" until it has been paid off: because "each shortcut taken today makes future work slower, riskier and more expensive, creating pressure for even more shortcuts, leading to more messiness, more delays", creating a "vicious circle". And of course, a system that has been rushed through without being properly architected, will be more difficult to upgrade or extend than one with an intelligent design that builds this kind of flexibility in from the start.
Why AI technical debt is a bigger problem
Technical debt is becoming an increasingly common issue in AI implementations because there is so much pressure to get AI into production faster. Whether they are building chatbots, agentic systems, or other AI initiatives, companies are trying to gain a competitive edge by launching ahead of their rivals.
I've already mentioned the various problems created by technical debt, but for AI implementations, things can be even worse.
AI is probabilistic rather than deterministic, which can make it very unpredictable; the same inputs may not always produce the same outputs, making AI systems much harder to test, govern and manage. So, if shortcuts or compromises have been taken during implementation, it is far more difficult to predict what problems this might create, where they will appear and how significant their impact might be once the system is operating at scale.
The potential negative consequences of technical debt can be even more serious in agentic AI deployments. AI agents are designed to make autonomous decisions in real-time that can drive multi-step enterprise workflows. So, any oversights or missing details in how they are built can create problems that spread quickly across these workflows before anyone on the team realizes.
Types of AI technical debt
There are four types of technical debt that can be specific to AI implementations.
1. Data AI technical debt
Data technical debt results from deploying AI solutions without ensuring that the AI model is trained on high-quality data from diverse, trustworthy sources. Poor quality data is likely to produce inaccurate or biased AI responses.
Even if the data quality was fine during model training, it is important to check that it has not degraded over time because of data drift (when real world changes mean that the original data is no longer representative or accurate). Similarly, it is important to check that data has had effective security in place to protect it from data poisoning by malicious actors.
2. Organizational AI technical debt
Organizational AI technical debt refers to companies failing to adhere to all necessary best-practice processes when deploying an AI tool or application. Perhaps they did not create a governance policy, conduct a comprehensive evaluation of the application before going into production, or have a plan to enable it to scale as activity levels increase.
3. Model AI technical debt
Model technical debt occurs when an organization fails to do all the things that are required to ensure the AI model is able to perform as required. Did they assess it to ensure it delivers accurate responses, in good time, for the use case it is targeting (including minimizing hallucinations)? Did they test the model against different types of security threats? Are plans in place for how the model will be updated to new versions when necessary, as well as developing rollback capabilities to go back to a previous version if errors occur?
4. Prompt AI technical debt
Prompt technical debt, as the name suggests, relates to all the prompts that are in place to ensure the AI system operates as required, from system prompts to guardrails and safety prompts to prompt instructions governing how the system uses RAG (Retrieval-Augmented Generation) and external software tools. Technical debt occurs in this area when the AI goes into production without ensuring all prompts are fully documented and validated to ensure they work effectively.
Managing AI technical debt
In an ideal world, an enterprise will want to avoid technical debt. This requires them to go through the necessary rigour from the outset. They need to work through the process of developing a detailed list of requirements, spend sufficient time in the planning, architecture and build phases before testing and full deployment, and continuing to evaluate the system post-launch.
Technical debt is not necessarily always a bad thing. It is often a judgement call. With regard to deploying AI, enterprises are trying to balance the value of getting an AI initiative off the ground quickly against the risks and long-term costs of not following best-practice steps to the letter from the start and having to handle the consequences later.
If the organization decides to do this, it needs to do so with its eyes wide open; be clear about any shortcuts it is taking and why, document them and have plans in place (and resources set aside) to go back and address them later.
Jeff Crume distinguishes between strategic technical debt and reckless technical debt.
Strategic technical debt is taken with full knowledge of the trade-offs it entails. The company recognizes that this is not a permanent solution and will have plans in place to fix any issues that have been glossed over. Reckless technical debt involves moving quickly to get something into production as fast as possible, without acknowledging and recording all the compromises being made, their potential impact, and what will need to be put right afterwards.
What is the point of an organization rushing to deploy AI ahead of its rivals if it ends up being plagued by technical problems, rising costs and unpredictable risks?