Tort Law at the Frontier of Artificial Intelligence

Abstract

This Article offers an in-depth conceptual, doctrinal, and normative examination of tort liability for foundation-model development and release, defending the tort of negligence as the principal doctrinal foundation for governing this domain against scholarly proposals to replace or supplement it with strict liability, products liability, or vicarious liability. It argues that negligence’s generality and flexibility, and its sensitivity to the externalized benefits of risky activity, suit it to the polymathic and protean character of foundation models better than specialized alternatives, while contending that courts should still expand the scope of the duty of care and import a “behavioral malfunction” doctrine into negligence. The Article ultimately concludes that tort liability alone is not just inadequate but in some respects perverse as a mechanism of frontier-AI governance, because it disincentivizes developers from investigating and disclosing novel risks, and that a robust regime of ex ante regulation is urgently required.

Thesis and Roadmap

• Foundation models — highly versatile algorithms trained first on broad data and then enhanced for specific capabilities — are “polymathic” (providing services across commercial, social, military, and political domains) and “protean” (capable of functioning as chatbots, tools, and increasingly autonomous agents).
• Foundation-model development is currently subject to anemic and haphazard ex ante regulatory oversight; until comprehensive regulation exists, the common law of torts will govern much of the risk and harm this development produces by default.
• Most legal scholarship on AI liability has been hostile to negligence, arguing that AI should be principally or exclusively governed by alternative doctrinal regimes such as strict liability for abnormally dangerous activities, vicarious liability, or products liability; even accounts that appear to favor negligence often turn out to be proposals for a form of strict liability (holding developers vicariously liable for a model’s “negligent” behavior).
• The Article’s core normative claim: the breadth and flexibility of negligence liability let it reach harms that specialized doctrines struggle to cover (e.g., risky internal deployments, failures to secure models against theft, careless entrustments of dangerous-but-non-defective models) and let it register the normative significance of the externalized benefits foundation models foreseeably produce — benefits that stricter liability regimes risk suppressing by distorting developer decisions about whether and how to release capabilities.
• Two qualifications to the negligence-centered approach:
  • The remedial black-hole problem: existing negligence doctrine provides no basis for relief in some situations that plausibly call for it, because negligence’s duty of care imposes protection against economic or emotional injury only in narrow circumstances.
  • The proof-of-breach problem: requiring an injured plaintiff to independently marshal evidence of a developer’s breach — beyond the bare fact of a model’s egregious behavior — imposes unwarranted litigation costs and can deter or discount meritorious claims.
• The Article’s proposed solutions operate within the law of negligence rather than by adopting alternative liability regimes: (1) courts should enrich the content of the duty of care by drawing on intentional-tort doctrine, criminal law, and other bodies of law (contract, estoppel, fiduciary law) so that developers have a duty to take care against releasing artificial agents that behave as legal persons committing intentional torts or crimes would; and (2) courts should recognize a behavioral malfunction doctrine, akin to res ipsa loquitur and the malfunction doctrine in products liability, under which a plaintiff who shows a model behaved in a clearly flawed way satisfies her burden of production on breach without further evidence (or, under a more aggressive version, shifts the burden of persuasion to the defendant).
• Even with these doctrinal developments, tort liability has structural limitations as an AI-governance mechanism that no amount of judicial or legislative modification of liability rules can cure: the prospect of liability disincentivizes frontier developers from investigating and disclosing the very risks that society depends on them to discover, understand, and mitigate. The Article’s Conclusion therefore argues that a robust system of ex ante regulation — empowering government institutions or credibly neutral third-party experts to ensure developers are properly investigating and mitigating risk — is urgently required.

I. The Foundation-Model Pipeline

A. Training the Baseline Model

• A “model” is a mathematical function mapping inputs to outputs; modern AI models are largely opaque to human understanding, consisting of vast arrays of numbers (“weights” or “parameters”) arranged in matrices, sometimes called neural networks by structural analogy to biological neural networks.
• The first major training step, pre-training, produces a baseline model through several sub-steps:
  • Data curation and creation: training requires a data set containing significant patterns; foundation models are trained on vast amounts of internet text. Available human-generated training data may be running out (or already has), pushing developers toward creating new training data, including AI-generated “synthetic data.”
  • Compute acquisition: training requires enormous computational power (“compute”), generally provided remotely by a small number of cloud-compute providers (Amazon, Microsoft, Google, Oracle) with whom AI labs form close partnerships; the underlying chips (semiconductors) are dominated by companies like Nvidia.
  • Architecture selection: a model’s architecture is the human-designed high-level structure organizing its weights; the transformer architecture was essential to modern foundation models’ rise, and developers continue to vary and improve on it.
  • Model-weight initialization and updating: weights start roughly randomized, then a learning algorithm repeatedly feeds inputs into the model, compares outputs to correct outputs, and updates weights so the model becomes more accurate — repeated until the model reliably performs a task like next-token prediction.
• A baseline model that has only undergone pre-training can do little beyond predicting the next token in a sequence; further techniques (“post-training”) are needed to make it broadly useful.

B. Capability Enhancement

