Who Is Responsible If Your AI Agent Makes a Mistake?

What you can decide after checking the facts

A better-informed decision starts with what is known, what still needs checking, and who will take the next step. The following are practical objectives to consider for this particular issue:

• Identify each participant and controllable risk.
• Distinguish direct loss from third-party claims.
• Preserve action history.
• Map possible contract remedies.

Why the evidence matters

US-TechLaw is an independent technology-law research and consulting platform. This page uses the applicable official rules and product-provider documentation as reference points, rather than relying on broad claims about what every AI system or business must do. Where company-specific contracts or settings would change the conclusion, they are identified as facts to verify instead of assumed. The research is informational and does not replace qualified advice for a particular situation.

How to raise your specific question

Describe the decision or problem in a few sentences, identify the product or system involved, and state what result you need to understand. Do not send privileged documents, complete customer files, credentials, or sensitive operational records in an initial email. The scope, appropriate expertise, and any secure exchange of additional documents should be determined separately before detailed review.

Questions worth preparing:

• Was this a service error, a privacy incident, or both?
• Was there a contractual obligation to approve an action?

Questions, documents and safeguards to review

What exactly did the AI agent do wrong?

An AI-agent mistake may involve a false answer, but it may also involve an action: sending a message, changing a customer record, granting access, or triggering another service. Those events are not interchangeable. Start with the action actually taken, its timestamp, the account used, and the person or organization affected. Record whether the agent was meant to advise a person or act independently. A wrong summary may call for correction; an unauthorized system change may require containment and investigation. Legal responsibility depends on the facts and applicable agreements, not the mere presence of AI.

Which company authorized the action?

The organization deploying an agent normally chooses the business purpose, connects systems, and decides what level of automation is permitted. Those choices make its instructions and approvals relevant to any later dispute. Ask who approved the deployment, who authorized the particular action category, and who could suspend the workflow. The word “autonomous” should not be confused with an absence of organizational control. A vendor might operate the underlying model while the customer determines the tools, data, and customer-facing process. Both sets of decisions belong in the factual record.

Who selected and controlled the agent tools?

An agent can involve a model provider, agent platform, integration vendor, internal administrator, and operator of a connected system. Prepare a chain of control rather than a list of logos. Which party wrote the instruction? Who supplied credentials? Which connector transmitted the request? Who defined the action limit? If the tool was configured to write to a database, the record should identify the permission and approval that enabled it. These questions reveal what each participant could reasonably prevent, detect, or correct. They do not, by themselves, determine liability.

What logs or approval records can explain the event?

Preserve a reliable sequence before changing the system. Useful material may include agent instructions and version, tool invocations, approval events, identity records, system responses, output shown to the customer, incident notices, and subsequent corrections. Restrict access to sensitive logs and avoid collecting unrelated personal data. A simple screenshot of an alarming AI response may omit the action that followed or the human who approved it. NIST's generative AI risk profile supports documenting system risks and management practices; the exact evidence required in a dispute depends on circumstances. (NIST AI Risk Management Framework, Generative AI Profile)

What does the customer agreement actually say?

Read the signed contract and incorporated documents, not an online summary alone. Relevant provisions may define the service, acceptable use, responsibility for configuration, security duties, incident notification, remedies, and exclusions. Determine which version applied when the event occurred and whether an order form or service schedule changed the baseline terms. A clause describing model limitations is different from a promise about a specific configured agent. Contract interpretation also depends on governing law and the actual loss asserted. Do not presume a supplier automatically accepts every outcome produced by a tool connected by its customer.

How do direct losses differ from other claims?

A business may face a direct operational problem, a customer complaint, a privacy incident, an intellectual-property issue, or a dispute between vendors. Those pathways require different tests. First identify who experienced the effect and what factual damage can be demonstrated. Then ask whether the relevant agreement covers that category of event. Some consequences may involve regulators or third parties who were not signatories to the contract. A private contract cannot be treated as a universal answer to duties arising independently under applicable law. Preserve this distinction in the incident summary.

What happens if more than one party contributed?

Where several providers contribute, prepare a responsibility map for the full workflow: model suggestion, agent planning, connector access, approval step, action execution, and customer notification. Attach evidence to each transition. A failure can arise because the model produced a mistaken suggestion, a tool executed beyond its intended scope, or a human skipped required review. Those are different root causes. Separating them allows the business to identify corrective controls and the agreement that governs a disputed component. Keep open the possibility of more than one contributing cause rather than forcing every event onto one vendor.

Which steps should be taken before changing the system?

The next step is both immediate and longer-term. Stop or limit the harmful action, preserve records, correct affected information where appropriate, and involve relevant internal decision-makers. Review whether notices or escalation obligations are triggered under contracts or applicable rules. Afterwards, change permissions, tests, approval requirements, and contract language that allowed the same event to happen. A useful outcome is an evidence-backed incident narrative and a prospective control plan, not a promise that any particular party will be found responsible. Specialist advice is necessary when the impact or jurisdiction makes it material.

Example: how the decision changes with the facts

Illustrative scenario, not a client case or statement of actual results.

An AI support agent creates an incorrect instruction and updates a customer account before the operator notices. The model provider supplied the language technology, the integration company built the connector, and the customer organization enabled the write permission. A careful investigation would preserve the agent configuration, tool call, user request, change log, and agreements with each provider. It would ask what each participant controlled and whether a human was expected to approve the change. The existence of multiple suppliers does not establish the responsibility of any one of them. A reviewed incident narrative is the starting point for any claim or corrective plan.

Decision and evidence table

Documents and facts to prepare

For a reliable review, identify the specific system or agreement, the date and version of its relevant terms, the business decision being made, the people affected, and the records available to support the answer. The most helpful starting material for this topic is: Five-party responsibility map plus first-party/third-party claims decision tree. A request for information should remain proportionate; sensitive records should be exchanged only through an appropriate authorized process.

Frequently asked questions

Is the AI model supplier always responsible?

No. Responsibility depends on the event, contracts, applicable law, and who controlled the relevant steps.

What should be preserved first?

The action sequence, applicable agreements, tool calls, approvals, system logs, and evidence of effects.

Can a contract eliminate all responsibility?

Do not assume that. Contract clauses and duties arising under law require separate analysis.

What to check before acting

Before acting, write down the decision your team needs to make: Help a company understand how responsibility for an ai-agent error may depend on contracts, control, and the actual event. List the relevant documents and settings, the facts still missing, and the person who will confirm each point. Review the decision again if the agreement, software features, workflow, or governing requirements change. Seek qualified professional advice when the specific legal question or regulated activity requires it.

Related business and technology guides

• Explore AI Agent Responsibilities
• Related research and practical support
• What Should an AI Agent Contract Say?
• How Do You Control What Copilot Studio Agents Can Do?