Most conversations about AI projects end at launch. The proposal covers the build, the demo proves the build, the invoice closes the build. Then the system goes live, everyone moves on, and a different set of costs starts running. Nobody scoped those, because launch day is where the conversation stopped.
This piece is the conversation that should happen before you sign anything. Not to scare you off. Most AI systems that earn their build also earn their upkeep, and the upkeep is usually modest next to the value. But "usually modest" is not "zero," and the operators who get burned are almost always the ones who budgeted as if the system would run itself.
It will not run itself. Here is what actually keeps it running.
The build is a one-time cost. Everything below is forever.
Custom software has always had a maintenance tail. Databases need backups, dependencies need updates, servers need patching. Operators who have owned software before know this rhythm.
AI systems have that tail plus four more, and the four are less familiar because they do not exist in ordinary software. They come from one fact: an AI system depends on a model you do not control, running against a world that keeps changing. Ordinary software mostly breaks when you change it. AI systems can degrade while you change nothing at all.
That is the mental shift. Everything else in this piece is detail.
Cost one: the model underneath you will change
Your system calls a model through an API, and that model belongs to someone else. Providers retire model versions on their own schedule, usually with months of notice, sometimes with less. When a version is retired, your system moves to a newer one whether you planned for it or not.
Newer is usually better on average and different in particular. A prompt tuned carefully against one model version can behave differently on the next: the tone shifts, the format wobbles, an edge case that used to be handled starts slipping through. None of this shows up as an error. The system keeps returning answers. They are just not quite the answers you validated.
What this costs you in practice: a few times a year, someone has to re-run your test cases against the new model, read the outputs, and adjust prompts where behavior moved. If your system was built with a written set of test cases, this is a day or two of work per migration. If it was built without one, it is a research project, because nobody can say precisely what "working correctly" looked like before.
The lesson for buyers is simple and worth stating during scoping, not after: a test suite of real examples with expected behavior is not a nice-to-have. It is the thing that turns every future model change from an incident into a chore.
Cost two: the world drifts and the prompts stay still
The second kind of degradation has nothing to do with the model. Your business changes. Products get renamed, policies get updated, a new document format shows up, customers start asking about something that did not exist when the system was built.
The prompts and reference material inside your AI system are a snapshot of your business at build time. Every month after launch, that snapshot gets a little more wrong. An intake triage system built in January does not know about the service line you added in June. It will not fail loudly. It will confidently route June's inquiries using January's categories.
This is the cost that surprises operators most, because it feels like the system broke, and actually the business moved. The fix is not technical. It is a standing habit: when something material changes in the business, someone asks "does the AI system need to know this?" and updates it if so. That someone must be named. In companies where nobody owns the question, the answer is always no, until the day the drift becomes visible to a customer.
Budget shape: an hour or two a month of attention in a stable business, more in a fast-moving one. Small. But it has to be someone's job.
Cost three: the API bill, and why it needs a ceiling
Running costs for most operator-scale AI systems are genuinely low. A system that processes a few hundred documents a day or answers internal questions all afternoon typically runs on tens to low hundreds of dollars a month in model usage. For the value delivered, this is usually the least interesting line on the ledger.
What makes it interesting is the failure mode. Usage-based pricing means a bug can spend money. A retry loop that never gives up, an integration that starts sending the same batch every minute instead of every day, a user who finds a way to paste in a whole archive: each of these turns a modest bill into a surprising one, quietly, at machine speed.
The protection is not vigilance. It is plumbing, and it should be part of the build: spending alerts at a threshold you choose, hard caps where the provider offers them, and rate limits inside the system itself so no single caller can run the meter. If a vendor proposes an AI system without mentioning cost controls, ask where the ceiling is. "We'll keep an eye on it" is not a ceiling.
Cost four: someone has to notice when it goes quiet
Ordinary software fails loudly. A crashed server throws errors, users complain, someone gets paged. AI systems have a second, quieter failure mode: the system keeps running and the quality slips, or the volume silently drops to zero because an upstream credential expired, and nothing anywhere turns red.
A system that summarizes inbound leads is only valuable if it is actually seeing the leads. If the connection to the lead source breaks on a Friday, the system does not fail. It just has nothing to say, indistinguishable from a quiet weekend, until someone asks on Wednesday why the pipeline looks thin.
The fix is monitoring designed for silence, not just for errors: every automated pipeline should declare how often it expects to produce something, and something else should notice when it misses that expectation. This is a small amount of engineering, cheapest when it ships with the system, and it is the difference between finding a dead pipeline in an hour and finding it in a month.
When you evaluate a build proposal, this is a revealing question: "how will we know if it stops working?" A good builder has a specific answer. A demo-focused builder has not thought about it, because demos never run long enough to die.
The person who answers
Fold the four costs together and a pattern appears: none of them is large, and every one of them requires a person. Someone to re-test after model changes. Someone to keep the prompts current with the business. Someone to watch the spend. Someone to respond when the monitoring fires.
This is the real post-launch question, and it is an ownership question, not a technical one. There are three honest answers.
You own it in-house
Right if you have technical staff with room to take it. The system's upkeep becomes a few hours a month of their time, and they build familiarity that pays off when you want changes. The risk is the quiet kind: AI upkeep is nobody's emergency, so in a busy team it slides until something visible breaks. If you choose this route, put the recurring tasks on an actual calendar, not on good intentions.
The builder retains it
Right for most operators without technical staff. The people who built the system are the cheapest people to maintain it, because they already know where everything is. This is exactly the arrangement Elorati / Managed exists for: we run what we build, watch the monitors, absorb the model migrations, and there is a person who answers. Whoever you hire, the shape of the deal matters more than the logo: a named response time, a monthly summary of what happened, and a clear list of what is included versus billed.
Nobody owns it
This is the default if you do not choose one of the other two, and it is a slow-motion write-off. The system works at launch, degrades along the four paths above, and in a year or two it is quietly turned off, having delivered a fraction of what it cost. When people say "we tried AI and it didn't stick," this is very often the actual story: not a bad build, an unowned one.
What this means for the buying decision
None of this changes whether AI systems are worth building. It changes how to evaluate the decision. Two practical adjustments:
First, price the ownership tail into the original math. When you weigh a build against the manual work it replaces, add the realistic upkeep: a maintenance arrangement or a slice of an employee's month, plus the running API costs. For a system that saves real hours every week, this rarely kills the case. For a marginal case, it should, and better now than after the invoice.
Second, let the maintenance conversation grade the vendor. Ask every prospective builder three questions: what happens when the model version changes, how will we know if it stops working, and where is the spending ceiling. Builders who plan for years give specific answers, because they have been on the receiving end of every failure in this piece. Builders who plan for the demo change the subject. That difference tells you more than any portfolio.
The systems that are still earning their keep years after launch are not the cleverest ones. They are the owned ones. Decide who owns yours before it ships, and most of this piece becomes a checklist instead of a warning.
Frequently Asked Questions
How much should I budget for maintaining an AI system?
As a shape rather than a promise: model usage for operator-scale systems commonly runs tens to low hundreds of dollars a month, and human upkeep runs a few hours a month in a stable business, whether that is in-house time or a maintenance arrangement with the builder. The honest answer for your specific system should come from whoever builds it, in writing, as part of the proposal. If a proposal has no maintenance line at all, that is the finding.
Can an AI system really degrade if nobody changes anything?
Yes, along two paths. The model provider migrates versions on their own schedule, and behavior tuned on one version can shift on the next. Separately, your business changes while the system's prompts and reference material stand still, so its picture of your business ages. Neither path produces an error message, which is why scheduled testing and a named owner matter more here than in ordinary software.
What is the single most important thing to ask a vendor about post-launch support?
Ask "how will we know if it stops working?" It is the question that best separates builders who plan for years of operation from builders who plan for the demo. Good answers are specific: monitoring for missed schedules, alerts on error rates and spend, a named person and response time. Follow with the other two: what happens when the model version changes, and where the spending ceiling is.
Is it better to maintain the system in-house or pay the builder to run it?
In-house works when you have technical staff with genuine room to own it and the discipline to schedule the recurring work. The builder running it works when you do not, and it is usually cheaper than it sounds because the builder already knows the system. The only wrong answer is the default one, where nobody explicitly owns it. Unowned systems degrade quietly and get abandoned, and the write-off costs more than either form of ownership would have.
This guide provides educational information based on industry research and case studies. Individual results vary by market, budget, and execution.