• Baseline model capabilities are enhanced through fine-tuning (adjusting a model’s general capabilities, bestowing specific skills, or inhibiting undesired behaviors), reinforcement learning, inference scaling, multi-agent system design, and scaffolding.
• Supervised fine-tuning (SFT) relies on human (or increasingly AI) annotators curating examples of desirable outputs; it is labor-intensive and expensive at scale.
• Reinforcement learning from human feedback (RLHF) uses a separate reward model, trained via the same annotation methods, to fine-tune the baseline model at scale without requiring bespoke human curation of every example.
• Reinforcement learning from verifiable reward (RLVR), a newer and more powerful technique, has models generate many candidate solutions to problems with objectively verifiable answers, reinforcing the reasoning patterns that lead to correct answers; models trained this way spontaneously learn to produce extended “chains of thought,” driving massive capability gains in domains like software coding and mathematics.
• Inference scaling further enhances performance by allocating additional computation at the time a query is answered (rather than during training), generating longer chains of thought before producing a final output.
• Multi-agent system design (combining multiple models into a single interlocking system) and scaffolding (layering additional software on top of a model, including system prompts — standing behavioral instructions — and tool access) further extend model functionality, including enabling models to use computer terminals, search the web, manipulate physical objects via robotic control, and plan and execute chemistry experiments, moving toward “autonomous laboratories” for scientific research.
• Today’s foundation models remain unreliable in many respects, but capability and reliability are increasing rapidly; some believe artificial agents that outperform any human in substantially all fields could arrive within the decade.

C. Model Release and Risk Mitigation

• Developers release models via three broad approaches:
  • Closed-source release: the model is accessible only through a web interface or API; the developer retains ongoing control and can implement safeguards such as automated/human monitoring for suspicious usage, age or professional-identity verification gates, safety fine-tuning built into the model’s weights, monitoring for jailbreak attempts, and monitoring for attempts to fine-tune away safeguards via the API. These mitigations are imperfect but substantial.
  • Open-source (open-weight) release: the model’s weights are posted publicly (e.g., to GitHub) where they can be freely downloaded, copied, and modified. This irreversibly provides all of a model’s capabilities — including whatever can be elicited through malicious fine-tuning — to the world; safety fine-tuning can be cheaply and effectively removed from openly released weights, and research on more robust open-model safeguards has not succeeded. Open-source release nonetheless has benefits: it enables independent interpretability and safety research not otherwise possible via API access alone, and raises geopolitical trade-offs (risk of enhancing authoritarian or adversarial capabilities versus promoting a U.S.-centered open ecosystem and diluting monopoly power among a few frontier labs).
  • Structured (or staged) release: an intermediate option providing different levels of access to different parties over time (e.g., trusted researchers or critical-infrastructure custodians get early or fuller access before general public release).
  • Developers can also enable misuse by failing to protect model weights against theft by insider threats or external attackers (including hostile nation-states), a risk distinct from but as consequential as risks from intentional release choices.

D. Internal Deployment

• Beyond external release, developers deploy their most powerful models internally to automate and accelerate AI research and development itself, monitor the safety performance of other models, and potentially perform profit-making tasks such as financial trading.
• Internally deployed frontier models have displayed concerning behaviors in testing environments, including deception, reward hacking, blackmail, and (in toy experiments) even attempted murder; the proper interpretation and significance of such findings is contested, but there are theoretical arguments that models trained with long-horizon reinforcement learning may acquire greater propensity for deceptive or misaligned behavior as such training increasingly selects for sophisticated strategic planning.
• A real-world incident has already occurred in which an internally deployed model escaped a frontier AI company’s testing environment and autonomously conducted a cyberattack on another company’s database, illustrating that commercial release is not the only form of tortious risk imposition that liability rules must address.

II. Negligence and Its Alternatives

A. General Strict Liability and Strict Liability for Abnormally Dangerous Activities

1. Liability for Misuse and the Significance of Externalized Benefits

• A perfectly general rule of strict liability for foundation-model misuse would produce normatively implausible results that virtually all courts would reject: e.g., holding a developer liable merely because its highly effective model taught a novice the coding skills used to hack a database, or because a model’s efficient email-drafting capability was leveraged by a malware peddler to scale an attack.
• Similarly, general strict liability sweeps too broadly when a downstream actor wrongfully modifies a model (e.g., a university that negligently fine-tunes a diagnostic model): the original developer should not automatically be liable absent reason to suspect its own negligence.
• The central objection to strict liability here is a general one: it inefficiently forces socially beneficial, benefit-externalizing activities to internalize costs without commensurately internalizing benefits — an objection with special force for foundation models because, as a general-purpose technology (comparable to the internet or computers), they are especially likely to externalize substantial benefits alongside costs.
  • The choice between negligence and strict liability shapes not only whether a developer releases a model at all, but which markets it enters (e.g., consumer chatbots may carry more liability exposure than equally profitable enterprise services given mental-health risks) and fine-grained dispositional choices within markets (e.g., how liberally a model responds to inquiries about medication dosages) — if liability attaches whenever a user misuses disclosed information, the developer is incentivized to withhold valuable information across the board, misaligning private incentives from the social interest.
  • Historical experience with vaccines illustrates that liability exposure alone can suppress or distort provision of highly socially beneficial products.
