Who Owns AI Agent Errors? Logs, Approval and Accountability

When an AI agent fails, neither "the AI is responsible" nor "the person who clicked confirm is responsible" is an adequate answer. A company must separate four roles: designers determine how the system works, operators maintain versions and sources, approvers authorise consequential actions, and users provide genuine goals and follow operating rules. Logs then connect those decisions into an evidence chain. Without it, an incident review becomes a contest between chat screenshots and memory.

This article addresses engineering and operational governance, not the legal outcome of a specific event. Legal responsibility can depend on jurisdiction, contracts, industry rules, the facts and the type of harm, and needs qualified advice based on the actual record. What a company can do in advance is make boundaries, authority, approval and evidence clear enough to reduce errors and support any later determination with facts.

Reconstruct a mispriced quote before looking for one person to blame

Imagine a sales agent that receives a customer inquiry, retrieves product prices from a knowledge base, drafts a quote email in the customer relationship system, and sends it after a salesperson confirms. One day a customer receives a price below the current rate. On the surface, the agent selected the wrong price and the salesperson clicked confirm. Stop there and none of the causes capable of preventing recurrence has been found.

Continue the reconstruction and more decisions appear. The requirements never said a price conflict must stop execution. The old price sheet had no expiry marker. Operations added the new product file without withdrawing the old version. The agent found two prices and continued with the lower one. The approval view showed only the email, not the source and version behind the price. The salesperson recognised the template and approved. The incident was produced by the chain, not by an isolated model sentence.

The review should therefore ask which control was supposed to stop the error and failed, rather than who last touched the mouse. Browser Agent Uses and Boundaries separates preparation from effect. If a system collapses drafting, evidence review and final sending into one action, the interface has already flattened accountability.

Four roles own different control points

A responsibility chain should not label everyone jointly responsible. Each control needs one primary owner, named contributors and an escalation path. Before launch, assign the following responsibilities to actual roles rather than department names:

• Designers translate the business goal into executable boundaries: inputs, outputs, permitted tools, forbidden actions, conflict handling, stop conditions, approval points and acceptance criteria. They do not sign every business decision, but they own whether the system provides the right controls.
• Operators own production versions, knowledge sources, account permissions, alerts, regression tests and change records. They must know which version is running, who maintains its material, and when anomalous signals require pause or degradation.
• Approvers authorise a specific high-impact action after receiving enough information. They are not expected to inspect every technical detail, but must verify the object, critical parameters, evidence, risk flags and their own authority.
• Users provide accurate and complete task information, operate within their authority, read warnings, avoid prompting the system around controls, and report anomalies. They should not be made accountable for hidden risks the interface never showed and the system never recorded.

Vendors and model providers may also carry contractual duties for delivery, support, security or incident notification, but buying a product does not outsource scenario design and internal authority. The deploying company still decides which material may enter the system, which identities it may use and which outcomes require review. Responsibility may cross organisational boundaries; no control point should remain ownerless.

Useful logs record decisions and side effects, not only chat

Chat text shows what was said, not everything the system did. An auditable record should connect the task ID, initiator and executing identity, agent and prompt version, knowledge-source and data-snapshot identifiers, available tools and permissions, each tool call's parameter summary and returned status, generated result, policy refusals, approval, the object actually written or sent, human takeover and rollback. Credentials and secrets must never enter logs. Do not link emails, phone numbers or other low-entropy values with a plain hash; use a random event ID, and only if cross-system matching is required, a controlled token or keyed HMAC with tightly limited reversal.

Sequence matters. The record should answer which source version the agent read before deciding, what the approver saw, which object and parameters were approved, and how external state changed before and after execution. A final email plus "user confirmed" cannot distinguish an approval view that omitted evidence, approved content replaced later, or an execution tool that wrote the wrong value despite receiving the correct one.

Logs need governance of their own: who may read them, how long they remain, how ordinary operators are prevented from altering them, and how timestamps and task IDs align across systems. At the same time, do not put complete passwords, access tokens or unnecessary personal data into the record for the sake of audit. A strong evidence chain records enough to reconstruct consequential decisions without creating a new sensitive-data liability.

