When AI Causes Harm: Product Liability, Tort Exposure, and Insurance Gaps Every Founder Must Understand in 2026

If your startup deploys an AI system that makes a real-world decision — a medical diagnosis, a hiring recommendation, a loan approval, an autonomous driving maneuver — and that decision causes harm, who pays? The answer in 2026 is still being worked out in courtrooms, legislatures, and insurance underwriting rooms. But the direction is clear: founders bear more liability exposure than they realize, their existing insurance may not cover it, and the legal frameworks are converging to make AI-caused harm easier to sue over.

Three developments make this urgent right now. First, the first wave of AI product liability cases is reaching appellate courts — including Tesla Autopilot litigation that tests strict liability and negligence theories against AI-assisted driving systems. Second, state AI laws like Texas TRAIGA (HB 149) and the Colorado AI Act impose duties of care that map directly onto negligence elements, creating regulatory violations that plaintiffs can use as evidence in tort claims. Third, the insurance market is moving aggressively to exclude AI-related harm from standard commercial general liability (CGL) policies — the Insurance Services Office (ISO) has introduced generative AI exclusions, and some carriers are adopting absolute AI exclusions that eliminate coverage entirely. Meanwhile, the EU's proposed AI Liability Directive was withdrawn, but the revised Product Liability Directive now extends strict product liability to software and AI systems explicitly.

This guide covers what founders need to understand: who bears liability when AI causes harm, the tort theories courts are applying to AI, how UCC warranty law intersects with AI outputs, the insurance coverage gap, and how to allocate risk contractually with AI vendors and customers. If you are building or deploying AI in Texas, this is the liability landscape you operate in.

Who Bears Liability: Developer vs. Deployer vs. User

AI liability does not allocate cleanly to a single party. When an AI system causes harm, the legal analysis distributes responsibility across at least three roles: the developer who built the model, the deployer who integrated it into a product or service, and the end user who interacted with the system when the harm occurred.

Texas's TRAIGA codifies these roles. Under Section 552.001, a "developer" is a person who develops an AI system offered, sold, leased, or provided in Texas. A "deployer" is a person who deploys an AI system for use in Texas. Many startups are both — you build models and you serve them to users. Colorado's AI Act similarly distinguishes between developers and deployers, requiring each to exercise reasonable care to protect consumers from known or foreseeable risks of algorithmic discrimination. (Colorado SB 24-205)

The practical implication: if you integrate a third-party AI model into your product, you may face liability for harm caused by that model even if you did not train it. The deployer's duty of care extends to how the system is configured, what data it processes in your environment, what guardrails you implement, and how you monitor its outputs. A developer's liability extends to how the model was trained, what it was designed to do, and whether known failure modes were disclosed. The end user's liability — if any — depends on whether they used the system as intended and whether they had meaningful control over the AI's decision at the moment harm occurred.

For founders, the critical question is not just "will I be sued?" but "which role am I in, and what is my duty in that role?" If you are a deployer, your negligence analysis turns on whether you conducted adequate testing, implemented appropriate guardrails, and monitored for foreseeable harms — not on whether the underlying model was well-trained. If you are a developer, your exposure turns on design decisions, training data choices, and disclosure of known limitations.

Tort Theories Being Applied to AI

Courts are not creating new tort theories for AI. They are applying existing product liability and negligence frameworks to systems that happen to use machine learning. Four theories are emerging as the primary vectors for AI liability.

Negligence

Negligence is the most flexible theory and the one most directly connected to emerging AI regulations. To establish negligence, a plaintiff must show that the defendant owed a duty of care, breached that duty, and caused foreseeable harm. State AI laws are creating statutory duties that plaintiffs can cite as the standard of care. Colorado's AI Act requires deployers of high-risk AI systems to "use reasonable care to protect consumers from known or reasonably foreseeable risks of algorithmic discrimination." (Colorado SB 24-205) Texas's TRAIGA requires that AI systems not be deployed in a manner that intentionally aims to cause harm, infringe constitutional rights, or unlawfully discriminate. (HB 149, Sec. 552.052–552.056)

