Who Is Liable When Your Automation Makes a Mistake

When an automation makes a costly mistake, the loss almost always lands on you. The vendor's terms disclaim warranties, exclude exactly the kind of damages a broken workflow produces, and cap whatever is left at a number set in the contract rather than by the damage: sometimes a fixed $1,000, sometimes twelve months of what you paid. Meanwhile the regulator, the customer and the counterparty all deal with your company, not the software.

This is not a scandal. It is the standard allocation of risk in American commercial software, and it is disclosed in documents you can read before signing. Here is what four widely used vendors actually publish.

What the terms say

Take OpenAI's Services Agreement, updated 1 December 2025 and effective 1 January 2026, as the fully articulated version. Beyond the "as is" line, the agreement disclaims any "REPRESENTATION, WARRANTY OR GUARANTEE THAT SERVICES WILL MEET CUSTOMER'S REQUIREMENTS OR EXPECTATIONS, THAT CUSTOMER CONTENT WILL BE ACCURATE, THAT DEFECTS WILL BE CORRECTED." The cap reads: "EACH PARTY'S TOTAL LIABILITY UNDER THE AGREEMENT WILL NOT EXCEED THE TOTAL AMOUNT CUSTOMER PAID TO OPENAI DURING THE TWELVE MONTHS IMMEDIATELY PRIOR TO THE EVENT GIVING RISE TO LIABILITY."

Zapier's Terms of Service follow the same architecture: neither party is liable "FOR ANY... INDIRECT, INCIDENTAL, CONSEQUENTIAL, PUNITIVE, SPECIAL... DAMAGES," with the cap set at fees actually paid during the current subscription term.

The two fixed-dollar caps are worth sitting with. Make's published Master Services Agreement, last updated March 2026, which names Celonis, Inc. as the contracting entity, provides an express limited warranty to paying subscribers and then states, at section 9.2, that where an exclusion of liability is prohibited by law, "OUR TOTAL AGGREGATE LIABILITY SHALL NOT EXCEED $1,000.00, WHICH THE PARTIES AGREE IS A FAIR AND REASONABLE AMOUNT." That last clause is not decoration: a contract that stipulates its own cap is reasonable is pre-arguing the question a court would otherwise reach on its own. UiPath's Community Agreement — the free tier, in the version dated 27 July 2026 — says "IN NO EVENT SHALL UIPATH AND ITS AFFILIATES' TOTAL LIABILITY... EXCEED ONE THOUSAND (1,000) USD," after excluding "LOSS OF PROFITS, REPUTATION, USE, OR REVENUE, LOSS OR CORRUPTION OF DATA, OR INTERRUPTION OF BUSINESS."

Negotiated enterprise agreements can and do differ from the published self-serve terms. But the published terms are what governs you unless you signed something else.

The exclusions are the whole story

People fixate on the cap. The exclusion of consequential and indirect damages does more work.

Think about what actually goes wrong when a bot fails. A billing automation double-charges 400 customers: the loss is refunds, chargeback fees, churn and a week of staff time. A sync misfires and overwrites your CRM: the loss is data and the revenue attached to it. A scheduled filing does not run: the loss is a penalty. Every item in that list is lost profit, lost revenue, lost data or business interruption — the exact categories the standard clause excludes.

What is left after the exclusions is direct damages, and for a software subscription the fee itself is most of what that can amount to. Then the cap applies to that. The recovery is small by design.

Why US law lets this stand

Limitation-of-liability clauses between businesses are ordinarily enforceable. The framework behind that is Uniform Commercial Code section 2-719. The UCC is state law, not federal, so what governs you is your own state's enactment of it. As enacted in New York, subsection (3) reads: "Consequential damages may be limited or excluded unless the limitation or exclusion is unconscionable. Limitation of consequential damages for injury to the person in the case of consumer goods is prima facie unconscionable but limitation of damages where the loss is commercial is not."

Read that last clause again. Where the loss is commercial — your business losing money — the limitation is not presumed unconscionable. That is the default the whole SaaS industry is built on.

"Your own state's enactment" is not boilerplate, and one state shows why. Louisiana never adopted UCC Article 2. Its commercial law lives in Title 10 of the Revised Statutes, whose table of contents, read on October 15, 2026, lists 458 sections and not one of them numbered in the 2-series. Sales are governed by the Civil Code instead, under a doctrine called redhibition: article 2520 opens "The seller warrants the buyer against redhibitory defects, or vices, in the thing sold." The article covering the same ground for a sale is article 2548, and it asks a different question. It permits the waiver — "The parties may agree to an exclusion or limitation of the warranty against redhibitory defects" — on conditions the buyer can check: "The terms of the exclusion or limitation must be clear and unambiguous and must be brought to the attention of the buyer." And it adds a limit with no counterpart in the subsection quoted above: "A buyer is not bound by an otherwise effective exclusion or limitation of the warranty when the seller has declared that the thing has a quality that he knew it did not have." New York's test is whether the limitation is unconscionable. Louisiana's starts earlier, with whether it was clear and whether anyone put it in front of you.

Two caveats, both genuinely unsettled at the edges. First, UCC Article 2 governs transactions in goods, and courts have not reached one answer on whether a cloud subscription is a good, a service, or a license; the analysis can differ by state and by contract. Second, subsection (2) provides that "where circumstances cause an exclusive or limited remedy to fail of its essential purpose, remedy may be had as provided in this Act" — and courts disagree about whether a remedy failing its essential purpose also knocks out a separate consequential damages exclusion. If you are in a dispute that turns on either point, that is a question for your attorney and the law of your state, not for a checklist.

