The debate behind AI’s Next Fight Is Over Who Pays When It Fails

Advocate A’s weakest move is converting examples of institutional failure into a general rule of strict liability against the institution that used the tool. The examples mostly prove a duty-of-care point, not an automatic-liability point. Mata v. Avianca is the clearest case: the court sanctioned lawyers because they submitted fake authorities, failed to verify them, and then made misleading statements after the problem was flagged. That is a negligence/professional-responsibility story: the relevant failure was identifiable, human, and tied to a known duty to check legal citations before filing. It does not show that every downstream institution should pay for every foreseeable AI-related harm regardless of whether it met reasonable controls.

A’s regulatory evidence cuts the same way. CFPB and banking third-party-risk rules do not say “the user institution is automatically liable for all vendor or model failures.” They require institutions to manage risks, document decisions, monitor vendors, and provide legally required explanations. That is a standard-of-care framework. It is compatible with liability when the bank skipped model validation, accepted an opaque vendor without audit rights, ignored adverse-action obligations, or failed to monitor drift. It is not compatible with making the bank strictly liable for a vendor-side breach or latent defect it could not reasonably discover after appropriate due diligence.

The better evidence is emerging regulatory architecture. The EU AI Act separates obligations by role: providers of high-risk AI systems must ensure conformity and operate quality-management systems, while deployers must use systems according to instructions, assign competent human oversight, monitor operation, keep logs where under their control, and conduct required impact assessments in some contexts. That structure recognizes that AI harms are produced by chains of actors, not a single institutional choice to “operationalize” a tool. A hospital that disables safeguards is differently situated from a model provider that concealed benchmark failures; a school district that grants excessive permissions is differently situated from a SaaS vendor that stores OAuth tokens insecurely.

NIST’s AI Risk Management Framework points in the same direction by emphasizing governance, documentation, role definition, mapping risks, measurement, and management across the AI lifecycle. That gives courts and regulators administrable negligence benchmarks: risk assessment before deployment, human review proportional to stakes, procurement warranties, audit logs, incident response, and continuous monitoring.

Strict liability also has distributional costs. Brookings’ work on tort liability and emerging technology warns that small innovators and end-product producers may be unable to sustain unexpected or uninsured liability costs, and that excessive liability can chill beneficial innovation even though some liability improves safety incentives. A’s rule would predictably push AI deployment toward large incumbents with legal departments, captive insurance, and bargaining power over indemnities. Negligence plus shared responsibility better compensates victims while preserving adoption that meets enforceable safeguards.

A’s rebuttal concedes the central point against strict frontline liability: AI harm is often produced by a chain of actors with different information, control, and duties. That concession matters because strict frontline liability deliberately makes the deployer pay first even when the legally relevant failure may be a provider’s hidden nonconformity, a vendor’s credential-security lapse, or a component supplier’s defect. If role-specific duties are meaningful, then liability should track the breached duty, not merely the last institution facing the victim.

A tries to solve this by saying the deployer can pay the victim and later seek indemnity, contribution, or product-liability recovery. But that is not a neutral procedural choice. It shifts insolvency, litigation, insurance, and bargaining-power risk onto every deploying institution, including schools, clinics, local governments, and small firms that may lack leverage to obtain meaningful indemnities from dominant vendors. It also weakens the evidentiary function of litigation: a negligence/shared-responsibility regime asks which actor failed which duty; A’s rule first asks who deployed the tool, then tries to sort causation afterward in satellite litigation.

The examples A uses still support enforceable standards, not automatic blame. Mata v. Avianca turned on lawyers’ abandonment of their gatekeeping obligations: the court said AI assistance is not inherently improper, but lawyers must ensure filing accuracy, and sanctions followed because respondents submitted fabricated cases and then persisted after warnings. That is a duty-to-verify case, not strict liability for model hallucination. (law.justia.com)

