Voice AI Liability: Who Pays When the Agent Gets It Wrong

An enterprise voice AI agent misquotes a price, discloses the wrong balance, books a slot it should have refused, or gives a customer regulated guidance it was never meant to give. Something goes wrong, and someone loses money. The first question in the room is rarely technical. It is contractual: who pays? The answer decides whether a single bad call is a footnote or a boardroom problem, and it is settled long before the incident, in the paperwork nobody reads twice.

Most buyers assume the vendor carries the risk because the vendor built the model. That is half right at best. The contract allocates the money through a liability cap, a set of carve-outs, and one or more indemnities. But the regulator does not read your contract. When something goes wrong in a regulated process, the Information Commissioner's Office, the Financial Conduct Authority, or the Care Quality Commission acts on the organisation that deployed the system, not the vendor that supplied it. Adoption is now near-universal, yet only about 33% of enterprises run AI in production and roughly 6% capture material value, according to McKinsey's State of AI (November 2025). As more agents reach production, the liability question stops being hypothetical.

This guide maps how liability is actually allocated in a voice AI contract, from the implied legal duty a supplier already owes, through the limitation-of-liability cap and its carve-outs, to indemnities and the insurance that stands behind them. It is written by practitioners who negotiate and deploy these systems, not by lawyers, and it is general information, not legal advice: your general counsel owns the clause, and the numbers below are market norms, not a recommendation for your specific deal.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. Or see DATS, our five-stage AI consulting system.

Who is liable when an enterprise voice AI agent gets it wrong?

Liability splits into two separate questions that buyers routinely merge. The contract decides who bears the financial cost, through a liability cap and indemnities negotiated between the AI vendor and the enterprise. Regulatory accountability is separate and non-negotiable: when a voice AI agent mishandles personal data or a regulated interaction, the regulator holds the deploying enterprise, not the vendor. A well-drafted contract shifts money. It cannot shift the duty a regulator places on you.

That distinction runs through every clause that follows, so it is worth making concrete before we open the contract. If your voice agent leaks personal data, the ICO enforces against you as the controller. If it gives unsuitable financial guidance, the FCA looks at your firm. If it mishandles a care enquiry, the CQC looks at your service. Your vendor may owe you money for causing the failure, and a good contract makes sure it does. But the enforcement notice, the fine, and the reputational damage land on the organisation whose name was on the call. We wrote about the underlying control-versus-processing question in our guide to whether your voice AI makes you a controller or processor under Article 28, and the split matters here too: being a processor's customer does not make the processor answerable to your regulator on your behalf.

The practical takeaway is to negotiate the money hard and to govern the accountability separately, because no clause you sign will make the regulator someone else's problem. That is why liability allocation belongs in the same conversation as your AI operating model, not just in procurement.

What does an AI voice vendor's limitation of liability clause actually cap?

A limitation-of-liability clause sets the maximum the vendor will pay if its system causes you loss. In enterprise SaaS, the cap is commonly the fees paid in the trailing twelve months, sometimes a multiple of them. It usually excludes indirect and consequential losses entirely, and it defines what counts as direct loss narrowly. For a voice AI deployment, that means the vendor's exposure is often a fraction of the damage a bad call at scale can cause.

Read the cap as a number and a shape. The number is what the vendor will pay; the shape is what it will pay for. A twelve-month-fees cap on a contract worth a modest monthly sum can be small against, say, the cost of remediating thousands of mis-handled calls or a regulatory investigation. The shape matters more: most caps exclude "indirect, consequential, special or punitive" damages and lost profits, which is where the real cost of a voice AI failure usually sits. Under the Unfair Contract Terms Act 1977, a limitation clause in a business contract must be reasonable to be enforceable, and liability for death or personal injury caused by negligence cannot be excluded at all, so an aggressive cap is not automatically watertight. The right posture is to size the cap against plausible harm, not against the licence fee, and to treat an uncapped, un-negotiable "as is" contract as a signal about how the vendor sees the relationship. Read it alongside the service levels that actually bind, because a cap and a service credit are sibling mechanics that either fire or do not.

The duty of care a supplier already owes

Before any cap or indemnity, an English-law supplier already owes an implied duty. In a business-to-business services contract, the Supply of Goods and Services Act 1982 implies a term that the supplier will perform with reasonable care and skill, whether or not the contract says so. That baseline duty is what a liability claim against a voice AI vendor is usually built on: the argument that the service fell below reasonable professional standards. The cap limits what the vendor pays for breaching it; it does not remove the duty.

The statutory language is worth quoting precisely, because it is the foundation the rest of the contract sits on:

In a relevant contract for the supply of a service where the supplier is acting in the course of a business, there is an implied term that the supplier will carry out the service with reasonable care and skill.