The NIST AI Risk Management Framework, which TRAIGA adopts as a safe harbor for compliance, provides a structured standard of care that plaintiffs can argue you should have followed. If you did not implement the NIST AI RMF's four functions — Govern, Map, Measure, and Manage — a plaintiff can argue that your failure to adopt a recognized risk management framework is itself evidence of negligence. We cover the NIST safe harbor in detail in our TRAIGA compliance guide for Texas AI startups.

Design Defect

Under the Restatement (Third) of Torts: Products Liability §2, a product is defective in design if the foreseeable risks of harm posed by the product could have been reduced or avoided by the adoption of a reasonable alternative design, and the omission of that alternative design renders the product not reasonably safe. Applied to AI, this theory asks: did a safer alternative design exist — better guardrails, additional testing, human oversight requirements, bias audits — that the developer or deployer failed to adopt?

The Tesla Autopilot litigation illustrates how design defect theories apply to AI-assisted systems. In Tesla, Inc. v. Banner, the Florida District Court of Appeal addressed a case where a driver activated Tesla's Enhanced Autopilot features — Traffic Aware Cruise Control and Autosteer — and the vehicle failed to detect or brake for a tractor-trailer crossing its path, resulting in a fatal collision. The estate sued Tesla for strict liability and negligence, alleging the vehicle "lacked a sufficient crash avoidance system" that other manufacturers had included in less expensive vehicles as early as 2015. The court allowed these claims to proceed, identifying eight similar incidents where Tesla's Autopilot had been engaged but failed to prevent collisions. (Tesla, Inc. v. Banner, Fla. Dist. Ct. App., Feb. 26, 2025)

For AI founders, the design defect theory is dangerous because it asks whether you knew about failure modes and chose not to address them. If your AI system produces biased outputs, hallucinated information, or unsafe recommendations, and you knew or should have known about those risks, a plaintiff can argue the system was defectively designed because feasible alternatives existed — additional testing, content filtering, human-in-the-loop requirements, or deployment restrictions.

Failure to Warn

The failure to warn theory holds a manufacturer liable for not adequately warning users about known or foreseeable risks of using a product. For AI systems, this theory asks: did you disclose the limitations of your AI system to users, customers, or patients? Did you warn about known failure modes, accuracy limitations, bias risks, or scenarios where the AI should not be relied upon?

TRAIGA imposes disclosure obligations for AI systems used in healthcare contexts — requiring providers to disclose AI use to patients not later than the date service is first provided. (HB 149, Sec. 552.051(f)) If your AI system is deployed in healthcare and the provider fails to disclose, both the provider and potentially the system developer face exposure — the provider for failing to warn, and the developer if the system's documentation did not adequately support the provider's disclosure obligation.

Strict Liability for Products

Strict product liability does not require a showing of negligence. If a product is defective and causes harm, the manufacturer is liable regardless of how much care was exercised. The key question for AI is whether an AI system qualifies as a "product" under state product liability statutes.

The EU's revised Product Liability Directive — which now explicitly covers software and AI systems — treats AI outputs as products for strict liability purposes. While the EU's standalone AI Liability Directive was withdrawn, the revised PLD extends strict liability to damage caused by defective products including software, AI systems, and AI-enabled goods. (WCR Legal, "EU AI Liability Directive: What Was It, Why Was It Withdrawn, and What Now Applies?") The European Commission's liability rules page confirms that the product liability framework now explicitly addresses AI. (European Commission, Liability Rules for Artificial Intelligence)

In the United States, whether AI software constitutes a "product" varies by state. Some courts have held that software is a product when it is sold as a standalone good; others have treated software as a service, which does not trigger strict liability. But as AI systems are increasingly embedded in physical products — autonomous vehicles, medical devices, industrial equipment — the product characterization becomes straightforward. The AI is a component of a product, and strict liability attaches to the product as a whole.

How UCC Warranty Law Applies to AI Outputs

Beyond tort law, AI systems implicate the Uniform Commercial Code's warranty framework. Two warranty types are most relevant.