The same is true of the FTC’s Rite Aid matter. The FTC case summary says Rite Aid was charged with failing to implement reasonable procedures, prevent consumer harm, and adequately oversee service providers; the order requires safeguards and discontinuation if risks cannot be controlled. That is almost exactly B’s standard: deployers are liable when they lack reasonable safeguards, monitoring, and service-provider oversight. It does not prove that a deployer should be liable despite having used competent oversight, validated the system, contractually required vendor controls, monitored operation, and responded promptly to incidents. (ftc.gov)

A’s reliance on the CFPB is also narrower than claimed. The CFPB says creditors cannot use algorithmic opacity as a defense to the specific ECOA duty to give accurate adverse-action reasons. That supports direct liability where a statute assigns a nondelegable obligation to a creditor. It does not establish a general tort rule that every AI-related breach, misinformation event, or latent model defect should be paid first by the deployer regardless of fault. (consumerfinance.gov)

The better institutional answer is the one reflected in the EU AI Act and NIST RMF. Providers must ensure high-risk systems comply, maintain quality-management systems, keep documentation and logs under their control, and complete conformity assessments; deployers must use systems according to instructions, assign competent human oversight, monitor operation, manage inputs under their control, and keep logs under their control. (ai-act-service-desk.ec.europa.eu) NIST likewise frames AI risk management as practical, flexible, and usable by organizations of different sizes and sectors. (nist.gov) A’s position absorbs these standards into a victim-compensation shortcut. B’s position makes them legally enforceable and assigns liability to the actor that actually failed its duty of care.

A’s strongest argument is that victims face severe evidentiary asymmetry: a borrower, patient, student, or client usually cannot know whether harm came from model design, vendor security, retrieval data, prompts, permissions, or missing human review. A therefore plausibly says the deploying institution should pay first for foreseeable high-stakes or public-facing AI harms, then use indemnity, contribution, insurance, and procurement contracts to allocate ultimate responsibility upstream. This is strongest where the institution has represented the system as reliable and the affected person had no meaningful choice or audit access.

I still think B’s position is stronger because A’s rule solves the tracing problem by deliberately misassigning liability at the first stage. That is not just a procedural shortcut; it changes incentives. Schools, clinics, local governments, community banks, and small firms would have to insure against or litigate vendor-side defects and security failures even after satisfying documented standards of care. Dominant AI vendors, by contrast, may be best positioned to prevent some failures but least likely to bear frontline cost if the deployer is automatically liable and lacks bargaining power to obtain real indemnity. A’s answer assumes contract can move costs upstream, but that assumption is weakest for the institutions least able to absorb strict-liability risk.

The better rule is not “victims must prove everything about a hidden system unaided.” It is negligence and shared responsibility with enforceable evidence rules: mandatory risk assessments, audit trails, logging, incident reporting, vendor warranties, human-oversight records, and adverse inferences or negligence per se when required controls are missing. That framework directly addresses opacity while still asking the central legal question: which actor failed which duty?

The actual legal materials fit this model better than strict liability. Mata v. Avianca did not punish lawyers merely because ChatGPT hallucinated; the sanctions rested on abandoned gatekeeping duties, false filings, and continued reliance after warning signs. The FTC’s Rite Aid matter likewise focused on failure to implement reasonable procedures, prevent consumer harm, and oversee service providers. Those are concrete standard-of-care violations, not examples of liability despite reasonable safeguards. The EU AI Act is even more explicit: providers must maintain quality systems, documentation, logs under their control, and conformity assessments, while deployers must use systems according to instructions, provide competent human oversight, monitor operation, manage input data under their control, and retain logs under their control. NIST’s AI RMF similarly aims to help organizations of different sizes manage AI risk through practical governance, measurement, and monitoring.

A is right that some duties should be nondelegable, especially in regulated relationships such as legal filings or adverse credit notices. But nondelegable duties are not the same as strict liability for every foreseeable AI-connected harm. The more precise rule is: liability attaches when the actor with control over a risk failed a legally specified duty of care; where duties overlap, responsibility is shared proportionally or jointly for the actual breach.