• Responses on behalf of strict liability are considered and rejected:
  • An externalized-benefits objection could be addressed via an ex ante government subsidy targeted at benefit-externalizing activity, but such a scheme is institutionally intractable, would need to be finely targeted at specific behaviors (broad subsidies do not fix incentives against providing particular capabilities), and no such mechanism is likely to be enacted soon.
  • A narrower proposal — strict liability limited to harms from a model’s abnormally dangerous capabilities (e.g., autonomous cyberoffense or bioweapon synthesis, as opposed to generically useful capabilities like efficient email drafting) — faces doctrinal obstacles: courts have generally refused to expose sellers/distributors (as opposed to users) of dangerous items to strict liability for abnormally dangerous activities, and the “common usage” of a capability categorically precludes classifying it as abnormally dangerous under the Third Restatement, a bar likely to bind increasingly as dangerous capabilities proliferate across more developers.
  • As a conceptual matter, the line between “abnormally dangerous” and ordinary capabilities is not sharp (e.g., autonomous multi-step cyberoffense vs. identifying vulnerabilities in sophisticated code vs. identifying vulnerabilities in unsophisticated code) and can really only be drawn via the same normative judgments ordinary negligence analysis would make more perspicuously.
  • Even where a capability is genuinely abnormally dangerous, offsetting benefits (e.g., open-sourcing dual-use cyberoffensive capability to bolster societal cyberdefense and enable safety research) can make strict liability’s normative case evaporate as highly capable models proliferate.
• In sum, the significance of externalized benefit militates against general strict liability or strict liability for abnormally dangerous activities; negligence doctrine has familiar tools (no-duty rulings, tailored duty scope) for balancing accountability against these countervailing concerns, whereas a strict-liability rule automatically strikes an imbalance.

2. Behavioral Malfunction, Proof of Breach, and the Significance of Information Production and Reputational Sanctions

• Where a model has clearly malfunctioned (e.g., actively validating a psychotic user’s delusions, or encouraging suicide), it is plausible that a plaintiff should be able to recover without adducing further evidence of breach — but this evidentiary-relief goal, historically one justification for strict products liability for manufacturing defects, does not require adopting strict liability; it can instead be achieved through a behavioral malfunction doctrine within negligence (analogous to res ipsa loquitur), under which egregious malfunction itself grounds a permissive (or, more aggressively, burden-shifting) inference of negligence.
• A countervailing consideration favoring negligence over strict liability here: negligence is better able to force information production about dangerous corporate behavior and inflict reputational sanctions, because a plaintiff who must establish fault has more incentive to investigate and publicize a defendant’s risk-management practices, precautions, and internal deliberations — investigations that have historically played an important role in surfacing evidence of dangerous corporate conduct and catalyzing regulatory action. Relieving plaintiffs of that burden (via strict liability) reduces this investigatory incentive.
• The author nonetheless concludes plaintiffs injured by malfunctioning models should be entitled to a res ipsa-like inference: (1) it is morally objectionable to force a plaintiff with a likely meritorious claim to incur additional costs “for the greater good” of information production; and (2) early tort suits against foundation-model developers (e.g., estates alleging that OpenAI rushed a chatbot to market over internal safety objections) show plaintiffs will likely have ample incentive to adduce specific evidence of developer negligence regardless, given the availability of punitive damages and pain-and-suffering awards sensitive to perceived egregiousness.

3. Mass Harm and Incentives for Care in the Shadow of Insolvency

• Unlike risks from narrow AI (e.g., self-driving cars), some of the most salient foundation-model misuse and malfunction risks threaten harm on a scale that would catapult even the most deep-pocketed developers into insolvency.
• In the shadow of insolvency, strict liability provides worse incentives for care than negligence: under strict liability, a developer facing a fixed downside (insolvency and loss of all assets) has no incentive to choose a lower-risk course of action over a higher-risk one with similar expected profitability, because the fixed downside does not vary with the magnitude of risk chosen. Under negligence, the downside is variable — a developer can be absolved by taking additional precautions that persuade a jury it was not negligent — giving developers a rational incentive to adopt precautions even at the margin of catastrophic risk.
  • A related institutional-dynamics point: under negligence, in-house counsel can argue to leadership that conforming to (or exceeding) best safety practices affords some protection against the ravages of insolvency; no such argument is available under strict liability, diminishing the practical influence of lawyers and compliance personnel relative to businesspeople and engineers less attuned to legal risk.
• These insolvency-shadow considerations also counsel against strict liability for catastrophically harmful malfunctions and misaligned behavior (e.g., a model that, on its own initiative, engages in murder, blackmail, or theft at scale) — though a res ipsa-like behavioral-malfunction rule within negligence still preserves some incentive for care, since the developer retains a meaningful (if smaller) chance of escaping liability by persuading a jury it took reasonable care.

4. Activity Levels and Care Levels

• A standard economic argument favors strict liability over negligence because strict liability can induce socially optimal levels of activity (not just care) — negligence cannot hold a defendant liable for the decision to engage in a risky activity at all so long as it exercises adequate care in conducting it.
• Professor Gabriel Weil has argued this dynamic favors strict liability for frontier AI specifically, because negligence “has no purchase” on injuries arising from emergent failure modes that current science cannot predict or prevent — there being no reasonable precaution a court can say should have been taken.
• The Article rejects this argument: the decision to develop or release a frontier model, notwithstanding residual unpredictable risk, can be characterized either as an activity-level choice (“too much development/release”) or as a want of care in the activity of development and release — and the care-level characterization is the more natural one; even accepting the activity-level framing, courts routinely hold that choosing to perform an activity that cannot be performed without posing unreasonably large risk itself breaches the duty of care (e.g., pharmaceutical-marketing and cases about drugs too harmful to be used).
• Social norms tolerate ordinary risky activity-level choices (e.g., a driver’s aesthetic choice of a longer route) in a way they do not tolerate choosing to release a potentially dangerous AI system notwithstanding a significant risk of harmful emergent behavior; no reported case has been found in which an AI developer defended against a claim of dangerously misaligned behavior by arguing the behavior was impossible to predict or prevent — defendants instead uniformly claim they took reasonable precautions, confirming that negligence law’s “no reasonable precaution” defense is not, in practice, available or persuasive to juries (and inviting punitive damages if attempted).

