Key takeaways
- Recent rules and cases point the same way: automating an action does not move responsibility onto the AI itself.
- California AB 316 bars the defense that the AI autonomously caused the harm; commentary says it applies from 1 January 2026.
- The EU Product Liability Directive covers AI software, lets courts order evidence disclosure, and allows a presumption of defect when required evidence is not disclosed.
- A log produced by the party in dispute is that party's account; a record bound to the transaction at execution can be checked by anyone.
- Verifiable proof shows what was executed, paid and settled, and under which authorization; it does not prove the agent's decision was correct.
What is AI agent liability?
AI agent liability is the question of who answers, legally and financially, when software acting for someone causes harm. The harm can be a wrong refund, a payment to the wrong party, a duplicate charge or a misleading statement to a customer. The agent cannot carry the liability itself, so it lands on a person or an organization.
For risk and compliance teams the question has two parts. The first is allocation: which party carries the loss under law and contract. The second is evidence: what each party can prove about what the agent did, under whose authority, and what was paid and settled.
This guide covers both. It describes what recent rules and cases say. It is not legal advice.
TODAQ Press puts the shift in one line: "Liability, in other words, is becoming a technical problem" (Settlement Without Proof).
Who is liable when an AI agent makes a mistake?
The sources point the same way. Responsibility stays with the people and organizations behind the agent.
- Moffatt v. Air Canada, 2024 BCCRT 149. A company was held responsible for what its chatbot told a customer. TODAQ Press reads the case as showing that "liability is not avoided by automating the actions in question."
- Bank of England. A Bank Underground post of 21 May 2026, as reported by TODAQ Press, takes the view that legal responsibility for an agent's actions remains with the human deployer.
- California AB 316. A defendant that developed, modified or used AI cannot argue that the AI caused the harm on its own.
- Contracts. TODAQ Press cites a February 2026 Clifford Chance note that "standard disclaimers typically leave the customer holding liability for a system they did not design and cannot fully audit."
TODAQ Press describes the resulting gap as "deployer liability without deployer visibility." The deployer carries the risk but often cannot see, or prove, what the agent did. That is where AI agent liability becomes an evidence problem.
What does California AB 316 change?
California AB 316 (Chapter 672, Statutes of 2025) adds section 1714.46 to the Civil Code. It was signed on 13 October 2025. Under it, a defendant that developed, modified or used artificial intelligence may not assert that "the artificial intelligence autonomously caused the harm to the plaintiff."
TODAQ Press, drawing on Baker Botts commentary, says the law applies from 1 January 2026 and "forecloses the autonomous-harm defense."
The statute addresses one specific argument: pointing at the model. Its effect on a given claim depends on the facts. What remains in any dispute is what the defendant did, authorized and controlled, and that is answered with records.
How does the EU Product Liability Directive treat AI software?
The EU Product Liability Directive (EU) 2024/2853 entered into force on 8 December 2024. Member states must transpose it by 9 December 2026, and it applies to products placed on the market after that date. "Product" includes software, including AI. TODAQ Press summarizes it as classifying "AI as a product subject to strict liability."
Two provisions bear directly on evidence:
- Disclosure. Courts can order a defendant to disclose relevant evidence.
- Presumption. A product can be presumed defective if required evidence is not disclosed.
Read together, these rules put weight on whoever holds the records. A provider that cannot produce credible evidence of what its system did can be in a weaker position. Which obligations apply to your products, and from when, is a question to confirm with your counsel.
What evidence matters in an AI agent dispute?
In a dispute about an agent's action, each side asks the same questions. What did the agent do? Who authorized it? What was paid, to whom, and when did it settle? Has the record changed since?
TODAQ Press argues that typical agent logs are weak on exactly these points (You Cannot Audit a Probability; When The Transaction Becomes The Record):
- An agent's log "is itself a language model output: a reconstruction, produced by the same probabilistic engine that executed the action." It "can be internally consistent, confidently written, and factually wrong."
- A record "generated separately from an action, and stored separately from an action, can always be questioned."
- In indemnification disputes, "the party whose infrastructure generated the logs is also a party to the dispute."
The essays frame this as "the difference between evidence and testimony." A log held by one party is that party's account. A record any party can check, without trusting its originator, is evidence. TODAQ Press also argues that insurers "are beginning to price the absence of portable provenance."
The essays point to Estate of Gene B. Lokken v. UnitedHealth Group (D. Minn.), where, they write, "logs existed, assembled after the fact from records that did not travel with the decisions, and a court order was required to surface them." The claims in that case are allegations, and UnitedHealth disputes them.
Logs still matter. Article 12 of the EU AI Act asks high-risk systems to "technically allow for the automatic recording of events (logs)." Our AI agent audit trail guide covers that. For the transaction itself, the question is narrower: can the other side verify it?
Evidence for AI agent disputes: what a bound record provides
| Dispute question | Evidence from a proof bound at execution | What you still need |
|---|---|---|
| What was executed and paid? | One record of the transaction and its settlement, with a transaction id and an emailed proof of purchase (A15, A17) | The business reason for the action |
| Who authorized it? | Authorization carried in the file: each update satisfies the previous step's requirements, such as specific signatures; human approval above the limit (A14) | Identity proofing of the approver |
| Was the right seller paid, once? | Payee in the record; sellers check X-Qatom-Transaction-Id so each sale is served once (B20) | The seller's own fulfilment records |
| Was spending authority respected? | Agent wallet balance as a hard ceiling and an auto-approve limit (A8, A9) | Evidence the agent's choice was within policy |
| Was the record changed later? | Non-equivocation proved by rigs; history cannot be altered without detection | Key and device custody controls |
| Can a court or insurer check it without us? | Local, offline verification against the file itself (C8) | Counsel's view on admissibility |
How does a record that any party can verify work?
Qatom transactions run on the TODA file protocol. Each TODA file carries a Proof of Provenance built from rigs: an unbroken, verifiable chain of custody. A rig proves non-equivocation, meaning no conflicting version of the asset's history was produced. Double-spend prevention is a proved theorem in "Simple Rigs Hold Fast" (Coward & Toliver, arXiv:2208.13617). TODA is not a blockchain: there is no global consensus, shared ledger or gas.
The proof is bound to the transaction and its settlement at the moment of execution. In TODAQ Press's words, "Settlement and verifiable record are the same atomic operation." Because the record was never separate, it "cannot be reconstructed after the fact."
Verification is local and works offline, because the proof travels inside the file. As TODAQ Press puts it, "Any party, a counterparty, regulator, insurer, or court, can verify it independently without trusting the organization that originated it."
Privacy holds by default. The owner can shield data before anchoring, so the trusted system records a proof without seeing the contents. Visibility is granted by consent: a counterparty or regulator can receive the full record, and others see nothing. The essays call the exportable record a "Transaction Binder" that a regulator or audit firm can verify offline (The Agentic Economy's Missing Middle).
In the product, you can inspect a note's minting information and provenance history (C7), verify a file's integrity and download the .toda file (C8), and export a twin's ledger as CSV (C9). The Qatom Console shows TODA files, provenance and verification for each twin.
How do you prepare evidence before a dispute starts?
Evidence is cheapest to secure before anyone disagrees. A practical sequence:
- List the agent actions that carry liability. Start with anything that moves money, commits to a purchase or issues a refund.
- Bind those actions to a verifiable record. Route payments through a rail where settlement and the record are one operation.
- Put spending authority in the money. Give each agent its own wallet with a small budget, set an auto-approve limit, and require passkey or phone approval above it (A8, A9, A14).
- Retain the records. Keep transaction ids and receipts, export ledgers (C9) and store .toda files (C8) in your retention system.
- Capture decision context separately. Keep prompts, model versions and approval reasons, since the payment proof does not show why the agent acted.
- Discuss evidence terms for contracts with counsel. Consider stating which records each party accepts and how they are verified.
- Test the handover. Give a sample record to someone outside the team, such as internal audit, and have them verify it offline.
What does the proof show, and what does it not?
Be precise with auditors, insurers and counsel about scope. Overstating it costs more credibility than it gains.
| Proves | Does not prove |
|---|---|
| What was executed, paid and settled, and when | That the agent's decision was correct |
| Who acted, under which authorization | That the agent stayed within its intended policy scope |
| That the history was not altered, substituted or selectively rebuilt | That the original data or human judgment was accurate ("Verification does not equal truth.") |
| That no conflicting version of the history was produced | A system-wide view for macro-prudential monitoring |
| That any party can verify it without trusting the originator | That regulators have accepted such records; none has formally opined |
TODAQ Press states the first limit directly: embedded provenance "cannot guarantee that an autonomous decision was correct, or that the agent acted within its intended policy scope." What it does guarantee is that "the execution history cannot be retroactively altered, selectively reconstructed, or institutionally withheld."
Further reading
- When The Transaction Becomes The Record (TODAQ Press, 20 May 2026)
- Settlement Without Proof (TODAQ Press, 19 May 2026)
- You Cannot Audit a Probability: The Agentic AI Trust Wall (TODAQ Press, 12 May 2026)
- Simple Rigs Hold Fast (Coward & Toliver) and the Rigging Specifications
Next steps
- Read the assurance overview for risk, security and compliance teams.
- Book an enterprise demo to verify a live transaction record yourself.
- Learn how cryptographic proof of payment works, step by step.