That is section 13 of the Supply of Goods and Services Act 1982, the business-to-business implied term. Its consumer-facing counterpart is section 49 of the Consumer Rights Act 2015, which treats every consumer service contract as including a term that "the trader must perform the service with reasonable care and skill". For most enterprise voice AI deals the 1982 Act is the relevant one, and it means the vendor cannot contract out of competence entirely. What "reasonable care and skill" requires of an AI system is an unsettled question, which is exactly why the written contract, and your own honest diligence before you deploy, carry so much weight.

Which liabilities are carved out of the cap?

Carve-outs are the liabilities a cap does not apply to, where exposure is uncapped or capped separately at a higher figure. In enterprise contracts they typically cover breach of confidentiality, infringement of intellectual property, personal-data breaches, and death or personal injury caused by negligence. For voice AI, the data-breach carve-out is the one that matters most, because a voice agent handles personal and often special-category data on every call, and that is where the largest single loss usually hides.

Treat the carve-out list as the real risk map of the deal. A vendor that accepts an uncapped or super-capped data-breach carve-out is telling you it stands behind its security; one that refuses is telling you the opposite. Confidentiality and IP carve-outs are standard and rarely contentious. The data-protection carve-out is where voice AI contracts are won and lost, and it should be read alongside your data processing agreement and your voice AI DPIA, not in isolation. A cap of twelve months' fees on the licence, sitting next to an uncapped indemnity for a personal-data breach, is a far stronger position than a single high cap covering everything, because it puts the vendor's money exactly where the worst harm is.

How do indemnities differ from the liability cap?

An indemnity is a promise by one party to cover the other's losses from a defined type of third-party claim, usually pound-for-pound and outside the general cap. The liability cap limits what a party pays for its own breaches; an indemnity is a separate, targeted commitment. In voice AI contracts the common indemnities run from vendor to buyer for intellectual-property infringement and, where negotiated, for data-protection breaches, and from buyer to vendor for platform misuse.

The difference is direction and trigger. A cap is defensive and general: it applies to whatever claims arise, up to a ceiling. An indemnity is offensive and specific: it fires when a named event happens, such as a third party suing you because the vendor's model infringed a patent, and it typically sits above or outside the cap so the protection is meaningful. When you negotiate a voice AI contract, the indemnities are where you convert "the vendor is responsible" from a sentiment into a mechanism. The same clause discipline shows up in our guide to voice AI SLAs: a right without a mechanism that fires is decoration. Get the IP indemnity and, if the vendor will accept it, a data-protection indemnity written so they actually pay, rather than a cap that quietly swallows the claim.

Does a vendor indemnity remove the enterprise's regulatory accountability?

No. An indemnity moves money between vendor and enterprise; it does not move the duty a regulator places on you. If a voice AI agent causes a personal-data breach, the ICO can fine the controller up to £17.5 million or 4% of total annual worldwide turnover, whichever is higher, and that liability rests with the deploying organisation regardless of any indemnity. The vendor's indemnity may reimburse the cost. It cannot make the regulator pursue the vendor instead.

This is the point where the two questions we separated at the start come back together, and it is the single most misunderstood part of voice AI risk. The same logic governs who answers when a decision is challenged: our guide to automated decisions under UK GDPR Articles 22A to 22D sets out the accountability the deployer keeps, and it is not something a supplier clause can absorb. Sector regulators reinforce it. The FCA holds a regulated firm accountable for outcomes even where a supplier operates the technology; the CQC holds a registered provider accountable for the safety of a service it delivers through an agent. An indemnity is genuinely valuable, because being reimbursed matters. But you should design your deployment, your monitoring, and your AI execution office on the assumption that the accountability is yours to keep, and buy the indemnity to cover the cost when it bites.

Where do professional indemnity and cyber insurance fit?

Insurance is what stands behind the cap and the indemnity when a claim actually lands. A vendor's promise to indemnify you is only as good as its ability to pay, so the practical question is whether it carries adequate professional indemnity, technology errors-and-omissions, and cyber cover, and whether those policies would respond to an AI-caused loss. On your own side, cyber and professional indemnity insurance sit behind your retained regulatory and operational exposure, the part no vendor clause removes.

Two checks earn their place in diligence. First, ask the vendor to evidence its insurance limits and confirm the policies are not written to exclude AI or automated decision-making, an exclusion that is becoming more common as insurers reprice AI risk. An indemnity backed by a policy that excludes the very thing that went wrong is worth little. Second, review your own cover against the accountability you keep: because the regulator pursues you, your insurance, not the vendor's, is the backstop for your fines-adjacent costs, defence, and remediation. Insurance does not change who is accountable. It changes whether the party that is accountable can afford the consequences, which is why it belongs in the liability conversation and in your broader DATS methodology for deploying AI responsibly.