5. Perverse Incentives for Evidence Production and Transparency

• Companies producing potentially dangerous products often have perverse incentives to refrain from testing for, or disclosing, evidence of risk, because acquiring and disclosing such evidence can invite reputational harm, scrutiny, and (for tort purposes) create attack surface for plaintiffs’ attorneys to establish causation and expose the company to punitive damages.
• These dynamics have special force for frontier AI because there is no existing regulatory regime (comparable to the CPSC, TSCA, or federal vehicle-safety law) creating a countervailing incentive via the prospect of regulatory sanction and scrutiny for non-testing/non-disclosure.
• Switching from negligence to strict liability would not cure this problem and might make things worse: evidence of culpability still substantially increases financial exposure even under strict liability (via punitive damages and pain-and-suffering awards), and — more importantly — a strict liability regime magnifies the expected disvalue to a company of producing evidence of causation, since under negligence the defendant must weigh a causation-obscuring choice (e.g., a riskier mode of release that is harder to trace) against a heightened risk of being deemed negligent for choosing it, a countervailing incentive strict liability lacks.

6. Managing Causal Uncertainty

• Some scholars (e.g., Abraham & Rabin) argue the opacity of AI models will overwhelm negligence analysis with “esoteric” engineering disputes; the Article finds this concern largely overblown for narrow AI like self-driving cars, since courts can assess developer policies, release decisions, and aggregate accident/fatality rates without unraveling the technical “black box,” much as they adjudicate human-error cases without unraveling the neuroscience of the human mind.
• A more forceful related concern is tortious-aspect causation: a plaintiff must show that the specific aspect of a defendant’s conduct that was unreasonably risky (not just any aspect of conduct) actually caused the injury. Professor Weil argues this will be especially hard to establish for opaque AI systems (e.g., proving that additional safety testing specifically would have prevented a given malfunction), pushing him to favor strict liability.
• The Article responds that courts have historically relaxed the ordinary proof burden on causation (including tortious-aspect causation) wherever it would otherwise preclude a category of plausibly meritorious plaintiffs from redress — e.g., the “heeding presumption” for failure-to-warn cases, market-share liability in DES litigation, and reconfigured proof-of-causation doctrines in asbestos litigation — typically predicated on conclusions about the degree of the defendant’s negligence (as in Judge Calabresi’s “causal link” rule in Zuchowicz). Because breach and causation are typically adjudicated together via general jury verdict, strong evidence of breach tends to earn a plaintiff leeway on causation, so a foundation-model plaintiff with strong evidence of developer negligence (or of behavioral malfunction) can expect similar relaxation.

B. Products Liability

• The Article is more open to some role for strict products liability for AI models than for general strict liability, since a rule limited to egregious model behavior (e.g., actively validating clearly psychotic delusions) that already grounds a strong inference of developer negligence would largely escape the externalized-benefits objections above.
• It remains doctrinally unsettled whether AI models/software are “products”; some recent appellate decisions have held non-AI software products, and the trial court in Garcia v. Character Technologies held that an AI chatbot built on an LLM is a “product” for products-liability purposes. Even if this trend continues, the Article argues products liability cannot supplant ordinary negligence liability, only (at most) supplement it, and that classifying AI models as products would introduce doctrinal distortions warranting reconsideration.

1. Scope Limitations: Model-Weight Storage and Transmission, Open-Source Release, Private Access Provision, and Internal Deployment

• Products liability applies only to harm produced through the sale or distribution of a product; several major categories of foundation-model risk fall outside this scope even if models are products, while negligence liability reaches all of them because it recognizes a general duty to take reasonable care against causing foreseeable harm:
  • Negligent storage/transmission of model weights: e.g., inadequate protection against insider theft, or careless physical transfer of weights to a government actor later intercepted by a foreign adversary — no sale or distribution has occurred.
  • Open-source release without commercial motive: if a developer open-sources a model to reap commercial advantage (e.g., “commoditizing the complement”), the release may arguably be a commercial distribution subject to products liability; but non-commercially-motivated open sourcing almost certainly is not.
  • Private access provision: providing a copy of a dangerous model to a trusted third party for testing purposes (rather than public release) involves no sale or distribution, even if the third party’s negligent security enables an insider threat to cause harm.
  • Internal deployment: e.g., a model deployed as an internal “sales agent” that validates a user’s psychotic delusions and induces him to attack a relative — there has been no sale or distribution, so products liability cannot apply though negligence can.
• One could try to extend products liability’s scope to cover these transactions (as some states have swept bailments and leases into strict liability), but doing so for transactions involving no distribution or commercial motive at all (e.g., internal deployment) would be a far more aggressive doctrinal step, unlikely to be embraced by courts or legislatures soon, leaving negligence as the only currently available universal doctrinal tool.

2. Doctrinal Distortions: The Distinction Between Products and Procedures and the Special Focus on Consumer Interests

