Who’s Liable When AI Makes the Call in Operations?

An AI agent extracts an invoice, adopts a manipulated IBAN, and releases the payment via an integration. Who is liable for AI decisions when the money ends up with the wrong recipient? Not the model. Liability starts with the people and companies that set up, approved, and operated the process without sufficient controls.

Most AI projects fail legally not because of the model, but due to unclear process accountability. If no one defines which decisions may be automated, which cases require exception handling, and who reviews logs, a foreseeable liability risk arises. This can be avoided clearly, honestly, and pragmatically—not through more technology, but through a robust operational process.

Why liability for AI decisions depends on the process

Legally, an AI does not make an independent decision for which it could be held liable. It processes data, evaluates patterns, or suggests an action. The result becomes binding only when a company integrates it into a process: for example, when a workflow blocks a payment, a voice agent confirms a contract appointment, or a system classifies a KYC case as unremarkable.

What matters, therefore, is the decision chain. Who defined the purpose? Who provides the data? Who sets the rules, thresholds, and access rights? Who may release the output? And who responds when monitoring flags an anomaly? Depending on the answers, operators, clients, software providers, service providers, or individual responsible parties may be affected. There is no blanket rule that always assigns liability to the provider or the using company.

In the invoice approval example from the introduction, the primary responsibility typically lies with the company initiating the payment. It defines the process, grants bank access, and must implement controls against payment fraud. If an external provider incorrectly implemented agreed checks or failed to fix a known error, a recourse claim may arise. However, this internal division of labor initially offers little help to the injured party.

Who is liable for AI decisions toward customers and authorities?

The answer depends on the damage and the legal area. In day-to-day operations, four levels are relevant and must be clearly separated.

Contractual responsibility remains with the contracting party

If an automated process rejects an order, calculates an incorrect price, or confirms an appointment, the key question is who entered into the contract with the customer. This company cannot simply claim the AI caused the error. An automation service provider may contractually assume liability for certain errors, but the contract distributes risks between the parties. It does not replace clear communication with the customer or a functioning correction process.

This also applies to CRM enrichment. If company or contact data is automatically supplemented and a sales team then initiates incorrect outreach, the data’s origin, timestamp, and approval rules are needed. Without this evidence, it is later difficult to determine whether a data error, incorrect assignment, or faulty rule was the cause.

Data protection law targets the responsible party

If a company processes personal data, it generally remains responsible under data protection law, even if a service provider operates the models, infrastructure, or workflow automation. Decisions that can significantly impact individuals—such as the automatic rejection of a loan application, insurance policy, or job application—are particularly critical.

For fully automated individual decisions, additional requirements apply. In practice, this means the company must justify the use, consider data subject rights, and enable effective human intervention when necessary. A button labeled “manual review” is insufficient. The reviewing person needs the case context, the authority to deviate, and enough time to actually decide.

Regulatory obligations cannot be outsourced

In banks, fintechs, and other regulated sectors, the question becomes more stringent. When a system prioritizes AML cases, extracts KYC documents, or matches KYB data, the subject-matter responsibility must not disappear into the automation workflow. The obligated company must be able to trace which data led to the classification, which rule or model was active, and who ultimately assessed a hit.

An externally operated service reduces workload but not accountability toward regulators and auditors. For identity processes, an additional rule applies: Document processing can check an ID document for missing fields, inconsistent data, or unreadable images. However, it does not automatically confirm the document’s authenticity or an eIDAS-compliant identification. This boundary must be clearly documented in the process.

Providers are not automatically liable—but not never

A provider may be held responsible if it breaches contractual commitments, delivers faulty components, causes security flaws, or fails to implement promised control mechanisms. Whether this results in a claim depends, among other things, on the contract, applicable law, the specific error, and provable damage.

The EU AI Act primarily imposes obligations for certain roles and risk classes. It does not automatically resolve every civil liability question. Those who treat it as a liability substitute or a checklist for all risks overlook the core issue: An unmonitored process remains problematic even if its technical documentation is complete.

Define the decision chain before go-live

Before integrating an AI into a business process, create a brief decision record for each use case. This is not a slide exercise but the operating manual for emergencies. Five details must be included:

1. Purpose and damage threshold: Which action may the system execute, and at what amount, risk, or customer impact must a human approve?
2. Data basis: Which source provides which data, how current is it, and how are missing or conflicting values handled?
3. Decision logic: Which rules, thresholds, model versions, and API integrations were active at the time of the decision?
4. Approval and exception handling: Who may override, who handles unclear cases, and within what timeframe must this occur?
5. Evidence and operations: Which logs are stored, who reviews monitoring alerts, and how are reconciliation, error correction, and escalation performed?

This ties liability to concrete process steps. For example, you can determine whether an incorrect payment resulted from a faulty extraction, a missing account check, or an overly broad approval rule. Without this distinction, the only useless statement remains: “The AI was wrong.”

Human-in-the-loop makes sense where a wrong decision is costly, irreversible, or regulatorily sensitive. It is not useful if employees uncritically confirm every case because the system generates too many alarms. Then the control instance is only formally present. Better is limited automation: clear cases proceed, borderline cases go to qualified reviewers, and recurring exceptions lead to rule adjustments.

Contracts must reflect operations, not just implementation

Many contracts address project scope and acceptance but not ongoing operations. Yet this is where relevant errors arise: A model is updated, a data source changes its format, or an API delivers duplicate records. Therefore, responsibilities for changes, incident reports, access, audit logs, data deletion, and recovery must be included in the agreement.

For critical processes, you should also define which uptime or SLAs are actually necessary and what happens in case of an interruption. An automation for internal appointment scheduling can be down for a few hours. A process affecting payments, blocks, or compliance cases requires a manual fallback. A system is only reliable when this fallback has been tested—not when it exists only on paper.

The liability clause in the contract must also match the risk. Blanket clauses are of little help if it remains unclear who approves changes or what data quality is owed. Have the specific legal design reviewed for your case. Operationally, however, you can create the decisive evidence yourself: versioning, approval logs, access rights, and a complete event history.

Running AI cleanly means: being able to intervene

The relevant question is not whether an AI decides error-free. No complex process works error-free. The question is whether you can detect, stop, explain, and correct an error before it causes damage.

Every productive system needs a designated process owner, monitoring with concrete thresholds, and a fixed rhythm for reviewing exceptions. For example, if the rate of manually corrected data extractions rises, this is not a minor detail. It may indicate a changed document layout, a new fraud scheme, or a faulty integration. The responsible operations team must pick up on these signals and adjust the automation.

This prevents surprises: The AI may only act within clear limits, critical decisions remain reviewable, and every deviation has an operational owner. This is less spectacular than a fully automated decision—but this is how automation becomes reliable in business.