Article · Governance & Risk
When an AI agent makes a costly mistake, who pays?
That your company answers for it is already settled. In front of your customer and in front of the regulator, the company deploying the agent is the one that shows up, and having a provider behind you does not shift that. The open question, the one almost nobody writes down, starts right after. Once the bill for the error is paid, how much of that cost can you recover from whoever built and runs the agent? The law does not settle that on the day of the incident. The contract settled it months earlier, and usually in the other party’s favour.
Two arguments, and they close at different speeds
When an agent reconciles badly and the same invoice gets paid twice, or it rejects a good order from a large account, two conversations open at once and they should not be mixed.
The first is with whoever took the damage: your customer, your supplier, your employee. That one closes the same day, you close it, and it does not entertain nuance about which software was involved. Under the European framework, providers and deployers each carry their own duties, and the regulation asks both of them to report serious incidents. Working out which role your company holds and what each one owes is the regulatory half of this question. What follows here is the financial half.
The second is with whoever built and operates the agent, and it is about money. How much of what you paid gets shared, and who has to prove it. That one can run for months and is played entirely on what you signed.
The clause missing from most operating contracts
A serious contract for an agent-run operation fixes four things: measurable outcome, permissions, traces and a clean exit. I set those out in what the contract for a managed operation must say and I will not repeat them. What I want to flag here is the fifth, the one that falls out of almost every proposal I review: what happens on the day the outcome goes wrong and costs money.
A provider can promise it answers for the outcome and never have written down what answering means. These are the questions I ask before signing, and none of them needs a lawyer to formulate:
| Question | Why it decides |
|---|---|
| What remedy applies when the process fails? | Redoing the work, crediting the period’s fee and covering the damage are three different commitments. Many contracts only carry the first. |
| Up to what amount does the provider answer? | A cap tied to your monthly fee turns any large error into your problem. Worth knowing beforehand, not during the claim. |
| What is excluded? | Indirect loss, lost profit and reputational damage are usually carved out. In a customer-facing operation, that is most of the real damage. |
| Who has to prove whose fault it was? | If the burden sits with you and the provider holds the logs, the argument is decided before it starts. |
| What does their insurance cover, and until when? | A policy that never contemplated autonomous process execution leaves the written commitment with nothing behind it. |
The answers do not have to be the ones you would prefer. They have to exist and be written down. A provider unwilling to put its liability cap on paper is telling you something useful about how much it trusts its own system.
The model lab is not your counterparty
This is where expectations tend to break. The model underneath the agent comes from a lab your company has no practical contractual relationship with. The implementer has that relationship, usually on standard terms nobody negotiates. If the error comes from a model hallucination, your lever is still the same party you signed with: whoever picked that model for that task, evaluated it and decided to deploy it.
Which is why model selection matters more than it looks. A provider that can swap the model per task and show the evaluations behind its choice is in a position to answer for that decision. One that wired your process into a single lab’s primitives has a comfortable defence when the lab changes something, and you are left without a counterparty. It is the seventh criterion that rarely appears on the lists of how to choose an AI agent provider.
When the error came from your own instruction
This is the uncomfortable part and the one I have seen decide a negotiation more than once. An agent’s supervision level, the thresholds above which it acts alone and the business rules it applies are not set by whoever builds the system. They are set by the company carrying the risk, which is the right arrangement, because nobody outside should decide how much risk your operation takes.
It has a consequence worth seeing before signing rather than after. If you raised the auto-approval threshold from 5,000 to 50,000 to speed up month-end close, an error inside that band is hard to claim back. The same holds when the agent worked on stale master data your team maintains, or applied a rule your department dictated and got wrong.
Hence a simple practice. Every change of threshold, rule or permission gets logged with a date and with who asked for it. Without that record, a year later nobody will be able to separate what the system decided from what you decided, and that separation is exactly what a claim turns on.
No trace, no claim, just two versions
All of the above rests on something installed before the incident. If you cannot reconstruct what data the agent saw, what it decided, under which rule and with which permission, you do not have a claim. You have one account against another, and in that situation whoever holds the record wins.
An agent decision trace is usually presented as a compliance tool, and it is one, but its economic value is different. It is the evidence. Which is why access to the logs, meaning that you can read and export them and not merely that they exist, is a liability clause dressed up as a technical one. A contract that hands you the outcome but not the trace leaves you unable to argue anything.
How the bill gets smaller before it happens
Most of the useful work here happens before the incident, and none of it is legal.
- Bound the possible damage by design. Per-operation and daily cumulative caps, and a human signature on anything that cannot be undone. That is what keeps any error down to a figure the board tolerates, and it is developed in AI agent permissions and controls.
- Start with reversible processes. An error in a draft that gets reviewed costs the review. The same error in an executed payment costs the payment.
- Demand the trace as a deliverable, not a favour. With your own access and exportable.
- Look at the billing unit. How a provider charges you already splits the ordinary risk of the process, which I cover in how much implementing AI agents costs. Splitting extraordinary damage, which is what this article is about, is a separate discussion and needs to be had separately.
- Count escalation as an economic control. A case that leaves the perimeter and reaches a person is what prevents the bill, even though the reports show it as work the agent could not close. The criteria are in exception handling and human escalation.
None of this is legal advice, and the wording itself needs a lawyer. It is what I review as an operator before an agent touches a process that moves money, and it sits inside the wider frame of AI agent governance. The rest of the ground, for anyone arriving here before deploying anything, is in AI agents for business.
Frequently Asked Questions
Can I pass the cost of an agent’s error on to my provider?
Partly, and only if you signed for it. You answer to the injured party; what you recover afterwards depends on the agreed remedy, the liability cap, the exclusions, and on being able to prove the failure was the system’s and not one of your rules or your data.
Does the lab that built the model answer to me?
Not to you. Your contractual relationship is with whoever builds and operates the agent, and that company chose the model, evaluated it and decided to use it for that task. Which is why it matters that it can change the model and explain why it picked the one it did.
What if the error came from a threshold we set ourselves?
You absorb it, almost always. Supervision levels and business rules are decided by the company carrying the risk, not by the provider. That is why every threshold change should be logged with a date and an owner: later, it is what separates your decision from a system failure.
Is a liability clause worth anything without the traces?
Not much. Without a reconstructable record, a claim becomes two competing accounts and whoever holds the data decides it. Access to the traces, exportable and in writing, is the part of the liability clause you can actually exercise.