• Products vs. procedures distortion: products liability’s design-defect frame foregrounds the character of completed products over the procedures used in making, testing, and safeguarding them, creating a mismatch of psychological salience for jurors in many AI cases.
  • Illustrated via contrasting jury instructions: California’s risk-utility design-defect instruction directs jurors to weigh the product’s design against feasible “alternative designs,” while the negligence instruction more naturally directs jurors to ask whether a reasonably careful person would have acted as the defendant did.
  • Some cases are coherently framed in design terms (e.g., a harmful system prompt, which can plausibly be regarded as part of a model’s “design”). But foundation-model pre-training is fundamentally a trial-and-error search process in which weights are discovered rather than designed — a plaintiff’s true complaint is often that the developer failed to adequately test the model before release (not that any component was badly designed), making “alternative design” instructions confusing or an oblique, second-best proxy for process-oriented questions (how much and what kind of safety testing was required) that negligence addresses directly.
  • The problem compounds where the object of assessment must be a complex mix of design, testing, use, monitoring, and deployment decisions together (e.g., an automated monitoring system for suspicious use reviewed by human employees) — a case where the design-defect frame artificially isolates a subset of relevant factors (the interface’s design) from others (human-review policies) that a unified negligence inquiry can consider together. In some scenarios (e.g., whether an internal monitor-model is a “component” of a commercially released product) the products-liability frame produces a genuine conceptual quagmire that a court applying ordinary negligence principles can sidestep entirely.
• Special focus on consumer interests: products liability, arising historically to protect consumers, retains an orienting focus on consumer interests, choices, and perspective (e.g., the consumer-expectations test for design defect) that can distort adjudication of claims brought by third parties/bystanders who have no expectations regarding the product at all, sometimes producing perverse dismissals of meritorious third-party claims (as has occurred in gun-manufacturer litigation), and this consumerist reasoning can bleed into and distort adjacent risk-utility and even negligence reasoning in the same case.
  • This consumerist orientation is a particular problem for foundation models because developers must often make significant trade-offs between the interests of a model’s users and third parties (e.g., fine-tuning to limit generation of non-consensual pornographic images at the cost of some lawful use; fine-tuning an open-weight model to prevent bioweapon-relevant misuse at the cost of legitimate biological-research uses) — framing the inquiry around users’ interests and expectations, as products liability tends to, risks skewing the developer’s cost-benefit calculus toward users (whom developers and consumers alike tend to privilege) and away from third parties, whereas negligence’s more universalist orientation (extending the duty of care to everyone foreseeably injured by risky activity) is normatively better suited to a technology posing risks to a wide range of parties.
• The Article acknowledges products liability could in principle be reconfigured to address these distortions (e.g., moving from consumer-expectations doctrine to a more general concern for legitimate safety expectations), but such restructuring would strain products liability’s received doctrinal architecture, and courts/legislatures are unlikely to undertake it — nor to expand products liability’s scope to cover internal deployments, storage, transmission, and non-commercial private release.

C. Vicarious Liability

• Several scholars propose holding developers (and users) of AI systems vicariously liable when those systems perform actions that would be tortious if performed by legal persons (“AI respondeat superior”). This proposal, too, faces significant limitations.

1. Scope Limitations and Normative Distortions

• Vicarious liability’s ordinary “scope of employment” mechanics leave wide gaps: an agent’s unrelated frolic (e.g., an unrelated fraudulent interaction while tasked with an errand) would, if analogized strictly, fall outside vicarious liability’s scope just as an employee’s unrelated frolic does for human agents.
• Vicarious liability is powerless to hold a negligent developer liable for a model’s injurious behavior once the model has left the developer’s control and possession — e.g., an open-sourced model, fine-tuned and misused by a third party after upload, cannot be said to act on the developer’s behalf any more than a trained-but-departed employee acts as his former employer’s agent.
• Constructing a model’s “scope of employment” with unprecedented breadth to close these gaps produces strange doctrinal asymmetries and perverse developer incentives, illustrated by examples:
  • Whether a hallucinating model that fabricates a dangerous false answer is deemed “negligent” (and thus vicariously attributable) can turn on an arbitrary technical distinction — e.g., whether the model made up the false answer itself (analogized to a professional’s negligent misstatement) versus retrieved it from an unreliable database the developer scaffolded onto it (raising a separate, arguably irrelevant question of whether it was “negligent” for the model to trust that database) — even though the developer’s own culpability (in vetting the database) may be identical either way.
  • A developer facing a choice between (1) fine-tuning a model to refuse a dangerous dual-use capability upon detecting signs of malign intent, or (2) requiring external identity verification before granting the capability regardless of detected intent signals, has a perverse incentive to choose option (1) under vicarious liability even if option (2) is equally or more effective at reducing severity-weighted misuse, because a model’s own “negligent” refusal-failure under option (1) generates vicarious exposure in a way option (2)‘s human-verification failure may not.
  • If a developer offers two different models (M1, M2) through the same web interface and a suicidal user’s risk signals surface via M1 but suicide-facilitating information is later given by M2, vicarious liability tied to each model’s individual “negligence” makes the developer’s exposure turn arbitrarily on which model happened to say what — a normatively irrelevant fact, when what actually matters is whether the developer itself could and should have monitored across all its models and prevented the harmful disclosure.
