I want to talk about a number that does not appear in any AI vendor deck, any ROI calculator, or any budget template I have ever seen. It is the number that determines whether an AI deployment actually delivers sustained value or quietly becomes an expensive piece of infrastructure that everyone has quietly stopped trusting.
The number is the ongoing cost of keeping the AI useful.
Not the license. Not the integration. The ongoing, continuous, unglamorous work of maintaining an AI system in a state where it can be trusted to give accurate, current, context-appropriate answers to the people who depend on it.
Most organizations do not budget for this at all. They budget for deployment and they budget for licenses. The maintenance work happens either because someone cares enough to do it on top of their actual job description, or it does not happen and the system degrades silently until users stop trusting it and the investment becomes a sunk cost.
Let me break down what this maintenance actually involves because I have been tracking it across several deployments and the components are consistent even when the specific numbers vary.
Document lifecycle management. An enterprise AI knowledge base is only as current as its most recently updated source documents. But source documents go stale continuously. Policies change, products evolve, organizational structures shift, pricing updates, contacts leave. Every one of these changes creates a gap between what the AI believes is true and what is actually true. Closing these gaps requires someone to monitor the source systems, identify when updates affect indexed content, remove or supersede outdated documents, and confirm that the updated content has been properly indexed and is retrievable.
For a 200-person company with an active internal knowledge base, I typically see this running at four to eight hours per week across whoever is responsible for it. It is not technically complex work. It requires attention, organizational knowledge, and the discipline to actually do it consistently rather than letting it accumulate. The cost at $80 per hour loaded compensation runs $16,000 to $32,000 annually in labor. It does not appear as an AI cost anywhere because it gets absorbed into someone's other responsibilities.
Retrieval quality monitoring. Retrieval quality in a RAG system is not static. It changes as the document corpus evolves, as the distribution of user queries shifts, and as the embedding model's relationship to the domain vocabulary changes over time. A retrieval configuration that performed well at deployment may be underperforming significantly twelve months later because the content it was optimized for has changed.
Catching this degradation before users notice it requires active monitoring. Running a set of evaluation queries on a scheduled basis, comparing results against a baseline, and investigating when metrics drop below threshold. Identifying specific document types or query categories where retrieval has degraded. Making configuration adjustments and verifying they had the intended effect.
For a system of moderate complexity, this monitoring takes two to four hours per week from someone who understands both the domain and the technical retrieval pipeline. The challenge is that most organizations do not have a person who is clearly responsible for this. The engineers who built the retrieval system moved on to other projects. The business users who rely on it do not have the technical background to investigate it. The degradation happens in the gap between those two groups.
Prompt maintenance. Enterprise AI systems built around specific prompts will find that those prompts need updating as the business changes. A system prompt written when the company had 50 employees and operated in two markets will not accurately represent the business context eighteen months later when the company has 200 employees, operates in six markets, and has restructured its product lines twice. The AI's outputs will reflect the stale organizational model it was given at configuration time.
Keeping prompts current requires someone who understands both how the business has changed and how those changes should be reflected in the system's instructional context. This is editorial work as much as technical work. It requires judgment about which organizational changes are substantive enough to affect AI behavior and how to express those changes in prompt language that produces the right output.
User feedback processing. Users encounter AI system errors constantly. Most of them do not report them. The ones who do report them often do so in informal channels, in passing comments, in slack messages to colleagues rather than through any formal feedback mechanism. Capturing this signal, triaging it to understand whether it represents a data quality issue, a retrieval configuration issue, or a model behavior issue, and routing it to the appropriate fix requires deliberate process design.
Without this process, the same errors recur, users accumulate distrust without the organization accumulating knowledge about why, and the gap between what users expect and what the system delivers widens continuously.
The budget conversation this creates.
When I walk through this analysis with a COO or CFO who is evaluating an AI deployment or trying to understand why a current deployment is underperforming, the reaction is usually some version of: "nobody told us this was part of it."
It is not that the vendors are lying. They are simply not asked about this and their incentive is not to surface costs that make the purchase decision harder. The ROI calculator they give you is built on an assumption of full adoption, perfect data, and maintained infrastructure. None of those assumptions hold automatically. All of them require ongoing work.
The organizations that understand this upfront are the ones that make a deliberate decision about who owns AI infrastructure and how that ownership is resourced. They treat AI maintenance the way they treat any other operational infrastructure: it has an owner, that ownership is in a job description rather than assumed, and there is a budget line for the labor it requires.
The organizations that do not understand this upfront discover it when they are trying to explain to a board why an AI deployment that looked promising in year one is producing questionable results in year two. By then the maintenance debt has accumulated and the retroactive investment required to restore performance is significantly higher than the ongoing maintenance investment would have been.
Budget for the deployment. Budget for the licenses. And budget explicitly, with a number and an owner, for keeping the thing useful after it is deployed. That third budget line is the one that determines whether the first two were worth it.
Top comments (0)