Nobody asks about the AI automation warranty until the thing stops working. By then, the build is paid for, the person who built it has moved on to the next client, and you are the one explaining to a customer why the booking confirmation never arrived. I have picked up more than one system in that exact state.
The uncomfortable truth is that most AI build contracts say almost nothing about what happens after launch. They cover the deliverable. They rarely cover the six months after the deliverable meets reality.
This post walks through what an AI automation warranty should actually cover, the four ways these systems break once they are live, which failures are genuinely the builder’s problem and which are yours, and the specific questions to ask before you sign anything.
Key Takeaways
- An AI automation warranty covers defects in what was built, not changes in the world around it, and your contract has to say clearly which is which.
- Four things break after launch: the model, the integration, the data, and the business process. Only two of them are usually the builder’s fault.
- Most AI build contracts carry a 30-day bug fix window and nothing else, which is shorter than the time it takes to notice a slow failure.
- Silent failures cost more than loud ones. A bot answering wrongly for six weeks does more damage than one that stops answering at all.
- Ask for named response times by severity, not a vague promise of support, and check whether the clock starts on your report or their detection.
- Monitoring belongs inside the warranty. If nobody is watching the automation, the cover is only as good as the day you happen to check it.
- Third-party changes, API deprecations and pricing shifts sit outside most warranties, so agree upfront who pays to adapt when a vendor moves.
- A builder who will not warrant their work either does not trust it or does not plan to be around in six months. Both are worth knowing early.
What an AI Automation Warranty Actually Covers
A warranty is a promise about defects. If the thing you paid for does not do what the contract said it would do, the builder fixes it at their cost, within an agreed window. That is the whole idea, and it is the same idea behind a warranty on a hot water cylinder or a set of tyres.
Where AI gets slippery is the definition of “defect”. Traditional software either works or throws an error. An AI system can run perfectly, return a confident answer, and be wrong. The logs will show a successful call. The dashboard will show green. And your customer will have been told the wrong price.
So a useful AI automation warranty has to define correctness in business terms, not technical terms. Not “the API returns a 200 response” but “the assistant books the appointment into the correct calendar with the correct service type, and where it cannot, it escalates to a human within five minutes”.
In New Zealand, there is a legal floor underneath all of this. Services supplied to a business are covered by ordinary contract law, and where you are buying as a consumer, the Consumer Guarantees Act requires services to be carried out with reasonable care and skill and to be fit for the purpose you made known. That floor is real, but enforcing it means a dispute, and a dispute is the most expensive way to get an automation fixed. A written warranty exists so you never have to reach for the legal floor.
Three things separate a warranty from a support agreement, and the two get muddled constantly:
A warranty is retrospective. It covers work already delivered, at no additional cost, for a defined period. A support agreement is forward-looking. It covers changes, tuning and new requests, and you pay for it monthly. A service level agreement is a promise about response speed, and it can attach to either.
You want all three named separately in the contract. When they are bundled into a single line that says “ongoing support included”, nobody can tell you six months later whether fixing the broken calendar sync is covered work or a new quote.
The Four Ways AI Automation Breaks After Launch
Before you can negotiate cover, you need to know what you are covering against. Automation failures fall into four groups, and they have very different owners.
1. The model changes underneath you
The AI model powering your system gets updated by the vendor. Sometimes that is announced. Sometimes it is not. A prompt that produced tidy, consistent output in March can produce slightly different output in June, because the thing reading the prompt is no longer quite the same thing.
This is the failure mode most business owners have never heard of, and it is the one that catches people out. The automation did not break. It drifted. Output quality slides a few per cent, then a few per cent more, and nobody notices until a customer complains about something odd in an email.
Whose fault is it? Nobody’s, strictly. But somebody has to own the fix, and if your contract is silent, that somebody is you.
2. An integration snaps
Your automation talks to other systems: your CRM, your calendar, your accounting software, your phone system. Every one of those connections is a dependency. Tokens expire. APIs get deprecated. A vendor changes a field name. Someone on your team revokes an app permission during a tidy-up and has no idea what it was attached to.
Integration breaks are usually loud and usually quick to fix, which makes them the best-behaved category. They are also the most common. If you are running an automation across four systems, assume at least one connection will need attention in any given year.
3. The data goes off
Automations run on the data you feed them. Your service list changes. You add a new location. Prices go up. A staff member leaves, and their calendar stops being the right destination for bookings.
The system keeps doing exactly what it was built to do, using information that is no longer true. This is not a defect in the build. It is a maintenance gap, and it is almost always the client’s responsibility unless you have specifically bought a service that includes keeping the knowledge current. Worth knowing before you get an invoice for it.
4. The business process moves
The biggest one, and the least technical. You changed how you work. You now qualify leads differently, or you added a deposit step, or two teams merged. The automation encodes a process that no longer exists in your business.
I have seen automations turned off entirely because of this, six months after a build that worked fine, with the owner concluding “AI didn’t work for us”. It worked. The business moved, and the system was never told.
This is why I push clients toward a scheduled review rather than a set-and-forget install. I wrote about the timing of that review in more detail in the 90-day AI automation checkpoint, and the short version is that the first quarter after launch is where almost all of the drift shows up.
What a Good AI Automation Warranty Includes
Here is what I would want to see in writing before handing over money for any AI build. Not all of it will be on offer. The point is to know what you are trading away when it is not.
A defined warranty period, in months, starting from a named event. Thirty days is common, and it is too short. Ninety days is a reasonable floor for a simple automation. Six months is fair for anything touching money or bookings. Check what starts the clock: signing, delivery, or the day the system actually goes live with real customers. Those can be weeks apart.
Severity tiers with named response times. Not “we’ll get to it promptly”. Something closer to: a total outage gets a response within two business hours, a partial failure within one business day, a cosmetic issue within five business days. The response time is when a human starts work, which is different from when it is fixed, and both should be stated.
Whether the clock starts on your report or their detection. This one matters more than it sounds. If the only trigger is you noticing and raising a ticket, then the warranty is doing nothing for the failures you cannot see.
Monitoring, with named checks. A warranty without monitoring is a warranty on the honour system. Ask what is being watched, how often, and what happens automatically when a check fails. At minimum: is the automation running at all, is it completing successfully, and is the volume of work it handles roughly what it was last week? A sudden drop to zero handled conversations is a five-second detection if anyone is looking, and a five-week detection if nobody is.
Root cause, not just restart. Anyone can turn it off and on again. A warranty worth having says the builder will identify why it failed and fix the cause, and will tell you in plain language what happened. This is also where an audit trail earns its place, because without a record of what the system did and why, root cause analysis is guesswork.
Named exclusions. A warranty that excludes nothing is a warranty nobody intends to honour. Good ones say plainly: this does not cover changes you make to connected systems, changes to your own process, third-party price rises, or new features.
What happens at handover if the relationship ends? Who holds the credentials, where the configuration lives, and can another builder pick this up? If the answer is that everything sits inside one person’s private account, you do not own the automation. You are renting access to it.
The reason I am specific about all this is that the failure rate on business AI projects is genuinely high. MIT research widely reported in 2025 put the share of enterprise AI pilots delivering no measurable return at around 95%, and the pattern in the failures was consistent: they started with the tool rather than the process, and nobody owned the system after launch. A warranty is one of the few contractual mechanisms that forces someone to own it.
What Sits Outside the Warranty, and Who Pays
The grey zone is where relationships go bad, so it is worth walking into it deliberately before you sign.
Third-party vendor changes. Your voice AI provider changes their pricing model. Your CRM deprecates the endpoint your automation uses. Neither is a defect in the build, and no sane builder will warrant against decisions made by companies they do not control. But somebody has to do the work of adapting.
The fair arrangement I use: adapting to a vendor change within the warranty period is covered up to a stated number of hours, and beyond that it is quoted. That way a small breakage does not turn into an argument, and a genuinely large rebuild does not get absorbed by someone who never priced for it.
Anything you changed. If your team edits a workflow, revokes a permission, or reconfigures the CRM, that is on you. This is not builders being precious. It is the only way anyone can warrant a system they no longer fully control. Ask for a short list of “do not touch without telling us” items at handover, and give it to whoever administers your systems.
Volume beyond what was scoped. A system built for 200 conversations a month may behave differently at 2,000. Not badly, necessarily, but differently, and the cost profile certainly changes. Scope the expected volume in writing so nobody is surprised.
Model output quality in edge cases. This is the honest one. Nobody can warrant that an AI system will handle every possible input correctly, because the space of possible inputs is infinite. What can be warranted is behaviour at the edges: that when the system is unsure, it escalates to a human rather than inventing an answer. That is a design decision, and it belongs in the contract.
The distinction I hold to is this. A builder should warrant the design, the build quality and the failure behaviour. Nobody should be asked to warrant the future behaviour of somebody else’s model.
Questions to Ask Before You Sign an AI Automation Warranty
Take these into the conversation. The answers tell you as much about the builder as they do about the cover.
“What breaks first, and how would I find out?” The honest answer names a specific failure mode. A vague answer means they have not run one of these long enough to know.
“How many of these have you had running for more than a year?” Longevity is the real proof. Anyone can launch. Keeping something alive through model updates, staff changes, and a rebrand is the harder skill, and it is the one the warranty is really testing.
“Walk me through the last time one of your systems broke.” What broke, how long until they knew, how long until it was fixed, and what changed afterwards so it would not happen again. A builder who cannot recall a single failure has either not been doing this long or is not telling you the truth.
“If I stop working with you in twelve months, what do I keep?” Credentials, configuration, prompts, documentation, and the ability to hand it to someone else. Get the answer in writing.
“What is watching this while I sleep?” Automations exist to run when you are not there. That is the entire point. So the monitoring question is not a technical detail; it is the whole value proposition. Dr Claire’s practice had two receptionists and was still missing close to half of its inbound calls, which is exactly the kind of thing nobody sees until it is measured. After the phone was handled properly, booked appointments rose 44%. That gain is only durable if something is checking, every day, that the phone is still being answered.
“What happens in the first 90 days?” The right answer includes a scheduled review, not just a support inbox. The first quarter is when process drift shows up and when the tuning gains are largest.
“Which parts of this will need me to keep something up to date?” Every automation has a maintenance surface: a price list, a service menu, a staff roster, a knowledge base. Knowing yours before launch turns an argument into a calendar reminder.
Why the Warranty Question Reveals More Than the Demo
Here is the pattern I keep seeing. Someone buys an automation because the demo was impressive. The demo is always impressive. Demos run on clean data, a happy path, and a person who knows exactly what to type.
Your business is not a demo. Your business has a customer who rings at 4.55 pm on a Friday with a half-formed question, a staff member who spells the suburb three different ways, and a supplier who changed their email address without telling anyone. The value of an automation is not what it does on day one. It is what it does on day 200, when all of that has happened.
That is why the warranty conversation is the most useful conversation you can have with a potential builder. It moves the discussion from “look what it can do” to “here is what I will stand behind”. People who plan to be around in a year answer it easily. People who plan to invoice and disappear get vague.
It is also a good test of whether the person is building you a system or selling you a tool. A tool gets handed over. A system gets owned, watched, and adjusted as the business it serves changes. The difference shows up in the contract long before it shows up in the results, and you can read about how that plays out in practice in these small business automation case studies.
One more reason to push on this. The automation you buy first is rarely the last one you buy. If it works, you will add another, then another, and eventually they start talking to each other and to your data. At that point, you are not maintaining three separate automations; you are running a small AI workforce with a shared brain underneath it. Warranty and ownership terms that were merely annoying on a single build become genuinely expensive to unwind across five. Get the pattern right on the first one.
Conclusion
An AI automation warranty is not paperwork. It is the answer to a simple question: when this breaks, and it will, who fixes it, how fast, and at whose cost.
Get four things in writing. A warranty period long enough to catch slow failures, ninety days at absolute minimum. Response times tied to severity, with the clock starting on detection rather than only on your complaint. Monitoring, so that detection actually happens. And named exclusions, so both sides know where the line sits before anyone is annoyed.
The bigger point sits underneath all of it. A single automation with nobody watching it is a liability waiting to surface. A set of automations sitting on a proper AI brain, with your business context, your data and clear ownership, keeps working when the world shifts around it. The warranty conversation is the first honest signal of which one you are being sold.
Ready to Work Out What You Actually Need Covered?
If you have an automation running and you are not sure who owns it when it breaks, or you are about to sign for a build and want a second opinion on the terms, book a 30-minute Discovery Call at octavius.ai/book. No pitch deck. I will ask what you are running, where it touches money, and what would happen tomorrow if it stopped. Thirty minutes is usually enough to tell you whether you have a gap worth closing.
Frequently Asked Questions
What is an AI automation warranty?
It is a written promise from whoever built your automation that they will fix defects in that build, at their cost, for an agreed period after launch. It covers work that does not perform as the contract described. It does not usually cover changes you make to your own systems, third-party vendor changes, or new features you decide you want later.
How long should an AI automation warranty last?
Thirty days is common and too short, because slow failures like output drift take longer than a month to show up. Ninety days is a fair floor for a simple automation. Six months is reasonable for anything touching bookings, money or customer communication. Check what starts the clock too, since delivery date and go-live date can be weeks apart.
Does a warranty cover the AI giving a wrong answer?
Partly. No builder can promise correct output on every possible input, and be sceptical of anyone who does. What should be warranted is the failure behaviour: that when the system is uncertain, it escalates to a person rather than inventing an answer. Get that escalation rule written into the contract as a specific, testable requirement rather than a general assurance.
What is the difference between a warranty and a support agreement?
A warranty looks backwards. It covers defects in work already delivered, at no extra cost, for a fixed period. A support agreement looks forward. It covers monitoring, tuning, changes and new requests, and you pay for it on an ongoing basis. Many contracts blur the two into one vague line, which is exactly where disputes start six months later.
Who is responsible when a third-party tool changes and breaks the automation?
Neither side caused it, so agree on the split in advance. A workable arrangement is that adapting to a vendor change during the warranty period is covered up to a stated number of hours, and anything beyond that is quoted separately. Without that clause, a routine API deprecation turns into an argument about whose problem it is.
What should I do if my automation breaks and the builder has disappeared?
First, check whether you hold the credentials and configuration. If you do, another builder can usually diagnose it within a few hours. If everything lives inside someone else’s private account, you may be rebuilding rather than repairing. This is why handover terms matter more than most people realise at signing time, and why they belong in the contract.
Do I need a warranty if I built the automation myself?
You cannot warrant your own work, but the underlying discipline still applies. Write down what the automation is meant to do, what watches it, what you check weekly, and what you would do first if it stopped. Most self-built automations fail quietly because nobody ever defined what working looks like, so nobody notices when it stops.
About Octavius
Titus Mulquiney is the founder of Octavius AI, where he builds AI brains and AI workforces for founder-led businesses stuck running everything out of their own head. Twenty years in marketing, ex-Sony product manager, ex-GM Zeal NZ. Based in Auckland, working with operators across NZ, Australia, and the US. Connect on LinkedIn.