Who Is Liable When the Human Approves a Bad Action? The Accountability Chain in HITL
An AI agent sends a customer a misleading email. The customer sues. Discovery reveals that the email was reviewed by a human before it was sent. The human approved it. The email was wrong. The customer was damaged.
Who is liable?
- The agent vendor, who built the model that produced the bad email
- The deploying company, who configured the agent and the HITL gate
- The human reviewer, who approved the email
- The human reviewer's manager, who set the review policy and the SLAs
- The customer's own company, for failing to filter the email upstream
The legal system doesn't have a clean answer. The emerging answer — the one regulators and courts are converging on — is: all of the above, distributed according to the chain of accountability, evidenced by the audit trail.
HITL doesn't eliminate liability. It distributes liability. And the distribution depends entirely on what the audit trail can prove about who did what, when, with what information, and under what policy.
The Three Liability Theories
Theory 1: The Reviewer Is Liable
The simplest theory. The human approved the action. The human had the opportunity to reject. The human failed to catch the error. The human is responsible.
This theory works when the human had the information, the time, and the authority to make a real decision. It fails when the human was rubber-stamping under volume pressure, when the human was given a summary that hid the relevant context, or when the human was told to "just approve the routine stuff."
The audit trail that supports this theory: The reviewer was authenticated, the reviewer was given the full context, the reviewer spent sufficient time on the review, the reviewer's decision was logged with reasoning. The reviewer is individually accountable.
The audit trail that undermines this theory: The reviewer clicked approve in 8 seconds. The review interface showed a one-line summary. The reviewer's manager had told them to clear the queue. The reviewer cannot be held to a standard they were not given the means to meet.
Theory 2: The Deploying Company Is Liable
The reviewer is an employee. The review interface is the company's design. The policy thresholds are the company's decision. The company is vicariously liable for the reviewer's decisions — and directly liable for the system the reviewer operated within.
This theory is closer to the legal reality. Companies are sued, not individual reviewers. The company's HITL system is evaluated for whether it was reasonably designed, reasonably operated, and reasonably supervised. The individual reviewer's decision is one data point in the company's system, not a free-standing act of personal judgment.
The audit trail that supports this theory: The company had a written HITL policy. The policy was followed. The audit trail shows consistent enforcement. The company is responsible for the system's design and operation, not the individual decisions within it.
The audit trail that undermines this theory: The audit trail shows that the policy was inconsistently applied. Some reviewers had different thresholds. Some actions bypassed review. The company's system was not reasonably designed or supervised.
Theory 3: The Agent Vendor Is Liable
The model produced a confidently wrong output. The reviewer was misled. The system was designed to be a process that could be misled. The vendor is liable for the model and for the system design that allowed the mistake.
This is the emerging theory under the EU AI Act and similar product liability frameworks. The vendor is responsible for the model's behavior, the system's safety, and the documentation that allows the deployer to use it safely. If the model is "reasonably foreseeable" to mislead, the vendor is liable.
The audit trail that supports this theory: The vendor's documentation warned about the failure mode. The deployer ignored the warning. The vendor is not liable for misuse. The deployer is.
The audit trail that undermines this theory: The vendor's documentation was incomplete. The model was demonstrably wrong in ways the vendor knew or should have known. The vendor is liable for the foreseeable harm.
The Chain of Accountability
The three theories are not mutually exclusive. In any real incident, the chain of accountability looks like:
Vendor (built model) → Deployer (deployed & configured) →
Manager (set policy & SLAs) → Reviewer (made decision) →
Agent (took action) → Customer (was harmed)
Each link in the chain has a duty and a defense. The duty is what the link was supposed to do. The defense is what the audit trail shows about whether the duty was met.
| Link | Duty | Defense in Audit Trail |
|---|---|---|
| Vendor | Build a model that is reasonably safe and reasonably documented | Model card, evaluation results, known limitations |
| Deployer | Configure the model and HITL system for the deployer's use case | Policy manifest, configuration decisions, change log |
| Manager | Set review policies, SLAs, and reviewer training | Written policy, training records, SLA compliance data |
| Reviewer | Make a reasonable decision with the information provided | Authentication, context provided, time spent, reasoning |
| Agent | Execute the approved action as authorized | Authorization chain, action parameters, execution log |
| Customer | (External — the harmed party) | N/A |
In litigation, each link produces evidence from the audit trail. The court's job is to assign liability proportionally to where the chain broke. The audit trail is the evidence that determines who broke it.
Where the Chain Breaks
Break Point 1: Inadequate Reviewer Context
The reviewer approved an action they didn't understand. The audit trail shows the review interface only displayed a summary. The reviewer had no opportunity to make a real decision.
Liability distribution: The deployer (designed the review interface). The vendor (if the model's outputs are reasonably foreseeable to mislead). The reviewer (if they rubber-stamped despite the interface).
Break Point 2: Inconsistent Policy Application
The same action was approved in one case and rejected in another, with the same reviewer, on the same day. The audit trail shows the inconsistency.
Liability distribution: The reviewer (made inconsistent decisions). The manager (failed to train or supervise). The deployer (failed to provide a clear policy).
Break Point 3: Timeout Cascade
The reviewer didn't respond. The timeout fired. The system auto-approved after the timeout. The action was bad.
Liability distribution: The deployer (designed the timeout to auto-approve). The manager (set unrealistic SLAs). The reviewer (failed to respond). The chain broke at the timeout design — which is a deployer decision.
Break Point 4: Cross-Agent Delegation
Agent A delegated to Agent B which delegated to Agent C which took the action. The reviewer approved Agent C's action without seeing the delegation chain. The action was bad because of an Agent A decision that the reviewer couldn't see.
Liability distribution: The deployer (failed to surface the delegation chain in the review). The reviewer (approved without verifying). The vendor (if the framework's delegation model hides context).
Break Point 5: After-The-Fact Override
The reviewer approved the action. Three weeks later, the reviewer or their manager realized the action was wrong. They tried to reverse it. The reversal was logged as "human override" — but the original approval was not corrected.
Liability distribution: The manager (failed to correct the audit trail). The deployer (audit trail doesn't link the override to the original approval). The chain is broken at the audit trail's immutability assumption.
What the Audit Trail Must Capture for Defensibility
The audit trail is the evidence. The evidence must be sufficient to support or undermine each link in the accountability chain. For a HITL system, the audit trail must capture:
For Each Action
- The agent's full context (what the agent saw, what tools it had, what model version)
- The policy rule that evaluated the action and classified it as review-required
- The agent's alternatives considered (and the rejected options)
- The risk indicators (financial impact, irreversibility, blast radius)
For Each Reviewer Decision
- The reviewer's identity and authentication method
- The review interface state at the moment of decision (what the reviewer actually saw)
- The reviewer's time-to-decision (the duration between action presentation and approval)
- The reviewer's stated reasoning (if the interface requires it)
- The reviewer's pattern at the time (recent decisions, override rate, time-of-day)
For Each Approval Chain
- The full delegation path (if the action originated in a multi-agent system)
- The escalation chain (if the action was escalated from a lower-tier reviewer)
- The timeout and fallback behavior (if the action was auto-approved after a timeout)
- The post-execution override (if the action was later reversed)
For Each Policy Decision
- The policy version active at the moment of action
- The reviewer pool definition at that moment
- The configuration changes that preceded the action
- The deployer's documented policy intent
The audit trail that captures all of this is the audit trail that can defend against litigation. The audit trail that captures only "Reviewer X approved action Y at time Z" cannot.
The Liability Distribution for a HITL Failure
When a HITL failure causes harm, the realistic liability distribution in a mature legal framework is:
- 30–50% Deployer — for designing the system, setting the policies, configuring the reviewers
- 15–25% Vendor — for the model's behavior and the system's safety design
- 10–25% Reviewer — for the individual decision, depending on context adequacy
- 5–15% Manager — for supervision, training, and SLA design
- 0–10% Other — depending on jurisdiction and specific facts
The deployer is the largest single share because the deployer is the one with the most control over the system that failed. The deployer chose the model, configured the policy, designed the review interface, and selected the reviewers. Every other link's liability is a fraction of the deployer's choices.
This is why the audit trail requirements are not just about compliance — they're about legal defense. A deployer with a comprehensive audit trail can defend the deployer's decisions. A deployer with a thin audit trail cannot — and the legal system will assume the worst.
HITL and Insurance
The insurance industry is just starting to develop products for AI agent liability. The underwriting question is: what is the deployer's HITL risk profile?
A deployer with:
- A documented HITL policy
- Version-controlled manifests
- Structured reviewer decisions with reasoning
- Audit trail with full context
- Calibrated timeout and fallback policies
- Two-reviewer patterns for high-stakes actions
...is a better insurance risk than a deployer with rubber-stamp approvals and untraceable decisions.
The insurance premium differential between these two profiles will, in the next 3–5 years, become substantial. The deployers who invest in the audit trail and the HITL design will pay materially less for the same coverage. The deployers who treat HITL as a checkbox will pay materially more — or be uninsurable.
Where Facio Fits
Facio's audit trail is designed for the accountability chain. Every action, every policy evaluation, every reviewer decision is captured with the full context needed to support or undermine each link in the chain. The manifest version, the reviewer authentication, the time-to-decision, the reviewer's stated reasoning — all logged, all queryable, all defensible.
Placet.io's review interface captures the reviewer's actual decision context. The reviewer authenticated, the interface they saw, the duration of the review, the structured reasoning — all recorded. The audit trail supports the individual reviewer's defense when the decision was reasonable. The audit trail undermines the individual reviewer's defense when the decision was rubber-stamped. Either way, the trail is honest.
The accountability chain is the legal reality. The audit trail is the legal evidence. HITL doesn't eliminate liability — it distributes liability. The deployers who build the audit trail to support the distribution are the deployers who can defend their position when something goes wrong.
Key Takeaways
- HITL doesn't eliminate liability — it distributes it. The agent vendor, the deployer, the manager, and the reviewer each have a share
- Three liability theories apply in different combinations: reviewer liability, deployer liability, vendor liability
- The chain of accountability is the legal reality — each link has a duty, a defense, and evidence in the audit trail
- The audit trail must capture far more than the decision — it must capture the context, the policy, the time, the reasoning, the chain
- Five break points in the chain: inadequate reviewer context, inconsistent policy application, timeout cascade, cross-agent delegation, after-the-fact override
- The deployer is typically the largest single share of liability — they have the most control over the system
- Insurance is starting to price HITL risk — comprehensive audit trail and structured review will become a premium differentiator
- Facio's audit trail is designed for legal defensibility — the trail supports each link in the chain, for better or worse
Sources: The liability analysis draws on product liability law (US Restatement Third, EU Product Liability Directive 2024), the EU AI Act's liability framework, the emerging case law on automated decision systems, and the documented patterns of audit trail requirements in regulated industries. The insurance analysis reflects early market signals from cyber liability and professional indemnity underwriters evaluating AI agent deployments.