Who Maintains an AI Automation After It Goes Live?

Who maintains an AI automation after it goes live?

An AI automation is maintained by one of four parties after it goes live, and you should know which before you sign anything.

The builder operates it. The system runs on the builder's infrastructure, they monitor it, they fix what breaks, and you get a report of what it produced. This is what BLACKSIG does, and the reason is unglamorous: we get the alert before you notice, because the alert comes to us.

The builder supports it on request. The system runs in your accounts and the builder fixes what you report, usually under a support arrangement with a response time. Workable, with one weakness. You only report what you notice, and the failures that cost most are the quiet ones.

Your people take it over. A capable internal team can own an automation, and some should. It needs somebody who can read the logs, hold the credentials, and know which vendor to call, and that person has to still be there in eighteen months.

Nobody does. This is the common case and it is rarely a decision. A project ends, the invoice is paid, the automation works, and the question never gets asked. It runs for seven months, then an input changes and it starts failing in a way nobody is watching for.

The four are not equally priced and they should not be. What matters at the point of signing is that the arrangement is named in writing, with who gets the alert, who is allowed to change the system, and how fast somebody looks.

What actually breaks in an AI automation?

What breaks in an AI automation is mostly not the AI: things outside your business change, and the automation finds out the hard way.

Vendor APIs retire on the vendor's timetable. OpenAI issued the deprecation notice for its Assistants API on 26 August 2025 and shut the endpoints off on 26 August 2026, after which calls to the assistants and threads endpoints simply stop working. The migration path is the Responses API for the model calls and the Conversations API for persisting history, and there is no automated tool for moving existing threads across. Twelve months of notice is generous by industry standards, and it still means somebody had to notice, plan and do the work. Model versions carry published shutdown dates of their own. If your automation calls a model by its exact snapshot name, that snapshot has an expiry.

Documents change shape. A supplier redesigns an invoice, a customer portal adds a required field, a lab exports a new column order. The system that read the old layout reliably starts getting the new one wrong on a fraction of documents, and that partial failure is worse than a crash because nothing alarms.

People change. The person whose inbox the automation watched leaves. A team starts using a new tool for the thing the automation was reading. Somebody renames a field in the CRM to make a report work. Each of those is a sensible local decision that breaks something elsewhere.

And accuracy drifts. The mix of inputs shifts with your business, so a system tuned on last year's customers meets more of the awkward cases this year.

None of this is specific to AI. Google's research team made the general point in Hidden Technical Debt in Machine Learning Systems (Sculley and colleagues, NIPS 2015): it is dangerous to treat machine learning quick wins as coming for free, because real systems commonly carry massive ongoing maintenance costs in the glue around the model rather than in the model. Eleven years on, that is still the part buyers underprice.

Is maintenance a big share of what an automation costs over its life?

Maintenance is the larger share of what an automation costs over its life, and software engineering has known the rough proportion for decades.

Robert L. Glass put it as Fact 41 in Facts and Fallacies of Software Engineering (2002): maintenance typically consumes 40 to 80 percent of software costs, averaging about 60 percent. That comes from the general software maintenance literature rather than from a 2026 study of AI systems, so treat it as an order of magnitude rather than a precise number. The useful consequence is the same either way: on average the build is the smaller half of what you are buying, and a quote that covers only the build is a quote for part of the job.

Glass's next fact is worth having alongside it. Enhancements account for roughly 60 percent of maintenance costs, which means most of what gets called maintenance is not repair. It is the system getting better at the job once real work has run through it. An arrangement that covers only breakage is buying the smaller half of the smaller half.

Four things decide where in that range you land. How many external systems the automation touches, because each one is a separate thing that can change under you. How variable the inputs are, since documents from two hundred irregular suppliers need more attention than documents from four regular ones. How much the system decides unattended, because unattended decisions need monitoring that attended ones do not. And whether the business itself is changing, since an automation in a company that reorganises twice a year is a moving target.

What it is not, in our experience, is a straight line. Maintenance clusters: quiet for months, then a vendor deprecation and two document changes land in the same fortnight. Which is the argument for an arrangement where somebody is simply watching, rather than one where you buy hours after something has already gone wrong.

What should a maintenance arrangement actually cover?

A maintenance arrangement should cover six things, and each one is a question you can ask on a sales call.

What to pin down	What a good answer sounds like	What a bad answer sounds like
Who gets the alert	The builder's monitoring fires to the builder, and you see it in the report	"Let us know if anything looks wrong"
How fast somebody looks	A stated response time, with a named route out of hours for anything customer facing	"We are pretty responsive"
What counts as covered	Breakages, vendor changes, model migrations and layout changes are in; new capability is a change request	Everything is a change request
Where it runs	A named environment, with the credentials and access documented	Nobody is sure which account the automation lives in
Who may change it	A named person or team, with changes logged	Three people have the keys and no log
What you get if you leave	Your data, an export, and a documented handover	Silence, or a conversation about it later

The last row is the one buyers skip and later regret. Ask it early, when the answer is cheap to give.

