Showing liability at the point of action
A plain-language statement, shown before the user authorizes an agent's action, of who is responsible if it goes wrong. The user decides whether to proceed with that answer already in view.
The impact of agents
As agents take on more actions with legal or financial consequences, more of those moments will pass with no one having said who bears the liability if it goes wrong.
The exposure could fall on the user for having delegated, on the agent provider that built and operated the agent, or on the government for accepting an agent-mediated submission, and these claims compete with no settled answer. Leaving the allocation ambiguous at this moment is harmful.
What must be verified
The liability allocation shown to the user must be accurate and enforceable, not a plausible-sounding statement with no backing regime. It must match the legal framework that applies to that action. The agency accepting the agent-mediated action must confirm that match before the checkpoint displays the allocation.
Protecting access
A liability statement written for lawyers excludes users twice over. A user who accepts exposure they didn't understand pays for it when the error lands. A user frightened off by legal-sounding text is deterred from help they were entitled to use.
Keeping the path open
- Put a plain-language liability line at the checkpoint ('if this contains errors, here is who is responsible'), with the full allocation expandable rather than default.
- Translate into the user's preferred language, and state the consequence concretely (who pays, who fixes it, who to contact) rather than as a limitation-of-liability clause.
- Make the liability line and its expandable detail operable by keyboard and screen reader, so the allocation reaches someone who can't see that fuller detail is collapsed.
Response surface
Who carries the cost if the agent gets it wrong is stated in plain language at the moment of authorization, rather than discovered afterwards.
The statement is always shown, and the record notes that it was shown. The accredited and pending versions never require a checkbox to continue — forcing routine acknowledgment trains click-through. Only the not-accredited state gates authorization behind an explicit opt-in. The version that appears follows from the provider’s accreditation status.
Maturity
- Established
For professional intermediary liability models, which are well settled.
- Emerging
For AI Act provider and deployer liability allocation, still taking shape.
- Frontier Headline
For user-facing liability disclosure at the point of agent action, which remains undesigned.
Precedents
Regulation (EU) 2024/1689, provider and deployer obligations. The Act separates the provider of a system, who designs it, from the deployer, who uses it, and gives each distinct obligations on oversight, documentation, and risk management. The allocation is written to be surfaced.
PSD2 authentication liability shift. Liability for a fraudulent transaction turns on whether Strong Customer Authentication was properly applied, and a merchant or payment provider that fails to apply it bears the loss. The allocation is fixed before the transaction, and not argued afterward.
ATO tax agent lodgment responsibility. A registered tax agent lodging for a client bears professional responsibility for the accuracy of the lodgment, subject to the information the client provided, and ATO systems record whether a return was self-lodged or agent-lodged. The record carries who acted, which is what any later allocation of responsibility rests on.
What carries over to agent use
The tax agent model is the closest analogue: a professional intermediary acting on delegated authority with defined professional responsibilities. For AI agents, the liability framework does not yet exist in most jurisdictions, but the interaction pattern should surface whatever framework applies.
At minimum, the review checkpoint needs to state that allocation before the action is authorized. The PSD2 liability-shift model suggests the framework should be pre-determined and disclosed, not litigated after the fact.
Where things go wrong
The failure mode is no clear accountability for an incorrect automated decision, often with the onus of proof reversed onto the user. A disclosed liability allocation at the point of action makes accountability legible before harm occurs. A disclosure can also satisfy the form and not the substance: a liability line that names a responsible party in general terms, with no enforceable process behind it, leaves the user no better off once the error lands.
Sources
3 references
The instrument, the operating deployment, or the official record itself.