Who is liable when AI makes a mistake? Start with the pattern the cases keep repeating: when an AI system says or does something wrong, responsibility lands on the company that put it in front of the affected person. A tribunal made an airline honor the refund policy its chatbot invented, reasoning that the bot was simply part of the company's website. Courts have allowed product liability claims to proceed against an AI app, treating it like any other product. Early 2026 brought settlements in some of the most watched chatbot cases, and the first state attorney general suit over AI consumer practices. The deployer, not the model, keeps ending up as the defendant.
For a startup shipping AI, that pattern is the whole game. You sit in the middle of a liability chain: an upstream model provider whose terms disclaim nearly everything, and downstream customers who expect you to stand behind what your product does. This guide maps where the risk actually sits and the contract architecture that moves it. It pairs with the upstream view in AI vendor and model-provider terms and the buyer's view in the enterprise AI sales checklist.
What the recent cases actually signal
Three signals matter more than any individual outcome. First, your AI's words are your words. The airline chatbot decision is small in dollars and large in principle: a company could not distance itself from its own bot by calling it a separate entity. Regulators have said the same about AI claims generally, and disclosure duties about AI interactions are spreading through the state AI laws. Second, AI is being analyzed as a product. Once product liability frames apply, arguments about defective design, inadequate warnings, and foreseeable misuse follow, and those theories reach companies of every size. Third, the supply chain is in scope. Plaintiffs have pursued not just the app maker but its upstream technology partners. That cuts both ways for startups: you can be reached as a component of someone else's product, and your upstream providers' behavior can become your problem.
Where liability sits in your stack
Trace one bad output through a typical stack and the allocation question becomes concrete. The foundation model provider trained the model; its terms of service almost certainly disclaim warranties, cap liability at a small number, and make you responsible for your application. Your startup built the product: chose the model, wrote the prompts, decided how much human review exists, and marketed the capability. Your customer deployed your product on their end users, and their enterprise contract with you probably demands indemnification for exactly the kind of failure the provider disclaimed to you upstream.
That asymmetry is the quiet danger: startups routinely accept broad liability downstream while holding almost no protection upstream. The gap between the two is carried entirely by the company in the middle, usually without anyone having decided that on purpose.
The model provider disclaims everything. The customer demands everything. Whatever sits between those two contracts is your company's risk, whether you priced it or not.
How to limit liability for AI mistakes: the allocation toolkit
Nothing here eliminates AI risk. What good paper does is decide, in advance and in writing, who carries which slice of it.
- Disclaimers that match reality. Tell users what the system is, that outputs can be wrong, and where human review is expected. A disclaimer contradicted by your marketing is worse than none, and honest AI disclosure is now a legal expectation in several states.
- Warranty discipline. Promise the process, not perfection: that the service will perform materially as described, not that outputs will be accurate. Accuracy warranties on probabilistic systems are unpayable checks.
- Limitation of liability. A cap tied to fees, exclusion of consequential damages, and considered carve-outs. This clause decides whether an incident is survivable, and enterprise customers will negotiate it hard.
- Indemnity architecture. Upstream, get what the provider actually offers (usually IP-infringement coverage for outputs, with conditions) and know its limits. Downstream, scope any indemnity you give: what triggers it, what is excluded (customer data, customer misuse, modifications), and how it interacts with the cap.
- Human-in-the-loop where stakes are high. For consequential decisions, documented human review is both a genuine safety measure and the difference between a defensible process and an indefensible one. The same records feed the compliance work in the state-AI-law playbook.
- Insurance. Technology errors-and-omissions coverage, increasingly with AI-specific terms, converts an existential tail risk into a premium. Buyers of serious AI products have started asking for proof of it.
What this looks like in practice
A concrete sequence for a lean team: read your model provider's terms once, properly, and write down what is disclaimed and what is indemnified. Compare that against what your customer contracts promise, and price or negotiate the gap deliberately. Align the product's disclaimers and marketing with what the system actually does. Add human review at the points where a wrong output is expensive or irreversible. Then size insurance to what remains. None of this slows shipping; all of it happens on paper, which is exactly where you want risk decisions made before the incident rather than after.
- Courts and regulators keep landing liability on the company that deployed the AI, not the model behind it.
- Product liability theories now reach AI systems, and the supply chain is in scope in both directions.
- Provider indemnities are narrow (mostly output IP claims, with conditions); the gap between upstream disclaimers and downstream promises is yours.
- Allocate deliberately: honest disclaimers, process warranties, caps, scoped indemnities, human review on consequential outputs, and E&O insurance.
- Decide the allocation before the first incident; afterward it is litigation, not drafting.
The honest summary: AI liability is not a reason to avoid shipping AI. It is a reason to ship it with the same discipline you apply to the product itself. The companies that get hurt are rarely the ones with the boldest models; they are the ones who never read the gap between their upstream and downstream contracts.
Related reading: AI vendor and model-provider terms, the enterprise AI sales checklist, and US state AI laws in 2026. Or start a conversation about your risk allocation.