Who is responsible to the customer when an AI agent makes a mistake?
Do not assume the language-model provider will automatically pay for a bot’s mistake with a customer. Responsibility depends on three things: the law that applies, the agreements between the parties, and what the agent actually did. A wrong chat response and an incorrectly processed refund have different consequences.
The key requirement is for the business to manage two things separately. First, the promises its bot makes to customers on the company’s behalf. Second, its relationships with the developer and model provider: who guarantees what, and who fixes what.
After reading, you can assess which bot actions carry the greatest risk, what to limit technically, which terms to agree with an integrator, and how to respond when a customer complains. This article explains an approach; it is not a legal opinion. A separate lawyer consultation is needed to assess a situation under Ukrainian law.
Response error and action error
The word “error” covers very different events. For risk assessment, divide them into two groups.
Response error. The bot gives a customer incorrect information: the wrong price, a nonexistent term, or an inaccurate description of a service. The system itself changes nothing, but the customer may act on the response: place an order, travel to a location, or reject another offer.
Action error. The agent not only responds but also does something in a system: applies a discount, issues a refund, or changes an order. The consequence has already occurred and must be corrected in the business system, not just in the conversation.
| Scenario | Type | What has happened | What is needed to correct it |
|---|---|---|---|
| Bot quoted a price below the price list | Response error | Customer received a promise and may rely on it | An authorized person decides how to handle the promise |
| Bot promised a refund that the rules do not provide | Response error | Customer expects a refund | Check the rules, make a decision, and explain it to the customer |
| Bot misstated what a service includes | Response error | Customer may have bought with false expectations | Review the order and possible changes to its terms |
| Agent applied a discount in the cart | Action error | Order was placed at a different price | Decide how to handle the order and correct the records |
| Agent processed a refund | Action error | Money was returned or scheduled for return | Financial procedure and review of the agent’s authority |
The more an agent can do on its own, the more costly its error and the harder it is to reverse. So the first management decision is not “which bot should we choose?” but “which actions may the bot take without a person?”
A Canadian case study
A useful case for discussing chatbot responsibility is Moffatt v. Air Canada, 2024 BCCRT 149. It is a 2024 decision of the Civil Resolution Tribunal of British Columbia, Canada: a ruling by a specific body in a specific jurisdiction, not a general rule.
The full decision was not available during the research; only an excerpt from paragraphs 27 and 28 was available. We therefore make no claims about the amount of compensation, an appeal, or other circumstances absent from that excerpt.
The available excerpt indicates:
- Paragraph 27. The airline argued that it could not be responsible for information provided by its agents or representatives, including the chatbot. The Tribunal rejected that position and said the company was responsible for all information on its website. In that case, the company could not present the bot as a separate person responsible for its own words.
- Paragraph 28. The Tribunal concluded that the company had not taken reasonable care to ensure the chatbot’s accuracy. It also had not explained why customers should cross-check information in one part of the site against another part.
This example does not mean a court in Ukraine or another country will reach the same decision. It does not establish a universal rule that a company always compensates for every bot response. A lawyer must assess whether similar reasoning applies to your situation under the law of your jurisdiction.
The practical business lesson is different: in this case, “the bot said it, not us” did not work. Plan bot operations as though each response may be treated as company information, and build accuracy controls accordingly.
Four parties and different agreements
A typical AI-agent project involves four parties. They have different agreements, and responsibility does not automatically pass down a chain from the customer to the model provider.
Customer and business. The customer interacts with the company, not the model. Their relationship is governed by a contract, public offer, sales rules, and any consumer-protection law applicable to the situation. To the customer, the bot is part of the company’s service.
Business and integrator. The company that builds and maintains the bot works under an agreement with the business. That agreement defines what the integrator guarantees, how it checks quality, how it responds to incidents, and what it is responsible for. If the terms are not written down, the dispute about them will happen after an incident.
Business or integrator and model provider. The model is used under the provider’s terms, which govern service access and data processing. Read the agreement you actually use to find its terms on responsibility for generated outputs; do not assume them.
Why the chain does not work automatically. Even if a model characteristic caused an error, the customer may complain to the company they deal with. Whether that company can then claim against the integrator, and the integrator against the provider, depends on their agreements and applicable law. There is no basis for assuming in advance that “whoever made the model pays.”
A separate note on transparency: Article 50 of the European AI Act sets transparency duties for providers and users of AI systems. The European Commission’s guidance on these duties was published on 20 July 2026, and the duties apply from 2 August 2026. Whether they cover your company depends on whether the Regulation applies. Article 50(1) requires providers of systems designed for direct interaction with people to ensure people are informed about AI, with an exception when this is already obvious from the context. Where notice is required, it addresses transparency of the interaction. It does not guarantee that prices, terms, or promises are correct.
What to limit technically
Technical decisions do not determine legal responsibility, but they affect how many errors can occur and how serious they can be. OWASP describes Excessive Agency as a risk for language-model applications: a system takes harmful actions in response to an unexpected, ambiguous, or manipulated model output. There are three causes: excessive functionality, excessive permissions, and excessive autonomy.
For a bot that discusses prices and terms with customers, this leads to four practical rules.
Prices and terms only from a catalog. The bot should retrieve and quote a price from a business system or catalog using a tool, not invent one. The same applies to delivery, warranty, and return terms. If the source has no answer, the bot should say it will check with a manager rather than guess.
System-level limits. If a bot can apply a promo code or discount, code—not a prompt instruction—should enforce the maximum amount and allowed discount list. OWASP recommends limiting extensions to the minimum necessary permissions and enforcing authorization in the target systems rather than relying on the model’s decision.
Human approval for disputed actions. Refunds, unusual discounts, and changes to contract terms should go through a person. OWASP explicitly recommends human approval for high-impact actions. In this setup, the bot gathers information and creates a request; an authorized employee makes the decision.
Change and conversation logs. Keep conversations, tool calls with their parameters, and versions of the sources the bot used: price lists, delivery rules, and return procedures. OWASP says logging and monitoring do not prevent excessive agency, but they help limit harm. A log is one source of facts when reviewing a complaint. Its availability, completeness, and evidentiary value must be assessed separately. Do not store secrets or unnecessary personal data; define a retention period and who can access the logs.
What terms to agree on
Some risks are addressed through agreements with the integrator and within the company, not through settings. Agree on the topics below before launch. A lawyer should draft the actual contract language.
| Topic | What to record |
|---|---|
| Scope of services | What the bot does, which data sources it uses, which actions it can take, and which it only passes to a person |
| Quality control | Who reviews responses, how often, against which test questions, and what counts as an error |
| Data updates | Who keeps the bot’s price and policy sources current and how quickly changes reach the system |
| Incidents | What counts as an incident, how it is reported, who disables the affected scenario, and by when |
| Responsibility | How responsibility is allocated between business and integrator by error type, within applicable law |
| Evidence | Which logs are kept, for how long, who can access them, and how to obtain them for review |
| Correction process | Who changes the system after an incident, how changes are tested, and who approves returning the scenario to service |
Also decide inside the company who may approve what the bot promises: the head of sales, support, or a lawyer. Without that, every complaint turns into an argument over who should decide.
How to respond to a complaint
A customer writes: the bot promised one thing, but the company is doing another. An organized response affects both the customer relationship and your position if the dispute continues. Consider this training example.
Training example: free delivery
This example is fictional. An online store’s bot tells a customer that orders over UAH 1,000 ship free. The store’s current rule is free delivery over UAH 1,500. The customer places a UAH 1,200 order and sees a delivery charge at checkout. They contact support with a screenshot of the conversation.
The table shows the facts to establish before any decision. It does not decide in advance whether the company must provide free delivery; an authorized person decides based on company rules and applicable law.
| Question | What to establish in this example |
|---|---|
| What did the bot say? | Exact response, date, and time from the conversation log, not only the customer’s screenshot |
| Which rule applied? | Version of the delivery rule at the time; whether it had recently changed |
| Where did the answer come from? | Whether the bot quoted a source or generated the threshold; whether the source was outdated |
| Was a purchase placed? | Yes, for UAH 1,200; whether the response influenced the decision |
| Who makes the decision? | An employee authorized to decide sales terms, not the bot or an unauthorized first-line agent |
| Which logs were preserved? | Conversation, tool calls, delivery-rule version, order data |
Pay particular attention to “Where did the answer come from?” If the bot quoted an outdated document in its knowledge base, the problem is the data-update process. If it invented the threshold, the problem is that the bot formulates terms instead of quoting them. That determines what needs fixing.
Response steps
- Reconstruct the facts. Find the conversation, tool calls, and version of the source the bot used. Compare the customer’s screenshot with the log.
- Check the promise. Compare the bot’s response with the rules that applied at the time. Determine whether this was a response error or whether the bot also took an action.
- Escalate to an authorized employee. A person with the right authority decides, following company rules and consulting a lawyer if needed. Tell the customer who will respond and when.
- Fix the source of the error. Update the data, limit the bot to quoting the catalog, and add the scenario to tests. If the error recurs, temporarily disable the affected scenario and route those questions to people.
- Record the incident. Write down what happened, what decision was made, and what changed. This record will help with future complaints and discussions with the integrator.
Frequently asked questions
A notice can explain the service’s limits, but it should not be treated as a universal release from company responsibility. The Canadian example discussed above concerns the accuracy of information on a website; by itself, it does not resolve whether every possible disclaimer is effective. A lawyer can assess how such a notice would be treated in your jurisdiction.
There is no universal answer. A developer’s duties depend on its role in the project, its agreement with you, applicable law, and the circumstances of the case. That is why responsibility allocation, quality controls, and incident procedures should be written into the agreement before launch.
To establish which terms applied during the conversation and what the bot relied on when it made a promise. Without source versions, it is much harder to distinguish stale data from an invented answer and identify why the error occurred.
Consultation on your customer bot’s permissions
In 15 minutes with an AI integration specialist, discuss your bot’s responses and actions on prices, discounts or refunds. Identify a first point for human approval; your legal adviser assesses liability.
Bot action
Human approval
15 minutes with a specialist to discuss one bot action and identify where human approval is needed.