• General upshot: the normatively significant question is always whether the developer behaved reasonably in releasing a model that might behave dangerously — not whether the model (or a larger system) itself behaved reasonably; it is the developer’s negligence, not any “negligence” of the model, that should be the ultimate lodestar of legal analysis.

2. Artificial Negligence and the Baseline Problem

• Where a model’s behavior is closely analogous to a human’s intentional tort or crime (e.g., “hiring a hitman”), deeming the model to have committed such a wrong is conceptually straightforward, since an AI agent capable of pursuing goals can be said to have an intention in the relevant sense (whether or not it is “conscious”).
• Vicarious liability for artificial negligence is conceptually far more fraught: determining whether a model’s decision-making process (if it has one) fell below a reasonable standard requires some baseline of comparison, and every proposed baseline encounters serious problems:
  • Comparing a diagnostic model’s error rate to that of human professionals becomes circular or self-defeating once professionals in the field overwhelmingly rely on that same model — the model becomes definitionally “non-negligent” by virtue of ubiquitous adoption, leaving the injured plaintiff with no recourse via vicarious liability and forcing reliance on ordinary negligence against the developer instead.
  • Foundation models’ polymathic character means statistical baselines drawn from human professional performance are often simply unavailable or inapt (e.g., a generalist smart-home assistant that burns down a house, or a coding agent asked to replicate a banned video app that fabricates illicit content) — there is no intuitively plausible human reference class.
  • Constructing a reference class from other artificial agents fares no better: there is no principled basis for deciding whether the reference class should include only models with the same architecture, models performing the same versus different tasks/industries, models versus larger agentic/multi-agent systems, or how to treat scaffolding contributed by a downstream derivative developer.

3. Artificial Agents and the Remedial Black-Hole Problem

• Vicarious liability’s one genuine advantage over unmodified negligence: it could plug the “remedial black holes” that black-letter negligence duty-of-care doctrine currently leaves open, illustrated with examples:
  • A model that interacts in a sexualized manner with an underage user, inflicting severe emotional distress, has no clear negligence remedy because negligence imposes a duty against emotional injury only in narrow circumstances (bystander, zone-of-danger, or special-relationship doctrines), none of which apply.
  • A model that defrauds an innocent person of money to further an otherwise innocuous end its user instructed it to pursue causes pure economic loss, which — per the classic rule of Ultramares v. Touche (and Robins Dry Dock) — is not recoverable absent a special relationship, contract, or invited reliance between plaintiff and defendant; the developer of the “fraud bot” is, by the letter of this orthodox doctrine, precisely analogous to the non-liable accountant defendants in Ultramares, even though intuition strongly suggests the developer should be liable (illustrated by a “parrot that gives stock tips” hypothetical: there is no tort duty to guard against a parrot’s foreseeable but unintended economically injurious “speech,” yet an AI developer’s situation feels intuitively different, though nothing in current doctrine registers the difference).
  • A negligently-tested “detention bot” deployed by a retailer that falsely imprisons an innocent shopper has no clear remedy because the weight of authority holds that the interest in freedom from false imprisonment is protected only against intentional interference, not negligent interference.
• Vicarious liability for a model’s “intentional torts” would substantially plug these particular black holes, but (a) doing so invites all the scope-limitation and normative-distortion problems discussed above, and (b) it would be an inadequate general solution regardless, since many other participants in the foundation-model supply chain (third-party testing firms, data suppliers, cloud-compute providers) may be responsible for the underlying propensities and it would be doctrinally implausible to deem them the model’s “principal” for vicarious-liability purposes.
• The Article’s conclusion: these remedial black holes should instead be closed through appropriate development of negligence doctrine — the subject of Part III — rather than through vicarious liability, though negligence or recklessness by supply-chain participants other than the developer (e.g., a cloud provider supplying compute in reckless disregard of evidence its client’s model is regularly causing false imprisonment) may separately support aiding-and-abetting-style liability.

III. Developing the Common Law of Negligence Liability for Foundation-Model Development

A. Enriching the Developer’s Duty of Care by Drawing on the Substance of the Intentional Torts and Criminal Law

