Who is liable for AI errors?

An AI system rejects a legitimate loan application, assigns an invoice to the wrong supplier, or provides incorrect information to a customer. The damage doesn’t originate with the model. It occurs where an incorrect result—without verification—triggers a business decision. Who is liable for AI errors? There is no blanket answer. What matters are the roles, contracts, damages, causes, and, crucially, who actually controlled the process.

Most AI projects fail not because of the model, but because of the process surrounding it. If no one has defined when a result is approved, which exceptions are stopped, and who responds in case of a failure, liability becomes difficult to assign later. This can be clarified pragmatically before go-live.

Why AI errors rarely have a single responsible party

Legally and operationally, an AI error is not a distinct category of damage. Depending on the case, contract law, tort law, data protection law, product liability, and—in regulated sectors—additional supervisory rules apply. In Germany and Austria, individual legal bases differ, but the assessment framework is similar: Who had which duty? Was it violated? Did this cause damage? And can the connection be proven?

Take a concrete example: A document processing system extracts the wrong IBAN from an invoice. A workflow automation passes the value via API to the ERP, the payment is triggered, and the money goes to the wrong account. The language model or extraction model may be the technical source of the error. But the liability question doesn’t end there.

The operator must explain why a payment was possible without cross-checking against master data. The implementation partner must demonstrate whether the agreed validation was built in. The software provider must stand by promised functions and possible product defects. Employees may be affected if they ignored obvious warnings. Toward the damaged contractual partner, the company using the process is often initially responsible.

This is the uncomfortable but honest starting point: A contract with an AI provider does not fully shift responsibility for your customer process to an external party.

Operators, providers, and employees: Who bears which risk?

The operator is responsible for concrete use

Whoever integrates an AI system into their own processes decides on the purpose, input data, approval rules, and scope of action. This creates operational responsibility. For example, with a voice agent in customer service: The company defines which issues the agent can resolve independently and which topics require handoff to a human.

The more consequential the decision, the tighter the control must be. A suggestion for an internal text summary requires different rules than an automated termination, credit decision, or AML escalation. In KYC and KYB processes, for instance, a system should be able to extract document data and flag inconsistencies. The final decision in unclear identity cases remains with the human-in-the-loop until the error rate and exceptions are measurably under control.

Data protection obligations also typically fall on the operator as the responsible party if they determine the purposes and means of processing. If personal data is processed without a lawful basis, stored too long, or transmitted to unauthorized recipients, pointing to an external model is not sufficient.

The provider is not liable for every business damage

A provider may be liable if their service is defective, promised features are missing, security or documentation obligations are violated, or they culpably breach contractual duties. What applies in detail depends on the contract and applicable law. General statements like “the model can make mistakes” do not replace a clear description of performance.

What matters, then, is what was specifically agreed: Which data does the system process? What recognition rate was tested for which document type? What availability applies? Who monitors the integrations? How quickly is an incident addressed? And which damages are limited or explicitly excluded in the contract?

With standard software and embedded AI components, product liability rules may also apply. The European Product Liability Directive has been expanded; its implementation is national. For your specific case, it’s not just whether a model was technically wrong, but also whether a product was defective and whether that defect caused the damage. For high damage amounts, you should have this legally reviewed instead of relying on marketing statements.

Employees need rules, not just access

Employees are generally not liable to third parties for every operational error instead of the company. Internally, breaches of duty may play a role, with labor law and degree of fault being decisive. Practically, something else is more important: A team should not have to guess when they can trust an AI result.

Therefore, don’t give a general instruction like “please check.” Define verifiable criteria: For invoices above a set amount, for new bank details, or for discrepancies between supplier name and account holder, the process is halted. This makes control reliable and reduces disputes over whether a warning was recognizable.

What the EU AI Act changes about liability—and what it doesn’t

The EU AI Act does not automatically create a single liable party for every AI-related damage. It primarily assigns duties along the supply chain—for providers, operators, importers, and distributors. Depending on the risk category, these duties range from transparency notices to risk management, logging, human oversight, and documentation for high-risk systems.

For companies in DACH, the practical consequence is clear: Whoever uses a system in a regulated or high-stakes process needs traceable documentation. This includes the intended purpose, known limitations, test cases, approval rules, logs, and a procedure for complaints or corrections. However, the AI Act does not replace a clean contractual liability arrangement or the obligation to handle damages under national civil law.

For credit decisions, employment, biometric identification, or certain government applications, classification as a high-risk system may be relevant. For an internal knowledge search or text assistance, it usually is not. Decide based on the actual use, not the provider’s label.

Distribute liability operationally before go-live

Liability is not manageable through a single clause in the terms and conditions. It becomes manageable through a process that, in case of an error, shows what happened and who had to react. Before launch, you should at least answer these five questions in writing:

• Which decisions does the system make itself, which does it only prepare, and which must remain strictly with a person?
• Which inputs, document types, and data sources are permitted, and which cases are immediately treated as exceptions?
• Which controls catch typical errors, such as plausibility checks, master data reconciliation, four-eyes approval, or reconciliation?
• Who owns the process functionally, who operates the technical pipeline, and who is responsible for an incident within what timeframe?
• Which evidence is stored so that you can reconstruct the input, model version, result, approval, and subsequent correction?

These questions are not bureaucratic add-ons. They distinguish an assistant that makes suggestions from an automation that moves money, changes contracts, or influences customer decisions. As the impact increases, so do the depth of testing, the degree of control, and the need for documentation.

A sensible start is a limited process with a clear error class. For data extraction from incoming invoices, for example, you can measure for three weeks how many fields are correctly recognized, how many exceptions occur, and which errors slip through despite the rules. Only when the rate is measurable per document type do you define which cases proceed automatically. This is pragmatic because the control effort is tied to real risks.

Contracts must reflect the operation

A robust contract doesn’t just describe software access. It describes the operation. This includes responsibilities for data quality, workflow adjustments, tests after model or prompt changes, incident reporting, log access, deletion, and exit. If a service provider manages automation operations, it should also be clear what monitoring times, uptime targets, and SLAs apply—and what happens outside those times.

A particularly common gap is a rule for changes. A new model, a modified prompt, or an additional integration can alter the behavior of an established process. Therefore, define which changes require retesting, who approves them, and how a rollback is performed. For payment, KYC, or AML processes, a change should not go into production without documented approval.

Also, don’t demand unrealistic guarantees like “error-free.” Demand concrete commitments: defined inputs, tested acceptance criteria, response times, and traceable logs. This doesn’t create absolute security, but it prevents surprises when an error occurs.

Error handling determines the actual damage

An incorrect AI result isn’t always avoidable. An uncontrolled error often is. That’s why exception handling belongs in the process: Does the system stop if data is missing? Does it flag low confidence? Can an employee correct the process? Are corrections evaluated so the same error class doesn’t recur a hundred times?

Monitoring must observe the business process, not just technical availability. A service can be reachable and still write incorrect data to a CRM. Meaningful metrics are therefore not just uptime, but also the share of automatically completed cases, the exception rate, time to correction, and the number of subsequently reversed transactions. Only such values make the operation measurable.

At CINDR.LA, we therefore view automations as systems that someone operates: with responsibility, monitoring, change processes, and clear handoffs. This is less spectacular than a demo video, but it’s the prerequisite for a process to run reliably even after the first month.

The right question is not whether AI can make mistakes. It’s: Which error is allowed to proceed to what point, who detects it, who stops it, and what evidence remains afterward? If you answer this clearly before launch, liability won’t disappear. But it will become operationally manageable.