Who is liable when an AI system causes harm, or an agent acts?

What California changed

California AB 316, Chapter 672, in effect since January 1, 2026, bars a defendant who developed, modified, or used an AI system from asserting that the system autonomously caused the harm. Civil Code § 1714.46(c) keeps other affirmative defenses and evidence relevant to causation, foreseeability, and comparative fault available. The remaining liability analysis depends on the applicable law and facts.

Its definition is worth noticing. AB 316 reaches a system that can "infer from the input it receives how to generate outputs," the same functional test the EU AI Act uses in Article 3(1). Two jurisdictions with little in common arrived at the same line independently, and the line is whether a system infers, whatever it is built from. More on that line in what people mean by AI.

Developer or operator

Two models for allocating responsibility are in play, and they place the exposure differently.

• Developer liability. Responsibility runs to whoever designed and trained the system, by analogy to product liability.
• Operator liability. Responsibility runs to the organization that deployed it, whoever built it.
• Professional and supervisory duty. Licensed professionals retain duties of competence, confidentiality, and review, while supervisors set and check firm rules. ABA Formal Opinion 512 and IRS OPR Issue 2026-19, issued June 24, 2026, apply those duties to AI use.

In financial services this is already concrete. A bank that deploys a third-party model is an operator; the lab that trained the model is a developer. Which model prevails decides who carries the risk.

Agents and the identity gap

With an agent, responsibility depends on the profession, contract, statute, role, and facts. Licensed professionals can retain direct duties for competent review and client confidentiality, supervisors can retain duties to establish and verify firm controls, and vendors can carry contractual or statutory duties. What changes immediately is the evidence. When a person acts inside a system, the record says who they were. When an autonomous agent acts, many deployments record only a service account, without the agent, authority, or instruction. Enforcing responsibility takes a record that names those elements, which is why attribution is far from administrative detail.

For the prompts a team sends to supported AI tools, Sentinel, an AI gateway, replaces the identifiers it recognizes before the prompt leaves the computer and records metadata for each request. It records metadata only, so the attribution record described above stays the record of who acted.

Three of the eight stages, by profession

Where standards are heading

• NIST opened an AI Agent Standards Initiative in February 2026, explicitly addressing agents run without dedicated identity, authorization, or accountability controls.
• Singapore published the first comprehensive governance framework for agentic AI in January 2026, requiring each agent to carry a verifiable identity and an audit trail of which agent acted under whose authority.
• The EU AI Act applies Articles 14 and 15, on human oversight and on system reliability, to autonomous agents in high-risk settings.

The NIST item comes from secondary reporting. Read the primary document before relying on its detail. Singapore's requirements come from the linked primary IMDA framework.

What to check

• List every agent with standing authority to act in your systems, and the identity each one runs under.
• For each, confirm the record can show which agent acted, under whose authority, and on what instruction.
• For each third-party model you deploy, find what the contract says about who carries the risk, and have counsel read it with AB 316 in mind.