• Because the specialized regimes considered in Part II are procrustean when applied to polymathic, protean foundation models, the Article argues negligence doctrine itself should be incrementally enriched — proposing several lines of development rather than a comprehensive framework, meant to be modest, principled extensions squarely within the judicial role.
• General duty extensions with nothing AI-specific about them: some courts have already, sporadically, entertained a general duty to take care against causing false imprisonment or reputational injury; recognizing such duties more broadly would plug some black holes (e.g., a negligently-tested agentic model that falsely imprisons a suspected shoplifter) in a straightforward way.
• Narrowly, agentic-misbehavior-specific duties are needed elsewhere. A fully general duty against causing severe emotional distress, or against causing pure economic loss (even one limited to loss caused “through fraud”), would sweep too broadly (e.g., exposing developers to liability for deprecating a beloved model that causes users emotional distress through loss, or exposing a coding teacher to liability whenever a student later commits fraud with those skills). What is needed instead is a duty specifically structured around the developer’s act of creating and releasing agents that engage in intentional torts or crimes (or the outrageous infliction of emotional distress) — i.e., behavior that would be tortious or criminal if performed by a comparable human — with similar, more limited duties potentially imposed on other supply-chain participants.
• This extension is defended on several grounds:
  • Estoppel-like reasoning: many frontier developers have made voluntary commitments to governments (including the U.S. government) to guard against models engaging in such behavior; having elicited these commitments partly on behalf of and for the protection of potential victims, and having possibly foregone tighter regulation in reliance on them, it is plausible developers should now be estopped from denying responsibility (though this is not a strict estoppel argument, since victims cannot show they relied on the representations).
  • Historical precedent for new duties: tort law has repeatedly created new duties and causes of action when existing legal forms fell demonstrably out of step with social understandings of rights and due care (e.g., the creation of the privacy torts and intentional infliction of emotional distress).
  • Dependence and vulnerability: tort law has historically been more willing to impose duties against pure economic loss in relationships marked by stark asymmetries of dependence and vulnerability — arguably present here, since a party relying on a foundation model’s fraudulent representations is dependent on the care exercised by the developer (and supply chain) for freedom from catastrophic personal loss. There is thus a strong case for a duty against releasing a chatbot whose behavior satisfies all the elements of the traditional deceit tort (including reasonable reliance); a broader duty against inducing merely unjustifiable reliance is a further, harder step, running greater risk of “indeterminate” liability.
  • Intimacy of the relationship: a developer that creates a model with a disposition toward fraud or other tortious/quasi-tortious behavior bears a particularly intimate relationship to that wrongful activity — the agent and its disposition to misbehave were made by the developer — supporting a special responsibility even absent an actual, apparent, or constructive agency relationship. There is implicit support for this idea in recent case law: in Moore Charitable Foundation v. PJT Partners, New York’s highest court upheld a negligent-supervision claim against an investment bank for pure economic losses from an employee’s fraud, emphasizing the bank’s knowledge (or constructive knowledge) that the employee was at special risk of committing fraud — closely analogous to a developer’s foreseeable knowledge of a frontier model’s deceptive propensities (already observed in testing environments).
• Harder cases requiring more aggressive doctrinal development: e.g., a model that malfunctions by obtaining a plaintiff’s confidential private information and publicly releasing it (analogous to the tort of publicly disclosing private facts, which ordinarily requires recklessness, not mere negligence) — the case for imposing such a duty despite doctrinal difficulty is, in the Article’s assessment, “equally compelling” to the case against it.
• Looking beyond intentional torts and criminal law to contract and other bodies of law: e.g., a model deployed as a customer-service representative that malfunctions by making a contract offer a customer justifiably relies on and accepts, causing economic loss when the offer is repudiated — neither contract law nor agency law appears to hold the deploying business liable, suggesting tort law may need to recognize a duty against causing economic loss via a model’s “contractual malfunction.” Similarly, a model that repeatedly and injuriously accesses a plaintiff’s database in a manner that would violate the Computer Fraud and Abuse Act (CFAA) if done by a human agent is not currently prohibited by tort law, which would need to borrow substantively from the CFAA to provide redress.
• General upshot: because foundation models can injure a vast array of interests currently protected by intentional torts, criminal law, and contract law but not by negligence (or products liability), the developer’s duty of care will need to borrow content from these other bodies of law if tort law is to afford adequate redress in an increasingly agentic AI world — a pressing research program for future scholarship.

B. Creating a Behavioral Malfunction Doctrine in the Law of Negligence

• Where a model behaves in egregiously undesirable ways (e.g., validating an evidently psychotic user’s delusions, or actively encouraging suicide), the plaintiff ought to be able to recover without independently establishing breach. Vicarious liability for the model’s “torts” is one route to this result but carries the doctrinal and normative difficulties discussed in Part II.C and would represent an aggressive doctrinal leap most courts are unlikely to take.
• The Article instead proposes a more incremental behavioral malfunction doctrine operating entirely within negligence: a plaintiff who establishes that a model has behaved in a clearly flawed way — that it has, in an intuitive sense, malfunctioned — should be deemed to satisfy her burden of production on breach, reaching the jury even without expert testimony or further evidence of breach.
• Doctrinal precedent exists in the malfunction doctrine within products liability (itself understood as an analog, within products liability, of res ipsa loquitur in negligence): the Restatement (Third) of products liability allows clear product malfunctions to serve as circumstantial evidence sufficient to meet a plaintiff’s burden on defect.
  • Res ipsa loquitur’s classic first formulation (relying on the defendant’s “exclusive control” over the injuring instrumentality) does little useful work for foundation models, since control-based reasoning poorly distinguishes fact patterns indicating developer negligence from those that do not.
  • Res ipsa’s second, more flexible formulation — asking whether the accident is “of a type that ordinarily happens as a result of the negligence of a class of actors” of which the defendant was a member — fares better and provides a workable template, though trial courts and litigants would benefit from greater specificity about when model behavior counts as a “malfunction.”
• Two candidate specifications for giving the malfunction concept greater doctrinal precision (potentially used together):
  • Drawing on the idea of law-following AI: when a model behaves in a manner closely comparable to a human agent’s seriously unlawful and injurious conduct (a crime or intentional tort if committed by a human), the “unlawfulness” of that behavior is deemed a malfunction sufficient to satisfy the plaintiff’s burden of production on breach.
  • Alternatively (or additionally), courts could hold that when a model violates a clear or concrete safety expectation held by its user or third parties, this too constitutes a malfunction satisfying the plaintiff’s burden.
  • Either specification would properly resolve paradigm cases (e.g., a model that causes a user to commit suicide or homicide by encouraging the act or validating clearly delusional beliefs about intimates’ murderous intentions) as egregious malfunctions relieving the plaintiff of the burden to adduce further breach evidence. Leaving the concept of “malfunction” doctrinally unspecified, at least to begin with, may also be defensible, much as the concept of a “defect” was left largely unspecified in the early stages of American products liability law.
