Civil Liability for AI Errors in Companies: Who Is Responsible?

When an AI system causes harm to a customer, the party that usually answers to that customer is the company that put the system in front of them and benefits from it, even if the error started in a third-party model. The technology provider may answer under the contract and for the defect in what it delivered, and the internal user answers for any misuse. In practice, what settles the discussion is the record of what the AI did and whether a person approved the decisions with the highest impact. This article is management guidance, not legal advice.

Key takeaways

• The company that serves customers with AI usually answers to them, even when the failure came from a contracted model or platform.
• The provider answers for what it sold and for what the contract actually covers, so clauses, logs and documentation matter.
• An internal user can be liable for misuse, such as pasting customer data into unapproved tools.
• Records of input, lookup, action and handoff are the main evidence for separating responsibilities.
• Human approval for refunds, discounts, cancellations and sensitive guidance reduces the chance that an error reaches the customer.

Why the question is practical, not theoretical

Much of the conversation about superintelligence concerns systems that do not run in company operations today. The liability question, however, is already on the table. An agent that states a delivery date, applies a discount or explains a product warranty is speaking on behalf of the company. Separating the future debate from what your operation does now keeps the focus where it belongs, and the difference between AGI, ASI and AI agents sets out that point.

Legally, an error by an AI answering on WhatsApp is not different from an error by a poorly trained employee. The difference is scale, and rebuilding what happened depends on records that many companies never kept.

The three liability scenarios

For the end customer, the company is the service provider. Under Brazil's Consumer Protection Code (CDC), article 14, service providers answer for damages caused by defects in the service, regardless of fault. Telling a customer that "the AI got it wrong on its own" does not protect the company in front of that customer.

The technology provider comes into play in the internal relationship. If the problem lies in the model, in an unannounced update, in a security failure of the platform or in an integration it delivered, the company may seek reimbursement. How far that goes depends on the contract: liability caps, type of support, notice period for incidents and access to logs. Without those clauses, the company carries the full risk with little evidence.

The internal user is the employee who operates, configures or uses the tool. If they enter customer personal data into an unapproved assistant, or change the agent's instructions without review, internal responsibility may fall on them, without removing the company's responsibility toward third parties. That is why the usage policy must state what is allowed and what is banned. Company policy for employee ChatGPT use covers that scope in detail.

How responsibility is distributed in a concrete case

Illustrative scenario: a custom furniture store uses a WhatsApp agent to handle quote requests. A customer receives confirmation of an assembly date that does not exist in the team's real calendar, and cancels another commitment because of it. The customer claims a loss.

In front of the customer, the store answers, because it offered the service. Internally, the analysis depends on what the records show. If the log shows the agent checked an outdated calendar, the question moves to the integration, which is the responsibility of whoever built and maintained it. If the log shows an employee changed the agent's instructions two weeks earlier without review, the question moves to the internal change process. If there is no log, the company cannot prove anything and tends to bear the whole cost.

The same situation leads to different recourse paths depending on the evidence. Without evidence, the company also loses the ability to fix the flow.

What the records need to show

A useful record is not just a saved chat. It must allow the decision to be reconstructed. A minimum checklist for each AI flow that talks to customers or takes actions:

• The incoming message, with date and channel, and the version of the instruction or flow that was active at that moment.
• The sources consulted, such as catalog, calendar or order status, and the answer each one returned.
• The action taken, such as an offer, discount, cancellation or charge, with the amount and condition applied.
• The point where the agent handed off to a person, the reason, and who took over the conversation.
• Who changed instructions, limits or integrations, and when, with the approval recorded.

Observability practice treats these records as linked event trails rather than loose files. For agents, a shared standard for generative AI telemetry helps keep what gets recorded consistent across systems.

There is also a privacy concern. Full records contain personal data, so they need a retention period, restricted access and a defined purpose. Recording everything without criteria creates another risk, this time under the LGPD, Brazil's data protection law. The national data protection authority (ANPD) is the reference body to follow for guidance on data processing in the country.

Human approval: where to place it and where it is not needed

Human approval does not need to exist everywhere, because that cancels the gain in service speed. Its job is to protect decisions that, if wrong, cause financial damage or affect someone's rights. A simple decision guide:

• Irreversible or valuable actions, such as refunds, cancellations and discounts outside the price table: the agent prepares the proposal and a person approves it before execution.
• Answers about health, credit, legal warranty or consumer rights: the agent gives the standard procedure and routes the case to human review.
• Factual catalog information, opening hours or order status: the agent answers directly, with the source consulted recorded.
• Low-risk conversations, such as triage or booking a free slot: the agent leads, with explicit limits and a clear option to speak with a person.

One important detail: automated decisions that affect someone's interests have their own rules under the LGPD, including the right to request a review. LGPD automated decision-making and the right to review under article 20 covers that point.

The OWASP Top 10 for LLM applications lists risks such as prompt injection and excessive tool use. It does not replace legal analysis, but it shows why sensitive actions should depend on a step that text typed by a user cannot bypass.

What to request in writing from the provider

Before contracting a platform or model, the company should turn responsibility into a contract item or technical annex. Points that are commonly negotiated, with no ready-made guarantees:

• What data the provider stores, for how long, and whether it uses that data to train models.
• Where data is processed, with attention to international transfer when applicable. International data transfer with AI under the LGPD supports that conversation.
• How, and within what deadline, the provider reports incidents and model changes that alter the agent's behavior.
• Whether the company can export complete logs, in a usable format, without depending on support.
• What the liability limits are and how they apply to failures of third parties the provider relies on.

For the legal analysis of these items, the company should work with a lawyer. The AI legal framework in Brazil is still taking shape, and tracking it is part of the routine for anyone running AI with customers.

How the method reduces risk in practice

The method we apply has four steps: map, limit, pilot and hand over. Mapping means listing the current process, its decision points and where AI enters, before any configuration. Limiting means restricting data and actions to what is necessary, with permissions the agent cannot exceed. Piloting means running a real flow with logs and a success metric agreed in advance, so behavior is observed before scaling. Handing over means delivering the flow with documentation and deciding, based on evidence, whether to expand, adjust or stop.

This path does not eliminate errors, but it lets the company know where the error happened, who had authority over each action and what to change. For teams that want to test flows before exposing customers, mocks and sandboxes for testing AI agents describes how to do it without real risk.

Frequently asked questions

Does the company answer for an AI error even when the model belongs to another company?

In the relationship with the customer, generally yes, because the company is the one offering the service to the consumer. The dispute over the third-party model happens afterward, in the relationship with the provider, and depends on the contract and the evidence. That is why the company needs records of what the AI did and clear clauses on incidents.

Can the model provider be held responsible?

Yes, within the limits of the contract and the defect the provided technology actually caused. If the failure came from a configuration the company itself made, responsibility tends to rest with the company. Without logs that show where the problem originated, the company will rarely be able to claim against the provider with confidence.

Does an employee who uses AI incorrectly create liability for the company?

The company can answer to third parties for what its employees do in the course of their work, and the employee can answer internally under company rules and applicable law. A clear usage policy, stating what is allowed and what is banned, reduces occurrences and makes investigation easier.

Does human approval eliminate the risk?

It does not eliminate it, but it reduces the risk considerably for the highest-impact decisions, because it creates a review point with authority and a record. It only works if the person has enough information to decide and enough time to do so. Automatic approval without real review does not fulfill that role.

Sources

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• OpenTelemetry: observability concepts
• ANPD: Autoridade Nacional de Proteção de Dados