Key Takeaways
- In Pega's survey of 509 automation decision makers, 87% reported some level of bot failure and 41% said ongoing management took more time and resources than they expected.
- Industry benchmarks put annual software maintenance at 15 to 25% of the original build cost, and 50 to 80% of total lifetime cost of ownership — over a system's life, maintenance is the bigger number, not the build.
- RAND's 2024 study, based on interviews with 65 data scientists and engineers, found over 80% of AI projects fail, roughly twice the rate of IT projects without AI.
- Gartner predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027, on escalating costs, unclear value and inadequate risk controls.
- There are four ownership models — nobody, break-fix, retainer and in-house — and “nobody” is what you get by default unless you actively choose one of the others.
- The things that break are mostly credentials, vendor updates and changed forms, not the AI itself.
- Name the owner, the exception queue and the health check before launch day, not after the first failure.
Who maintains my AI automation after it's built?
Someone has to, and the honest default answer for most small businesses is that nobody does. An automation is not a website that sits still. It is a set of live connections between systems that each update on their own schedule, and every one of those updates is a chance for your automation to stop working.
There are only two roles that matter, and you need both filled by name before launch.
The business owner is someone inside your company who owns the outcome — the office manager, dispatcher or bookkeeper who notices that confirmations stopped going out. They do not need to understand the tooling. They need to know what “working” looks like and who to call.
The technical maintainer owns the fix — credential renewals, API changes, broken integrations. This is your agency, a contractor on retainer, or an internal developer.
Small businesses reliably fill the first role by accident and leave the second one empty. That gap is the entire problem. This is a different question from whether to automate or hire — you can get that decision completely right and still lose the system 14 months later.
Why does automation maintenance get skipped?
Because it is invisible at the moment of sale. A build has a demo; maintenance has a calendar reminder. Nobody films the second one.
Practitioners describe the same pattern repeatedly. In a widely-discussed r/automation thread on why small businesses cannot run their own tooling, the highest-voted comment framed the problem in one line: the best automation is “the one people can actually keep using without calling someone every week.” Another commenter put the product question sharply — what a small business actually wants is not a workflow but the ability to keep maintaining it once its creator is gone.
The second reason is that the build is priced and the upkeep is not. Industry benchmarks put annual software maintenance at 15 to 25% of the original build cost, and 50 to 80% of total lifetime cost of ownership. Almost no small-business automation quote includes that line. When it appears later as an invoice it reads as a vendor being opportunistic, rather than a cost that was always there.
Third, the failure is silent. A broken website is obvious within an hour. A broken automation just stops sending things. If you want a rough figure for your own setup, our support cost calculator is built for exactly this estimate.
What actually breaks in an AI automation?
Almost never the AI. The model is the most stable component in the stack. What breaks is everything around it — and knowing the categories tells you which skill set you actually need on call.
| What breaks | Why it breaks | Who can fix it | Frequency |
|---|---|---|---|
| Expired credentials & tokens | OAuth tokens, API keys and passwords rotate on the vendor's schedule | Technical maintainer | Every 3–12 months |
| Upstream API changes | Your CRM, calendar or accounting tool deprecates an endpoint | Technical maintainer | 1–3 times a year |
| Business rule drift | Hours, services, pricing or staff changed; the automation did not | Business owner | Continuously |
| Silent exception build-up | Edge cases fail quietly into a queue nobody is watching | Business owner | Weekly |
| Integration UI changes | A connected tool renames a field the automation depends on | Technical maintainer | Unpredictable |
Note the split in that third column. Two of the five categories are things a non-technical owner can and should handle themselves — if the system was built to expose them. That is a build-time decision, and it is the single biggest lever on your ongoing cost.
The mechanism, from a 30-year business owner: automations break “not because of Make — but because word/excel/adobe/quickbooks/outlook” keep shipping their own updates. Your automation sits downstream of every vendor's release schedule. That is the job, and it never ends.
How often do automations really break?
Often enough that breakage should be treated as the normal operating state rather than an incident.
The most useful hard numbers come from Pega's survey of 509 automation decision makers across seven countries. In Pega’s sample, 87% reported experiencing some level of bot failure, 41% said ongoing management was taking more time and resources than expected, and 38% said the bots added more complexity than expected. Respondents estimated their bots would last about three years.
Don Schuerman, Pega's CTO, tied it to process rather than tooling, arguing that bots “are only band-aids that temporarily mask the bad processes still lurking underneath.” That matters for a small business: if the underlying process is undefined, automating it just makes the ambiguity run faster.
The forward-looking number is Gartner's. In a June 2025 prediction, the firm expects over 40% of agentic AI projects to be cancelled by the end of 2027 on escalating costs, unclear business value and inadequate risk controls. Cancellation is a maintenance outcome — projects rarely get switched off deliberately, they get abandoned once nobody is left who can repair them.
RAND's 2024 study, based on interviews with 65 data scientists and engineers, found over 80% of AI projects fail — about twice the rate of IT projects without AI — with miscommunication about the problem to be solved as the leading root cause.
Who is legally responsible when your AI automation gets it wrong?
You are. This is settled enough in Canada to plan around.
In Moffatt v. Air Canada, 2024 BCCRT 149, decided by the British Columbia Civil Resolution Tribunal on 14 February 2024, a customer relied on an Air Canada chatbot's description of its bereavement fare policy. The information was wrong. Air Canada argued the chatbot was “a separate legal entity responsible for its own actions.”
Tribunal member Christopher C. Rivers rejected that outright, finding the airline responsible for all information on its website including the chatbot's, that it “did not take reasonable care to ensure its chatbot was accurate,” and that the customer's reliance was reasonable. Air Canada was ordered to pay $650.88 in damages for negligent misrepresentation.
Why this matters more than the dollar figure: the award was small, the principle is not. An unmaintained automation is a liability that speaks in your business's voice, with your authority, to your customers. A BC tribunal decision does not bind other courts, but it signals clearly how a Canadian adjudicator reads the question — and it makes “the vendor built it” a non-defence.
This is the argument for a monitored AI receptionist or customer-facing chatbot over an unattended one. A system that talks to customers needs a human who reviews what it said.
What are the four AI automation maintenance models?
There are four realistic arrangements. Most small businesses end up in the first by default, which is the one to avoid.
| Model | How it works | Annual cost | Best for | Main risk |
|---|---|---|---|---|
| Nobody (default) | Built, handed over, forgotten | $0 until it fails | Nothing | Silent failure, discovered by a customer |
| Break-fix | Call the builder when something stops | Hourly, unpredictable | Simple internal automations | No monitoring, so you still find out late |
| Support retainer | Fixed monthly fee, defined response time, health checks | 15–25% of build cost | Anything customer-facing | Paying for quiet months |
| In-house ownership | You hold all credentials, trained staff maintain it | Staff time + training | Teams with a technical person on payroll | Key-person risk |
For most owner-operated businesses the honest recommendation is a support retainer for anything a customer touches, and break-fix for internal-only automations where a two-day outage is survivable. Budget against the benchmark: an $8,000 build implies roughly $1,200 to $2,000 a year. That aligns with our published AI automation cost breakdown.
What should you put in writing before launch?
This is the entire defence, and it costs nothing to negotiate before you sign. Every item below exists because its absence has stranded somebody.
1. Named owners on both sides. One person in your business who owns the outcome, one at the vendor who owns the fix. Names, not roles.
2. Admin credentials in your name. You own the accounts — the automation platform, the API keys, the domain, and critically the business email. Vendors can have access. They should not have exclusive ownership.
3. A response-time commitment. What happens when it breaks at 4pm Friday, and what that costs.
4. The fix-versus-change line. Define in advance what counts as a covered repair and what is billable new work. This single clause prevents most disputes about surprise invoices.
5. A visible exception queue. Failed runs must surface somewhere a non-technical person looks, with approve, reject and needs-human controls. Hidden failures are the expensive kind.
6. A business-facing health check. Not “the workflow executed” — something closer to “last successful real booking: 20 minutes ago; credentials valid for 74 days; 3 open exceptions.”
7. A written exit process. How credentials, documentation and process maps transfer if you part ways. Agree it while everyone is friendly.
To pressure-test an existing setup against this list, the automation scorecard walks through it, and the AI readiness assessment covers the pre-build side.
How do you take over an automation someone else built?
Inheriting an undocumented automation is common and usually recoverable. Work in this order.
Establish access before touching anything. Log into every connected account directly, not through the builder's dashboard, and confirm you can see and export your own data. Check whose name the domain and business email are actually in. This is where the real leverage sits, and it is frequently not where owners assume.
Map what exists before changing it. Write out, in plain language, every trigger and every step. If you cannot describe what the automation does without opening the tool, you cannot safely modify it.
Run the replacement in parallel. Never cut over live. Stand the new version up alongside the old one, compare outputs for a full business cycle, then switch.
Then reduce the dependency. Document, move credentials into your ownership, and expose the business rules so routine changes stop requiring a developer. That is the same discipline behind the multi-location workflow in our review response-time case study.
Methodology and what we excluded
Statistics here come from primary sources, each linked inline: Pega's 509-respondent survey (September 2019 — dated, and Pega sells a competing automation category, so treat the direction as reliable and the precision as indicative), Gartner's June 2025 agentic AI prediction, RAND's 2024 report based on 65 practitioner interviews, Galorath's software maintenance benchmarks, and the full text of Moffatt v. Air Canada via CanLII.
Practitioner sentiment is drawn from two public Reddit threads with a combined 271 comments, read in full rather than sampled from titles. These are anonymous and are used for pattern, never as evidence for a number.
We deliberately excluded the widely-circulated MIT NANDA claim that 95% of generative AI pilots return nothing. It drew substantial methodological criticism after going viral, its reported sample sizes are inconsistent across write-ups, and “zero return” conflates measured failure with unmeasured outcomes. It is not load-bearing for anything argued above.
What this means for your business
Maintenance is not a technical problem you can solve by choosing better software. It is an ownership problem, and ownership is assigned with a name and a signature.
The businesses whose automations are still running in year three did one unglamorous thing at the start: they decided who was responsible before anything was built. That decision costs nothing at the negotiating table and is nearly impossible to retrofit once a system is live and the person who understood it has moved on.
If you are still deciding what to automate in the first place, start with what AI automation actually covers and how agentic AI differs, then come back here before you sign anything.
Maintenance is not only about your vendor — the platforms they build on change hands too, as Nvidia’s $12.93B acquisition of Hugging Face showed.
Frequently Asked Questions
Whoever is named as owner in writing before launch. If nobody is named, the practical answer is nobody: the builder moves on and the system degrades until it visibly fails. A workable split is a business owner inside your company who owns the outcome, and a technical maintainer under a support agreement who owns the fix.
Industry benchmarks put annual software maintenance at roughly 15 to 25% of the original build cost, and 50 to 80% of total lifetime cost of ownership. An automation built for $8,000 should therefore carry a budget of roughly $1,200 to $2,000 a year to keep running.
Partly, and the split is predictable. A non-technical owner can handle content changes, business rules, approvals and clearing an exception queue, provided the system was built with those controls exposed. Credential renewals, API version changes and integration repairs almost always need a technical maintainer.
Your business is. In Moffatt v. Air Canada (2024 BCCRT 149), the BC Civil Resolution Tribunal rejected the argument that a chatbot is a separate legal entity, held Air Canada liable for negligent misrepresentation, and awarded the customer $650.88.
It depends entirely on who holds the accounts. If you hold admin access to every connected service, own the credentials and have a written process map, you can hand the work to another maintainer within days. If the builder owns the accounts, you are negotiating rather than migrating.
In Pega's survey of 509 automation decision makers, 87% reported experiencing some level of bot failure and 41% said ongoing management took more time and resources than expected. Treat breakage as the normal operating state and budget monitoring accordingly.
Named owners on both sides, a response-time commitment for outages, confirmation that you hold admin credentials, a clear line between a covered fix and billable new work, a visible exception queue, a monthly business-facing health check, and a documented exit process.
For maintenance purposes, mostly no, and that is the useful insight. The AI model is the most stable part of the stack. What breaks is the same set of things that break any integration: credentials, API versions, changed fields and drifted business rules.
Get a Maintenance Plan Before You Get an Automation
We build AI voice, chat and booking systems for BC clinics, trades and multi-location retail — and every build ships with named owners, your credentials in your name, and a written support agreement.
Book Your Free AI Assessment →