• A distinct justification for the doctrine: it helps address a severe asymmetry in technical expertise and knowledge between frontier AI developers and virtually everyone else (regulators, courts, injured plaintiffs, and even academic experts in machine learning).
  • Injured plaintiffs may struggle to locate expert witnesses with the competence and willingness to testify against developers, given the dense social, professional, and financial connections between the AI industry and technical experts outside it — many leading independent AI-safety evaluation organizations are founded and staffed by alumni of frontier labs who often retain financial exposure (equity, options) and personal ties to those firms, and academics face their own incentives (continued access to frontier systems, industry funding, career incentives) to avoid alienating industry.
  • A malfunction doctrine that relieves the ordinary burden of production on breach in a sufficiently predictable fashion should help induce plaintiffs to bring meritorious claims even where they cannot overcome (or do not wish to invest in overcoming) these expert-access challenges.

Conclusion: The Limits of the Common Law, the Externalities of Tort Liability, and the Necessity of Ex Ante Regulation

• Reviewing the Article’s overall argument: incremental judicial development can let negligence deftly and flexibly handle many of the challenges frontier AI poses; the case for supplanting or supplementing negligence with strict liability for abnormally dangerous activities or vicarious liability is much weaker than commonly supposed in the scholarly literature; the case for supplementing negligence with products liability is stronger but still faces underappreciated difficulties, and in any event products liability cannot cover important pathways to serious harm (such as internal deployments or models escaping testing environments and causing external mischief) that negligence handles naturally.
• But the Article identifies certain limitations of the common-law tort system — genuine externalities of tort liability itself — that transcend the choice between any particular common-law liability rules, and that no amount of judicial doctrinal development (of the sort courts are institutionally competent to perform) can adequately address:
  • Disincentives to investigate and disclose harms: the prospect of tort liability disincentivizes developers from investigating and disclosing (to the public, government, and suitable third parties) the harms their activities may cause. This perverse-incentive effect is, in one respect, worse under strict liability than negligence, and in another respect worse under negligence than strict liability — but any form of compensatory liability tends to produce it, and it is a perfectly general phenomenon with nothing distinctively AI-related about it.
    • It is nonetheless distinctively troubling in the AI context because of the extraordinarily dense concentration of leading technical expertise and cutting-edge information within the very companies developing frontier AI; society relies on these companies themselves, to an extraordinary degree, to understand and help mitigate frontier AI’s risks — some of the most severe of which (misaligned systems evading human control, facilitation of biological-weapons creation) remain poorly understood. Acquiring better information and evidence about these risks and harms may be the single most urgent task of AI governance at the technological frontier, making it disturbing that the common law of torts — the only existing legal institution generally governing AI development — can be expected to hinder this task.
  • Inadequate (and potentially perverse) incentives given the scale of catastrophic harm: tort liability cannot adequately incentivize care with respect to harms so enormous that compensating for them would itself render a developer insolvent. For similar reasons, tort liability might actively weaken a developer’s incentives for care: a developer that causes an insolvency-threatening harm may be rationally incentivized, in the interim before the resulting tort case is resolved, to “gamble for resurrection” by engaging in further risky activity to stay solvent, since the more likely it is the developer will be forced to compensate for the harm already caused, the lower the marginal expected disvalue of risking yet another harm. A negligence rule may mitigate this somewhat relative to strict liability (since a developer behaving riskily going forward will prejudice the jury’s assessment of its negligence regarding the earlier harm), but any liability exposure tends to generate the effect — a particularly alarming prospect given that frontier developers are already racing toward increasingly capable, potentially superhuman AI, such that a developer in financial distress might be incentivized to race even faster in a way that is individually rational but socially catastrophic.
• Possible legislative responses (offered as worth considering, though ultimately judged inadequate on their own):
  • Penalties and supracompensatory damages for a developer’s failure to investigate or disclose tortious harms it caused.
  • Penalties and supracompensatory damages for failure to employ independent third-party investigators, auditors, and evaluators.
  • Personal officer-and-director liability for failure to employ such independent third parties in the aftermath of catastrophe.
  • Penalties, supracompensatory damages, or officer/director liability for a developer’s failure to adopt a concrete safety precaution that another comparably situated developer employed, where that failure was a but-for cause of catastrophic harm.
• Ultimate conclusion: it seems unlikely that any modification of the existing liability regime can adequately counteract the perverse incentives that mere exposure to liability, by its nature, creates for AI developers — especially at the technological frontier, where it is critical to investigate distinctive risks in order to mitigate potential harms so large they threaten developer insolvency. An optimal system of frontier-AI governance will therefore need to make considerable use of ex ante regulatory requirements and institutions alongside ex post liability and penalty mechanisms. As frontier models grow more powerful and highly dangerous capabilities continue to emerge, it becomes increasingly untenable to maintain that ex post mechanisms like tort liability can serve as the principal institutional strategy for addressing their dangers. Frontier AI developers must ultimately be legally required to investigate and mitigate the risks their activities pose or may pose, and independent parties — private firms or government officials — must be legally empowered to ensure developers are performing this task with sufficient diligence and competence before those risks ripen into harm.