How much does it cost to maintain an AI system
Recurring AI system costs: usage, hosting, maintenance and further development. How to estimate them and what happens if they are overlooked.
Reading time: 9 min
An AI system is not a purchase: it is something that lives. The development cost is one-off, but around the system everything changes — the business management software gets updated, price lists change, and previously unseen cases arrive.
Ignoring recurring costs is the most common way in which a technically successful project becomes a lost investment, and it almost always happens in the second year.
In summary
- Four recurring voices: consumption, hosting, maintenance, evolution.
- Maintenance is not necessary because the system is bad: it is necessary because the environment changes.
- A maintenance-free system degrades and is abandoned, usually to the second year.
- We need one. internal person with his first and last name following him, not an office.
- Post-release assistance goes agreed before, not discussed when something breaks.
- The demands for evolution are a good sign, but they go on a separate budget.
The Four Voices
| Voice | What it includes | How he behaves |
|---|---|---|
| Consumption | Use of token APIs | It grows with use |
| Hosting | Where the system runs | Stable, content |
| Maintenance | Corrections, adjustments to external changes | Stable |
| Evolution | New cases, new functions | It grows if the system likes |
Consumption is treated in cost of AI API. The two least understood items are the last ones, and it is worth distinguishing them: maintenance is used to keep what's there working; evolution adds new things. Confusing them leads to unpleasant contractual discussions.
Why a system that works needs maintenance
Typical causes have nothing to do with the quality of development:
- The management software is updated and changes the way it exposes data
- A service provider modifies its interfaces or decommissions them
- The company introduces a new category of products or a new price list
- Change legislation that affects responses given to customers
- There comes a type of request that did not exist at the time of the project
None of these is a fault: they are the normality of a living company. A system integrated with processes reflects those processes, and when processes change the system needs to be updated.
Who follows him in the company
This is the entry that does not cost money and determines the outcome more than all the others. It serves a person with three tasks, which take a few hours a month:
- Watching a Champion of what the system produces, regularly.
- Collecting reports colleagues instead of leaving them in chats.
- Decide when to call the supplier, before the problems accumulate.
He does not need to be a technical figure: he needs to know the process and have a mandate to deal with it. The lack of this person is the most frequent cause of systems abandonment, as described in hidden costs of AI projects.
Practical examples
Passive bill automation, second year. The management software provider updates the software and changes the export format. Automation stops working. With a maintenance contract: resolved in a few hours. Without: the administration returns to hand-input and after a month no one talks about the project anymore.
Customer assistant on e-commerce. The catalogue expands with a new line. The assistant continues to respond, but on new products he knows nothing and sudden. You need to update the sources: ordinary maintenance, a few hours, but someone has to notice.
Agent for quotes. It works well, and precisely because of this, the salespeople ask to add two price list variants and discount management. This is not maintenance: it is development, and should be assessed as a small project of its own.
How much work is, in practice
The percentages say little to those who have to decide. It is more useful to understand what activity it is, because most require hours, not days.
Periodic check-up. Look at a sample of what the system produces —twenty conversations, thirty processed documents —and verify that they are still correct. It is the activity that intercepts problems before customers discover them, and it takes little time if done regularly.
Updating the sources. When changing a price list, a product, a procedure, the system must know. If the sources are organized well, it is a matter of replacing a document; if they are messy, each update becomes a small project. It is the reason why it is worth investing in the order of the contents at the beginning.
Technical adjustments. They are the ones that require the provider: a changing interface, a service that is discontinued, a management software update. They are unpredictable at the moment but predictable in frequency.
Requests for improvement. They come if the system works, and it's the best signal you can get. They must be collected, ordered and faced in blocks instead of one at a time, otherwise they become a continuous rivulet of small interventions that cost more than an organized intervention.
When it is better to redo instead of maintaining
There comes a time, for some systems, when maintenance costs more than a rewrite. It is not a failure: it is normal, and recognizing it in time avoids continuing to spend on a basis that no longer holds.
There are three signals: each change takes longer than the previous one; the exceptions managed "apart" have become more numerous than those managed by the system; the process that the system automates has changed so much that it no longer resembles what it was built for.
When two of these three signals are present, it is worth putting the hypothesis of redoing on the table. Often the second version costs less than the first, because the analysis work has already been done and you know exactly what it is needed — something nobody knew about the first version.
What to Put in the Contract
Maintenance is the part of the relationship with a supplier that generates the most friction, almost always because it has not been defined. It is worth closing four points before signing.
What is included and for how long. An initial period of corrections is practice: it must be written how long it lasts and what it includes.
What is maintenance and what is evolution. It is the distinction that generates the worst discussions. An even approximate definition put in black and white is worth more than long subsequent negotiations.
Response times. You don't need a complex service contract: you just need to know if a block is dealt with on the day or in the week, and that the two things cost differently.
What happens if you change providers. Documentation, credentials, code properties. These are the three points that make it possible to leave, and must be agreed when the relationship is good.
The complete picture on these contractual aspects is linked to the choice of partner, treated in DIY AI or agency, and to planning in AI budget for SMEs.
Mistakes to Avoid
- Not budgeting anything from the second year onwards. It's when the system starts to need it.
- Not agreeing on support in the contract. It's being discussed at the worst time.
- Not assigning an internal contact. Reports are lost.
- Confusing maintenance and evolution. It generates friction with the supplier.
- Ignoring signs of degradation. "We still do it by hand" is the first symptom.
- Not monitoring usage. It grows silently with use.
How to apply it in the company
When you receive a quote, explicitly ask for three things: what is included in the first few months after release, what the next service costs, and what interventions are considered evolution instead of maintenance.
Then, internally, appoint the person who will follow the system and agree them a few hours a month. It is the investment with the best cost-to-probability ratio that the project survives.
The overall cost framework is in how much AI costs in the company and annual planning in AI budget for SMEs.
One final method consideration remains. Maintenance of an AI system is not a cost to be minimized at all costs: it is the one that protects the investment already made. Saving a few hundred euros a year on a system that has cost thousands, and losing it for that, is the worst deal possible. The correct criterion is not to spend as little as possible, but to spend enough for the system to stay alive and useful.
Conclusion
Maintaining an AI system costs, and the cost does not depend on the quality of the development but on the fact that the company around changes. Consumption, hosting, maintenance, evolution: four predictable items that must be budgeted from day one.
The decisive variable, however, is not economic: it is Have someone take care of it. A system with a careful referent survives for a long time; one without shutting down in the second year, regardless of how much has been paid.
AI becomes useful when it enters processes. Giallo Studio helps SMEs and teams to build concrete, measurable and sustainable automations.
Giallo Studio guides: methodology and sources
How we apply it in the company
Related resources
FAQ
How much does it cost to maintain an AI system every year?
There are four items: API consumption, hosting, corrective maintenance and evolution. A prudent criterion is to provide an annual percentage of the development cost for the maintenance part, plus separately estimated consumption. The exact figure depends on how much the system is integrated and how much it is used.
Why is maintenance needed if the system works?
Because everything around the system changes: the management system is updated, a provider changes its interfaces, the business introduces a new price list or a previously unseen case arises. An integrated system is not an appliance: it operates in a changing environment.
What happens if I don't plan maintenance?
The system degrades slowly. First it stops covering a few cases, then people start bypassing it for cases it doesn't handle, finally it's abandoned. It's the most common way a successful project becomes a lost investment, and it typically happens in the second year.
Does the provider have to provide assistance?
It must be explicitly agreed: what is included, for how long, response times and the cost of anything beyond that. A contract that omits post-release support leaves a grey area that emerges at the worst moment, when something has broken.
Who should be following the system internally?
You need an identified person, rather than a department. Their role is not technical: it is to notice when the system starts behaving differently, collect reports and decide when to contact the provider. Without this role, problems accumulate until they become serious.
Do maintenance costs increase over time?
They tend to grow if the system is extended and stabilize if it stays the same. A widely used system generates demands for improvement: it is a good sign, but it must be managed as an evolution budget and not confused with ordinary maintenance.