Express warranty arises when a seller makes an affirmation of fact or promise about the goods. If you market your AI system as "95% accurate" or "FDA-cleared for diagnostic use" and it falls short, you have breached an express warranty. Marketing claims about AI capabilities are a primary source of warranty exposure — the FTC has actively pursued "AI washing" cases where companies overstate what their AI can do. We discuss this in our TRAIGA compliance guide, which notes the FTC's "Operation AI Comply" enforcement actions against companies making deceptive AI claims.

Implied warranty of merchantability (UCC § 2-314) requires that goods be fit for the ordinary purposes for which such goods are used. An AI system that produces unreliable, biased, or dangerous outputs may not be merchantable. The challenge for plaintiffs is that UCC warranty law applies to "goods," and software is sometimes characterized as a service rather than a good. But when AI is embedded in a physical product or sold as a licensed software product, the warranty analysis is more likely to apply.

Founders should audit their marketing materials, terms of service, and product documentation for warranty-creating language. Phrases like "guaranteed accurate," "error-free," or "always reliable" create express warranties that your AI system may not be able to satisfy. Disclaimers of implied warranty must be conspicuous and specific — boilerplate disclaimers buried in a terms page may not be sufficient.

The Insurance Coverage Gap

This is where the liability picture becomes most dangerous for founders. Even if you understand your tort exposure, your insurance may not cover it.

The Insurance Services Office (ISO) — the organization that issues standard forms for insurance policies — has introduced new endorsements that insurers may attach to standard CGL policies to exclude coverage for losses "arising out of" generative AI. The ISO endorsements include exclusions for bodily injury, property damage, personal and advertising injury, and products/completed operations hazards that arise out of generative AI. According to analysis published in JD Supra, "even incidental use of AI tools may be sufficient to trigger the exclusion." (Lathrop GPM, "The AI Coverage Gap: What New Insurance Exclusions Mean for Your Business," May 2026)

Beyond the ISO endorsements, many carriers are adopting absolute AI exclusions — particularly in management and professional liability policies including Directors & Officers (D&O), Employment Practices Liability, and E&O coverage. These absolute exclusions disclaim coverage for any claim, loss, or liability based on, arising out of, or attributable to a company's use of artificial intelligence — including content generation, failure to detect AI-generated content, inadequate AI governance, breach of duty relating to AI development or deployment, any product incorporating AI, chatbot statements, AI capability disclosures, and violations of evolving AI-related laws. (Lathrop GPM, May 2026)

Unlike the ISO CGL endorsements, the absolute exclusions are not limited to generative AI — they reach all forms of artificial intelligence. This means a startup that deploys a recommendation engine, a predictive analytics tool, or an automated decision system may find that its D&O and E&O policies exclude coverage for claims arising from that system's operation.

The practical consequence: a founder whose AI system causes harm may face a tort lawsuit with no insurance coverage. Personal assets become exposed. Board members — who already face oversight duties under Delaware's Caremark doctrine as we explain in our board oversight of AI and cybersecurity risk guide — may find that their D&O policies do not cover claims arising from AI-related failures.

What Founders Should Demand From Insurance Brokers

When evaluating insurance coverage, founders should:

• Request the full policy forms, not just the declarations page. AI exclusions are in the endorsements, which are often not shown in summary documents. Ask your broker specifically whether any endorsement excludes AI-related claims.
• Distinguish between generative AI exclusions and absolute AI exclusions. If your policy has a generative AI exclusion but you deploy non-generative machine learning systems, your coverage for those systems may be intact. If the exclusion is absolute, no AI use is covered.
• Negotiate for AI-specific coverage. The market for AI-specific liability insurance is nascent, but some carriers are developing products. Ask your broker whether AI-specific endorsements or standalone policies are available for your risk profile.
• Review E&O and professional liability policies carefully. If you sell AI-enabled products or services, your professional liability policy is more likely to be relevant than your CGL — but it is also where absolute AI exclusions are appearing most aggressively.

Contractual Risk Allocation in AI Vendor and Customer Agreements