Indemnity runs the other way

The same agreements that limit what you can recover also run indemnity the other way, and all four quoted here do it — though not to the same extent. Zapier's terms, in the version effective April 9, 2026, state: "You agree to defend Zapier, its affiliates, directors, officers, employees, and agents ... and indemnify Zapier Indemnified Parties from and against any and all loss, costs, damages, liabilities, and expenses (including reasonable attorneys' fees) arising out of or related to (i) your violation or alleged violation of these Terms, or (ii) Customer Content." Note the case: unlike the warranty disclaimer and the damages cap, which Zapier sets in capitals, this clause is written in ordinary sentence case.

The other three carry the same obligation in different widths. OpenAI's Services Agreement, section 13, has the Customer "agrees to indemnify, defend, and hold OpenAI and its affiliates and licensors harmless" for claims related to use of the services in violation of the agreement, to Customer Applications, or to Customer Content. UiPath's Community Agreement, version 2026.07.27, does it in section 5.3, which opens "Customer agrees to indemnify and defend UiPath, its Affiliates and their respective directors" and goes on to cover non-compliance with the acceptable use and export terms, violations of law or third-party rights, breaches of the customer warranties, and third-party claims involving customer data. Make's Master Service Agreement, last updated March 2026, is the narrow one. Section 12.1(a) says "You shall defend and/or settle, at Your expense, any third-party claim brought against Us or Our Representatives" — but only for claims about User-developed Apps, which the agreement defines as the custom applications a user builds on the platform for other users. If you never publish one, that clause never fires.

The same agreement also assigns you the risk of the connections you build: "If you choose to grant a Third-Party Service any access to your Zapier Account, you are solely responsible for that Third-Party Service having access to your data, including Customer Content." In a multi-app workflow, that is most of the surface area.

Regulators deal with you

Contract terms allocate risk between two companies. They do not bind a regulator or your own customers.

The FTC has made this concrete. In its 2014 case against GMR Transcription Services, the Commission alleged the company "never required the individual typists it hired as contractors to implement security measures, such as installing anti-virus software," after a service provider stored and transmitted files in clear text on a server accessible online without authentication. The settlement required GMR to build a security program covering information "the company provided to independent service providers." The vendor's failure; the client's order.

Where a specific rule applies, the obligation is written down. The FTC's Safeguards Rule, at 16 C.F.R. § 314.4(f), requires covered financial institutions to "select service providers with the skills and experience to maintain appropriate safeguards," to spell out security expectations in the contract, and to periodically reassess them. Choosing badly is itself the violation.

A newer signal points the same way, and it is worth reading carefully because it is not law yet. On July 1, 2026 the FTC published a proposed policy statement on the suppression of accuracy in AI systems, applying Section 5 to companies that market AI. The comment period closed July 31, 2026, and as of October 7, 2026 no final statement has been published. Treat it as a direction of travel, not a rule.

Two things in it are settled doctrine rather than proposal, and those are the ones that touch a buyer. The Commission restates its three-part deception test: "First, there must be a representation, omission or practice that is likely to mislead the consumer"; "Second, we examine the practice from the perspective of a consumer acting reasonably in the circumstances"; and "[t]hird, the representation, omission or practice must be a material one," such that it is "likely to affect the consumer's conduct or decision with regard to a product or service." It also notes that courts "have recognized that the Commission's deception authority requires the entity to substantiate the representation it makes about its products or services with sufficient evidence."

Read that last line as a buyer and then as a seller. If you tell your own customers that an automated process checks something, reviews something, or is monitored by a person, you are making a representation about a product or service — and substantiation is your problem, not your vendor's. The cap in the vendor's contract limits what you can recover from them. It does nothing about what you said downstream.

So where does the risk land

On the business operating the automation, in almost every direction that matters: refunds and remediation to your customers, penalties for missed filings, regulatory exposure for data you were responsible for, breach of your own contracts, and the staff time to unwind it. What you can recover from the vendor is a fraction of that, and it is capped.

Which suggests a short set of habits rather than a legal strategy:

1. Read the cap before you build. If a workflow can create six-figure exposure, do not put it behind a tool whose aggregate liability is $1,000.
2. Gate irreversible actions. Payments, mass sends, deletions and filings should require a human approval step. Approval is cheap; reversal is not.
3. Set volume limits. Most catastrophic automation failures are a small error executed thousands of times. A ceiling on records per run converts a disaster into an incident.
4. Reconcile. A daily check that counts what the automation did against what it should have done finds problems in hours instead of at month end.
5. Keep logs you can export. If you have to prove what happened, you will need them, and the vendor's retention window may be shorter than your problem.
6. Ask your broker about coverage. Technology errors and omissions and cyber policies exist precisely because contractual recovery is limited. Whether your current policy responds to an automation error is a question worth asking before you need the answer.
7. Negotiate when the stakes justify it. Caps, indemnities and security terms are negotiable at contract sizes where a vendor has a sales team.

The Bot Desk publishes information, not legal advice. We are not a law firm, and nothing here creates an attorney-client relationship. Contract terms change, vendors publish different agreements for different plans, and enforceability turns on the law of your state and the facts of your situation — have a qualified attorney review any agreement you are relying on.