For decades, software companies have occupied an unusual position in American product-liability law. A defective automobile, power tool, or children’s toy is unquestionably a product. Software has often been treated differently—as a service, a license, a source of information, or something too intangible for traditional product-liability rules.

Artificial intelligence is putting that distinction under pressure.

The bipartisan AI LEAD Act, introduced by Senators Dick Durbin and Josh Hawley, would declare that artificial-intelligence systems are products and create a federal right to sue when those systems cause harm. The proposal is still only a bill: it was introduced as S. 2937 on September 29, 2025, referred to the Senate Judiciary Committee, and has not passed either chamber.

If enacted, however, its consequences would reach well beyond OpenAI, Anthropic, Google, and the other companies developing frontier models. It could turn AI safety from a largely voluntary engineering practice into a question of evidence, insurance, and survival.

AI would legally become a product

The premise of the bill is straightforward: if companies profit from AI products, they should be responsible when defective systems injure the people who use them.

The official bill text would allow claims against an AI developer based on four familiar product-liability theories:

• The developer failed to use reasonable care in designing the system.
• The developer failed to provide adequate instructions or warnings about foreseeable risks.
• The system failed to conform to an express warranty made by the developer.
• The system was defective and unreasonably dangerous when used—or foreseeably misused—and caused harm.

The fourth theory is the most consequential. It would impose strict liability for a defective and unreasonably dangerous AI product even when its developer exercised all possible care. The injured person would not have to buy the system directly or have a contract with its developer.

That does not mean an AI company would automatically lose whenever its software made a mistake. A claimant would still need to prove a defect, causation, and legally recognized harm. For an ordinary design-defect claim, the claimant would generally also need to identify a reasonable alternative design that could have reduced the foreseeable risk. But the bill would firmly remove the threshold argument that AI is not a product at all.

The definition of harm goes far beyond physical injury

Most people associate product liability with exploding batteries, defective brakes, or contaminated medicine. The AI LEAD Act is much broader. Its definition of harm includes:

• Physical injury, illness, or death
• Damage to property
• Financial loss
• Reputational injury
• Mental anguish, psychological harm, or emotional distress
• Distortion of a person’s behavior that would be highly offensive to a reasonable person

The proposal grew partly from reports of children being harmed after interacting with AI chatbots. The Senate Judiciary Committee’s announcement emphasizes those cases. Yet the statutory language is not limited to children, chatbots, or physical injuries.

An AI-generated financial recommendation, employment evaluation, insurance decision, medical response, cybersecurity action, or legal conclusion could potentially create the type of injury covered by the bill. That makes the proposal relevant to nearly every company putting AI into an operational workflow.

The model company may not be the only developer

One of the bill’s most important provisions is easy to overlook. A developer is not merely the company that trained the original foundation model. The definition includes a person or company that designs, codes, produces, owns, or substantially modifies an AI system for its own use or for others.

The design of an AI product expressly includes:

• Selection of training data
• Training and fine-tuning
• Testing and auditing
• The intended or known characteristics of the system
• Unexpected skills or behaviors that emerge from it

This creates a potentially wide liability chain. A foundation-model provider may develop the base model. Another company may fine-tune it. A software vendor may place it inside an application. An integrator may connect it to business data and automate decisions. A customer may modify its behavior for a specialized workflow.

Depending on the facts, more than one participant could be characterized as a developer.

The bill treats a company that merely deploys or licenses AI more favorably. A deployer generally would not be liable simply because it used the product. It could become liable, however, if it substantially modified the AI, intentionally misused it, or had to stand in for a foreign, insolvent, or otherwise unreachable developer. If the developer and deployer both contributed to the injury, both could face claims.

For small software companies, the practical question will therefore be: At what point does configuring someone else’s AI turn us into the manufacturer of a new AI product?

Terms of service would no longer be enough

AI agreements commonly say that outputs may be inaccurate, users must independently verify them, and the provider accepts little or no responsibility for resulting damage. Those warnings may remain relevant, but the AI LEAD Act would limit the ability to contract away liability.

The bill would make certain contractual terms unenforceable when they waive legal rights, dictate an unreasonable forum or procedure, or unreasonably limit liability under the proposed federal law or applicable state law. It would also permit individuals, classes of individuals, state attorneys general, and the U.S. Attorney General to bring cases in federal court. Available relief could include damages, restitution, injunctions, attorney fees, litigation costs, and government civil penalties.

This would change the commercial negotiation between model providers and application developers. An upstream vendor could no longer assume that a broad disclaimer would end the discussion. Customers, developers, and insurers would instead focus on indemnification, audit rights, data provenance, known limitations, incident reporting, and which company controlled each design decision.

Insurance could become a gatekeeper

The most important effect may occur before anyone files a lawsuit.

Once AI is expressly treated as a product, insurers must decide what evidence they require before accepting the risk. Technology errors-and-omissions and cyber policies may not be enough. Product-liability coverage, exclusions for AI behavior, and disputes over which policy responds could become central parts of underwriting.

Insurers and enterprise customers are likely to ask questions such as:

• What testing was performed before release?
• Which foreseeable harms were evaluated?
• Were safer alternative designs considered and documented?
• What warnings were given to users and deployers?
• How are model, prompt, data, and policy changes versioned?
• Can the company reconstruct the exact system involved in an incident?
• How are abnormal outputs detected, escalated, and corrected?
• Did the application rely on an upstream model whose developer can be sued and can pay a judgment?

These are not merely compliance questions. They are architecture questions.

A company that cannot reproduce its tests, identify the model version used for a decision, or explain why it permitted autonomous action may become difficult to insure. Enterprise buyers may reject it even if its product is technically impressive. Investors may treat undocumented AI liability as a hidden obligation.

The bill could favor the old guard

Product liability can encourage safer engineering, but it also creates fixed costs. Large technology companies can afford specialized counsel, safety teams, model evaluations, insurance programs, and years of litigation. A startup may have an excellent product and still be unable to purchase adequate coverage or withstand one serious lawsuit.

That creates a difficult policy balance. Without meaningful liability, companies can externalize the cost of dangerous systems onto users and the public. With poorly bounded liability, only the largest companies may be able to develop consequential AI products.

The bill’s definition of an AI system makes that concern more serious. It covers software, applications, tools, and data systems using machine-learning algorithms, statistical or symbolic models, or other computational methods—whether dynamic or static. Read literally, that could extend beyond modern generative AI into categories of conventional decision software that have existed for years.

Congress will need to determine whether that breadth is intentional. It will also need to decide how open-source developers, small companies, downstream integrators, professional users, and systems combining several models should be treated.

Engineering records may become courtroom evidence

The AI LEAD Act is not law, and its language may change substantially if it advances. Companies should not reorganize themselves around a bill that remains in committee. But its direction is significant.

The era in which AI safety could be handled primarily through aspirational principles is ending. Courts, regulators, insurers, customers, and investors increasingly want to know who made the consequential design decisions, what risks were understood, and what evidence supports the claim that the system was reasonably safe.

For software organizations, this means architecture and governance are converging. Test results, model cards, risk assessments, change histories, warnings, approval records, and incident logs may become as important as source code. They will help determine whether a company can obtain insurance, close an enterprise sale, defend a lawsuit, or prove that responsibility belongs somewhere else in the AI supply chain.

The defining question may no longer be whether an AI system works. It may be whether its creator can prove that it was responsibly designed when something goes wrong.

---

This article is general business and technology commentary and is not legal advice.