Agentic AI liability: design the evidence before the dispute

Updated 17 October 2026. Imagine an agent making a consequential change that nobody intended. The first useful question is what actually happened. A confident explanation without records can make the dispute harder to resolve.

Preserve the action chain

Record the requested task, relevant permissions, approval conditions and observed outcome at an appropriate level of detail. The record should make it possible to distinguish a proposed action from an executed one. Protect sensitive information and define retention deliberately.

An illustrative payment workflow needs to establish the amount, recipient and approval that applied to the action. If those changed between approval and execution, the investigation should be able to see that difference. A generic “approved” flag may conceal the important fact.

Test how the system behaves when a response is missing. Retrying an action can create a duplicate if the first attempt succeeded but its acknowledgement was lost. The product needs a defined way to resolve that uncertainty before acting again.

This evidence supports investigation; it does not predetermine legal liability. Responsibility depends on the facts and applicable rules. Avoid replacing that assessment with a slogan about who has the deepest pockets.

The practical next step

Choose a consequential workflow and test an ambiguous result in a safe environment. The evidence you wish you had during the exercise is evidence to design before deployment.

Keep the resulting decision, its owner and unresolved questions in a short decision record. For claims about agent behaviour, connect the decision to evaluation evidence rather than relying on a successful demonstration alone.

Further primary reading: NIST AI Risk Management Framework. The review map and product recommendations above are my analysis, not a certification or a legal assessment of a particular deployment.