For our own arrangement: systems we build live on our infrastructure and we run them from there, which includes the vendor migrations and the layout changes. The subscription covers the operating and the improvement work. If a client cancels, the systems do not switch off; the arrangement drops to maintenance, priced on how many systems are running and what they cost to operate.

What happens if nobody maintains an AI automation?

An unmaintained AI automation dies quietly, and the business concludes that AI did not work for them.

That failure shows up in the research as abandonment. Gartner predicted in July 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, naming poor data quality, inadequate risk controls, escalating costs and unclear business value. Three of those four are ownership problems rather than technology problems.

MIT's Project NANDA report The GenAI Divide: State of AI in Business 2025, which reviewed more than 300 publicly disclosed AI initiatives and interviewed representatives of 52 organisations, found that in its interview sample tools built with external partners reached deployment about 67% of the time against about 33% for internally built ones. Deployment is not the same as still running two years later, but the direction is consistent with what we see: the systems that survive have somebody whose job it is to keep them alive.

The pattern inside a business is predictable. The automation starts failing on a subset of inputs. Somebody works around it by hand, because that is faster than raising it. The workaround becomes the process. Six months later the automation is switched off and nobody can say exactly when it stopped being useful. Nothing dramatic happened. There was simply no owner, which is the failure mode examined in full in why AI automation projects fail.

Can somebody else take over an automation we already have?

Somebody else can usually take over an automation you already have, and how hard it is depends on three things you can check this week.

Documentation first. Not a diagram: the credentials, the environment, the integrations by name, and what the system is supposed to do when an input is wrong. If that exists, a takeover is a few days of reading.

Access second. Automations built in a hurry tend to run under a personal account, with API keys in somebody's notes and a cloud function in a project nobody else can see. Find out whose account it runs under before that person leaves, because that question gets much more expensive later.

Design third. A system that writes into your CRM through a documented interface can be picked up by anyone competent. A system built on a platform the original developer configured by hand, with logic spread across twelve screens and no export, is a rebuild wearing a takeover's clothes. Which of the two you have is established before anybody quotes, because a takeover and a rebuild are different pieces of work with different prices.

A takeover also means inheriting whatever the system is doing wrong. We start by watching it against the manual process for a period, which is the same thing we do with a new build, and the reasoning for that is in what happens when AI gets something wrong in your business.

How do you tell on the sales call whether a firm will still be there?

You can tell on the sales call whether a firm will still be there by asking three questions, and the answers sort firms faster than any case study.

Ask what broke last month. A firm that operates what it builds has a specific answer: a supplier changed an invoice layout, a vendor retired an endpoint, a client renamed a field. A firm that delivered and left will tend to describe its architecture instead, which is a different answer to a different question.

Ask who gets the alert when something fails at 2am, by name and route. Vagueness here is the whole answer.

Ask what they have talked a client out of. A firm that has never recommended an off the shelf product, or told a client to fix their records before automating anything, either has not been asked hard questions or does not say no. We publish maturity labels on the industry boards, marked proven, working or early, so you can see that judgement before you are in a sales conversation.

Then ask for one client who has had the system for more than a year, and ask that client what maintenance has actually looked like. Our work with Universidad Maimonides is on the site for that purpose: it has been running since it was built, on our infrastructure.

Frequently asked questions

How much does it cost to maintain an AI automation?

What moves the number is how many external systems the automation touches, how variable its inputs are, how much it decides without a person checking, and whether anybody is monitoring it or waiting for you to report a problem. Software engineering literature has long put maintenance at 40 to 80 percent of total software cost, averaging about 60, so budget for the ongoing work as a real line rather than a rounding error. BLACKSIG does not publish a rate card; the operating work is part of the subscription, and if a client cancels, the arrangement drops to maintenance priced on how many systems are running and what they cost to operate.

How does maintenance on an AI automation actually work?

Monitoring watches whether the system is running and whether its outputs still look right, which is two different checks. Vendor changes get handled on the vendor's timetable rather than yours: a deprecation notice arrives, somebody plans the migration, it ships before the shutdown date. Input changes get caught by sampling outputs against what a person would have done. Improvements are separate work, decided from what the system has learned about your process since it went live. Systems we build run on our infrastructure, so all of that happens on our side and shows up in the report of what each system produced.

Should our own team maintain it instead of the firm that built it?

Your team should own it if automation is going to be continuous work at your company and you have somebody who can hold it, and that person has to be there in eighteen months. If the first automation is one significant build with a long tail, having the builder operate it is the cheaper and sturdier arrangement, because the knowledge does not walk out with a resignation.

Can our existing automation be maintained by a different firm?

Usually, and the three things that decide it are documentation, access and design. Documented credentials and integrations make a takeover a few days of reading. Automations running under somebody's personal account, with keys in their notes, cost more to inherit than to rebuild. Ask whoever built it for a written handover now, while the relationship is good, rather than at the point you need it.

What happens to the systems if we stop paying?

With us, they do not switch off. The arrangement drops to maintenance, priced on how many systems are running and what they cost to operate, which is well below the subscription. Ask any firm this question directly and get the answer in writing, because "we would work something out" is not an answer and the systems in question are running your business by then.

Who Maintains an AI Automation After It Goes Live?

The short version