Because insurance coverage is contracting while tort exposure is expanding, contractual risk allocation becomes the primary tool for managing AI liability. Every agreement involving an AI system — whether you are the vendor selling the AI or the customer buying it — should address the following provisions.

Indemnification for AI-caused harm. If you are a deployer integrating a third-party AI model, your vendor agreement should require the model developer to indemnify you for claims arising from the model's outputs — including defamation, intellectual property infringement, and harmful recommendations. If you are the developer, you will resist broad indemnification and instead cap liability, exclude consequential damages, and limit indemnification to specific, defined harms.

Warranty disclaimers specific to AI. Standard software warranty disclaimers may not adequately address AI-specific risks. Your terms should disclaim warranties about AI accuracy, bias-free outputs, fitness for particular purposes, and non-infringement of AI-generated content — while complying with applicable consumer protection laws that may override certain disclaimers.

Limitation of liability calibrated to AI risk. Traditional liability caps — typically a multiple of annual contract value — may be inadequate for AI systems that can cause physical harm, reputational damage, or regulatory penalties. Consider separate caps for different categories of harm, with higher caps for bodily injury and regulatory violations.

Audit and testing rights. If you are a deployer, your vendor agreement should give you the right to audit the AI model's performance, request bias testing results, and receive notification of material changes to the model. If you are a developer, you should define what information you will and will not disclose — balancing customer transparency against protection of proprietary methods.

Insurance requirements for AI vendors. Require AI vendors to maintain professional liability and technology errors and omissions coverage that explicitly covers AI-related claims. Given the ISO and absolute exclusion trends, verify that the vendor's policy does not contain an AI exclusion that would void the coverage you are requiring them to maintain.

Actionable Next Steps

1. Map your AI liability surface. Identify every AI system your company develops or deploys. For each, determine whether you are a developer, a deployer, or both under TRAIGA and Colorado's AI Act. Document what each system does, what harm it could plausibly cause, and what guardrails exist. This inventory is the foundation for every other step.
2. Align with NIST AI RMF. TRAIGA's safe harbor for substantial compliance with the NIST AI Risk Management Framework gives you both a compliance defense and a negligence defense. Implementing the Govern, Map, Measure, and Manage functions demonstrates that you exercised reasonable care — which is the core question in any negligence or design defect claim.
3. Audit your insurance policies for AI exclusions. Request the full policy forms from your broker, including all endorsements. Look for ISO generative AI exclusions and absolute AI exclusions. If your coverage excludes AI-related claims, you need to know now — not after a lawsuit is filed. Explore AI-specific coverage options with your broker.
4. Review vendor and customer contracts for AI risk allocation. Every agreement involving an AI system should include indemnification provisions for AI-caused harm, AI-specific warranty disclaimers, liability caps calibrated to AI risk, and insurance requirements that verify the counterparty's coverage is not itself voided by an AI exclusion.
5. Audit marketing materials for warranty-creating language. Remove or qualify claims about AI accuracy, reliability, or capabilities that could create express warranties your system cannot satisfy. The FTC's AI-washing enforcement actions target companies that overstate AI capabilities — and those same statements create warranty exposure in private litigation.
6. Document your testing, monitoring, and disclosure practices. If your AI system causes harm, your best defense is documented evidence that you tested the system for foreseeable risks, monitored its performance, disclosed its limitations to users, and responded to identified issues. This documentation is what distinguishes a company that exercised reasonable care from one that did not.
7. Engage counsel before deployment — not after harm occurs. The cost of a pre-deployment liability assessment is a fraction of what a single product liability claim will cost. If you are deploying AI in Texas, bring counsel into your product roadmap before launch, not after a demand letter arrives.

The legal infrastructure for AI product liability is being built in real time — through cases like Tesla v. Banner, through statutes like TRAIGA and Colorado's AI Act, and through insurance market decisions that are quietly removing coverage. Founders who treat AI liability as a known, manageable risk — by mapping their exposure, aligning with recognized frameworks, auditing their insurance, and contracting carefully — will navigate this landscape. The ones who assume their existing policies and contracts will cover AI-related harm will discover too late that they will not.