What happened to the EU AI Liability Directive, and what governs liability now?

The proposed EU AI Liability Directive was withdrawn. The European Commission flagged it for withdrawal in its 2025 work programme and formally withdrew the proposal in October 2025, having found no agreement between member states. There is now no dedicated, harmonised EU civil-liability regime for AI. Liability for a voice AI failure now falls back to national contract and tort law, the deployer and provider duties in the EU AI Act, and, above all, the contract you signed.

For an enterprise, the withdrawal makes the contract more important, not less, because the safety net people assumed was coming is not arriving. You can read the official status on the European Parliament's legislative train schedule, which records the file as withdrawn. The EU AI Act still splits obligations between the provider that builds a system and the deployer that puts it into use, so an enterprise running a voice agent carries deployer-side duties whatever the vendor does. And UK common law plus the Supply of Goods and Services Act 1982 continue to set the baseline for services delivered here. The absence of a special AI liability statute does not mean no liability. It means the ordinary rules, and your negotiated clauses, decide the outcome. This is one more reason the in-house, vendor or hybrid operating-model decision should account for where liability lands under each model.

What is the best way to allocate voice AI liability in 2026?

There is no single best allocation, only the right one for the deployment's risk profile. The best structure for a high-stakes, regulated voice AI programme is a cap sized against plausible harm rather than the licence fee, uncapped carve-outs for data breach and IP, a data-protection indemnity that actually fires, and evidence of AI-inclusive insurance behind it. For a low-risk, low-volume deployment, a standard capped contract is often perfectly reasonable, and pushing for bespoke terms wastes leverage.

Vendor posture predicts the deal you will get. Self-serve platforms such as Vapi, Retell AI, Synthflow and Bland AI are built for speed and scale, and typically offer standard-form, "as is" contracts with tight caps and little appetite to negotiate indemnities: excellent for prototypes and lower-risk lines, less comfortable when the calls are regulated. Managed and enterprise-focused providers such as PolyAI and Dilr Voice more often negotiate real allocation, because the deployments are higher-stakes and the relationship is longer. The honest concession is that for a genuinely low-risk use case, the self-serve, standard-cap route can be the better commercial choice, and paying for negotiated liability terms you do not need is its own kind of waste. The decision belongs with the platform-selection work in our guide to voice AI platform selection criteria, not bolted on afterwards. Match the liability terms to the stakes, and read them before, not after, an incident forces the question.

Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside enterprise systems.

Can a vendor cap its liability to the fees paid?

Yes, and in enterprise SaaS the cap is commonly the fees paid in the trailing twelve months. It is not unlimited freedom, though. Under the Unfair Contract Terms Act 1977, a limitation clause in a business contract must satisfy a reasonableness test to be enforceable, and negligence liability for death or personal injury cannot be excluded at all. A cap that is plainly inadequate against foreseeable harm can be challenged, so the number is negotiable, not fixed.

Who is liable if the voice AI gives incorrect regulated advice?

The deploying enterprise faces the regulator, and the contract decides whether it can recover the cost from the vendor. If a voice agent gives unsuitable financial guidance or a wrong clinical instruction, the FCA or CQC holds the regulated organisation accountable for the outcome, not the AI supplier. A vendor indemnity may reimburse the loss, but accountability stays with the deployer, which is why regulated voice AI needs governance, not just a strong clause.

Reading the contract before the incident

The pattern across every clause is the same. The liability cap, the carve-outs, the indemnities and the insurance decide who pays, and they are worth negotiating hard, because the difference between a twelve-month-fees cap and a properly structured allocation is often the difference between a manageable loss and an unfunded one. The one thing none of them changes is who the regulator holds accountable, which is always the organisation that deployed the agent. Buy the money protection, and govern the accountability as if it can never be transferred, because it cannot.

Practically, that means three things before signing. Size the cap against plausible harm, not the licence fee. Put uncapped or higher-capped carve-outs and a real indemnity where the worst harm sits, which for voice AI is almost always personal data. And design the deployment, the monitoring and the escalation on the assumption that accountability is yours, using the in-house versus vendor operating model and, where you are leaving a supplier, the discipline in our voice AI vendor-exit guide. Do that, and the liability conversation stops being the thing that surprises you after a bad call and becomes the thing you settled on purpose. If you want a second pair of eyes on where the risk actually sits in your voice AI programme, that is what our strategy work and an execution-office review are for, and it is a good use of a short conversation with our team.

For the wider picture of how these clauses sit inside procurement, governance and deployment, our writing on voice AI auditability and explainability and about Dilr.ai covers the ground a general counsel and a head of operations usually need to walk together before a voice agent goes live on the Dilr Voice platform.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.