Human approval must bind to an action instead of decorating it

Meaningful approval occurs before the side effect and shows what the approver needs to decide. Sending a quote should display the customer, product, quantity, currency, price, price source and version, any deviation from the standard price, and the final message. A permission change should show the account, old and new access, duration and basis. The approval record binds to those parameters; changing a critical field after approval invalidates it and requires confirmation again.

Do not send every step to a person. Low-risk reversible actions can run automatically with sampling; high-impact actions receive stepped-up review. Too many repetitive dialogs with no highlighted difference train users to click mechanically. A better view foregrounds changes, anomalies and evidence, explains why this case needs judgement, and allows reject, edit or request-more-information rather than offering approve alone.

The approver must genuinely possess the relevant business authority, with a deputy and escalation path. The system must not quietly switch to automatic approval when someone is absent, or let a low-privilege user coax the agent into approving its own action over several turns. Separate the identities of the agent, approval service and execution tool where appropriate so one compromised session cannot propose, approve and execute.

Contain side effects first, then preserve evidence and restore service

When an error occurs, follow a defined order instead of debating responsibility while the same version keeps running:

1. Control impact: pause related tasks, reverse what can be reversed, narrow permissions and fall back to people or the previous process where needed.
2. Preserve evidence: capture and retain logs immutably, along with versions, inputs, source snapshots, the approval view and external state, before investigation overwrites the scene.
3. Establish scope: identify affected tasks, objects and periods, separating completed actions, pending actions and drafts that never took effect.
4. Repair and verify: fix data, rules, interface or permission controls together, then prove the control with a reproducible case.
5. Restore gradually: begin in shadow or a limited scope, observe continuously, then recover authority and volume in stages.

External communication, customer remediation and whether an event must be reported depend on the facts, contracts, applicable rules and professional advice; no universal answer follows from a general article. Engineering's job is to provide a trustworthy scope and record promptly, not to use model opacity as a reason why the incident cannot be investigated.

The repair must enter the test set. The mispricing scenario should add price conflicts, expired documents, missing provenance and changed approval parameters, then rerun them at every release. How to Evaluate AI Agents provides the layered approach across outcomes, process, tools, safety and recovery. An incident becomes organisational learning only when it becomes a regression case, not merely a meeting note.

Update the responsibility matrix with models, sources, tools and permissions

An agent is not static after launch. Models change, prompts are edited, sources keep moving, and tools and pages are redesigned. Each change can move the responsibility boundary. Adding a sending tool creates a new approval point. Replacing a read-only identity with a writer changes the risk tier. Introducing a source adds an owner and retention rules. The change record should update tests, log fields, approval views and the responsibility matrix together.

Operational measures need owners too: failures, human takeover, anomalous refusals, duplicate actions, rejected approvals and cost per task. Decide in advance who may stop the system when a threshold is crossed, who investigates and who authorises restoration. If technical staff only watch whether the service is online while nobody watches whether business outcomes are quietly deteriorating, the chain remains broken.

The handover matters most between pilot and production. From AI Pilot to Production emphasises a named operations owner and rollback plan. An agent needs one further layer: enumerate autonomous actions and confirm the owner, evidence, approval and stop condition for each. Informal rescue work absorbed by the project team during a pilot must become an explicit production duty.

An executable responsibility chain ends in three working documents

A company need not begin with a vast policy. Start with three documents that can operate. The scenario responsibility matrix names design, operations, approval, execution, review and escalation for every consequential action. The logging specification defines how tasks, versions, inputs, tools, approvals and side effects link. The approval and incident playbook states which actions require confirmation, what the reviewer sees, and how to pause, preserve evidence, roll back and restore. Validate all three through a drill, not only a review meeting.

Return to the mispriced quote. A reliable chain does not simply declare the salesperson or the model responsible. It explains why the old source remained retrievable, why the conflict did not stop execution, why approval hid provenance, who authorised sending, and how each control will be repaired. Accountability is valuable not because it finds someone faster after failure, but because every consequential decision has an owner before failure and the facts can be reconstructed afterwards.