Voice AI MSA: The 11 Clauses Enterprise Legal Demands

The voice AI vendor MSA arrives looking like a software-as-a-service contract. Enterprise legal redlines it like one. Six months later — when the deployment hits its first hallucination incident, its first regulator query, or its first CFO question about who owns the call transcripts — the contract is silent on the things that matter.

The mistake is treating the voice AI master services agreement as a SaaS deal. It isn't. A voice AI deployment carries obligations that standard SaaS contracts don't carry: regulatory indemnity under EU AI Act Article 50, the ICO AI Code of Practice and the FCA's 2026 Code of Conduct extension; hallucination liability with material P&L exposure; transcript IP that becomes evidence in a regulator audit; and latency SLAs that, unlike uptime, materially change whether the agent functions at all.

This post is the 11-clause checklist that closes those gaps. Each clause includes what enterprise legal should demand, what is reasonable to negotiate, and what makes us walk from a vendor. These are the clauses we've seen survive procurement at enterprise voice deployments and the ones we've seen omitted from vendor templates we've redlined.

This guide is published by the team behind Dilr Voice — enterprise voice AI live across regulated UK and EMEA deployments. The 11 clauses below are derived from MSAs we've redlined, negotiated, and shipped. For procurement-stage support see DATS, our enterprise AI consulting practice.

The economic gap between the 88% using AI and the 6% capturing material EBIT impact does not close at the demo. It closes — or doesn't — in the contract. The MSA decides whether the deployment can be governed, audited, repriced, exited, and defended in front of a regulator. Below is the clause-by-clause architecture that makes it possible.

Why a voice AI MSA isn't a SaaS MSA

Standard SaaS contracts assume three things that are wrong for voice AI. They assume the vendor processes the customer's input data in a stateless way; they assume uptime is the operational SLA that matters; and they assume the regulatory perimeter is contained inside data protection law. None of those is true for an enterprise voice deployment.

The regulatory perimeter is wider. A voice AI deployment in 2026 sits inside at least four overlapping regimes. EU AI Act Article 50 transparency enforces from 2 August 2026. The ICO's UK AI Code of Practice on automated decision-making has been in force since 12 May 2026. The FCA's Code of Conduct extension to AI-assisted communications extends from 1 September 2026. The US TCPA, refreshed by the FCC's February 2024 ruling on AI-generated voice calls, governs every outbound campaign that touches a US number. Each of those regimes can issue a fine the size of the entire deployment budget. The MSA has to specify, in writing, which party carries that risk and how.

The operational SLA is different. Voice agents fail not by going down — they fail by responding slowly or by responding wrongly. Sub-500ms latency at P95 is the difference between a working agent and an unworkable one. Containment rate, accuracy, hallucination rate, and escalation correctness all matter more than uptime. A SaaS MSA that promises "99.9% uptime" gives the buyer nothing.

The data layer is evidence, not telemetry. Call recordings and transcripts in a voice AI deployment are not just product usage data. They are evidence — in a regulator audit, in an SRA conflicts check, in an FCA Consumer Duty review, in a court-disclosure exercise. The MSA must give the buyer ownership, retrieval rights, and a tamper-evident format. SaaS template language doesn't.

Hallucination liability has no equivalent in SaaS. A spreadsheet doesn't make things up. A voice agent can. The legal regime for that liability is unsettled — and exactly because it is unsettled, the contract has to allocate it explicitly, or the vendor will take the default in their favour. We've covered hallucination as a procurement gate separately; here, we put the contract clause into the MSA itself.

Get the 11 clauses below into the voice AI MSA before signature. After signature, every one of them becomes a renegotiation with a vendor who no longer has competitive pressure to give ground.

The 11 clauses, in order

1. IP ownership of transcripts, recordings, and call metadata

The enterprise must own the outputs of every call its voice AI handles — full transcripts, audio recordings, structured call metadata (timestamps, caller identifiers, sentiment scores, escalation flags), and any derived analytics. The vendor is a processor under data protection law and a service provider under IP law. Neither role grants ownership of the customer's call data.

What to demand: "Customer shall be the sole and exclusive owner of all Call Outputs, including without limitation transcripts, audio recordings, call metadata, sentiment scores, and any derived analytics. Vendor shall have only such limited licence as is strictly necessary to provide the Services."

What vendors will push back on: "we need a perpetual licence to use Call Outputs to improve our service." That is the model-training clause dressed up in service-improvement language. Reject the perpetual scope; if vendor wants to use Call Outputs for service improvement, it must be opt-in, time-bound, and per-tenant — see Clause 2.

Why this matters: regulators, courts, and acquirers will all want to know who owns the call data. If the contract is ambiguous, the vendor's standard terms will fill the gap — usually in their favour.

2. Model training data exclusion (opt-in, never default)

This is the highest-leverage clause in the MSA. Voice AI vendors are commercially incentivised to use enterprise call data to improve their models. Some vendors do this by default; others ask for opt-in. The default should always be exclusion.

What to demand: "Vendor shall not use Customer Data — including without limitation transcripts, audio recordings, and call metadata — to train, fine-tune, evaluate, or otherwise improve any model, whether vendor's own model or any third-party model, except where Customer has provided express written opt-in for a specific, time-bound, and per-tenant use case."

Three reasons this is non-negotiable. First, voice data may include biometric special category data under GDPR Article 9 — using it for training without Article 9 lawful basis exposes both parties to enforcement. Second, training data leakage is a known model failure mode; the enterprise's call data could surface in another customer's calls. Third, this is the clause that protects the enterprise's competitive advantage — call data captures proprietary sales scripts, objection handling, customer-specific terminology.

What vendors will push back on: "we use Customer Data only in aggregate and anonymised form." Aggregation and anonymisation are not GDPR-compliant lawful bases in their own right. They are techniques applied to data that already has a lawful basis. The MSA needs the lawful basis, not the technique.

3. Sub-processor controls

The voice AI vendor will sub-process: with an LLM provider, a TTS provider, a telephony provider, sometimes a hosting provider. The MSA must contain a sub-processor schedule listing every sub-processor by name, the data they receive, and the lawful basis for that transfer.

What to demand: a current sub-processor list as an MSA schedule; 30-day prior written notice of any change; a contractual right to object to a new sub-processor; vendor's commitment to bind every sub-processor to the same data protection obligations under Article 28 GDPR.

What vendors will push back on: "the sub-processor list is on our website and may change without notice." That position is incompatible with Article 28(2) GDPR for EU customers and with the ICO's expectations under the UK data protection regime. For enterprise buyers, walk if a vendor refuses to bind sub-processor changes to written notice.

A live example: when ElevenLabs launched on-premise deployment in April 2026, part of the customer demand they were responding to was sub-processor control. Enterprise buyers wanted to know — and contractually pin — exactly which LLM and TTS providers were in the call path.

4. Hallucination liability and definition

Define what hallucination is. Allocate who is responsible when it happens. Specify what the financial consequences are. Without this, the vendor's default position is that hallucination is the customer's deployment risk, not the vendor's product defect.

What to demand: a contractual definition of hallucination ("any Output that asserts a fact contradicted by Customer's verified data sources, where such Output is presented as factual rather than as a probability"); a liability framework that holds vendor responsible for hallucinations arising from the model layer (where vendor controls the architecture) while making customer responsible for hallucinations arising from the prompt or knowledge-base layer (where customer controls the input); service credits for hallucination rates above a contractually defined ceiling; an uncapped liability carve-out for any hallucination that triggers a regulatory fine attributable to vendor's model behaviour.

This is the clause vendors will try hardest to dilute. Their preferred position is "voice AI is probabilistic; we cannot warrant correctness." That's true at the technical level and irrelevant at the commercial level. The customer is paying for a system that works. The MSA has to say what working means.

Pair this clause with a hallucination procurement gate at vendor evaluation, so the buyer knows what number to negotiate the SLA threshold against.

5. Regulatory indemnity (one-way, uncapped for vendor breach)

The four overlapping regulatory regimes — EU AI Act, ICO Code, FCA Code, TCPA — each carry fines that can exceed the MSA's total contract value. The MSA must allocate that risk explicitly.

What to demand: a one-way indemnity from vendor to customer for any regulatory fine, penalty, or enforcement cost arising from vendor's failure to perform its specified obligations under the MSA. Specifically: failure to deliver Article 50 disclosure in the way the MSA defines; failure to provide the audit log specified in Clause 8; failure to honour the retention and deletion requirements in the DPA schedule; failure to maintain sub-processor compliance under Clause 3. The indemnity should be uncapped for these specific vendor-controlled failure modes.

What vendors will push back on: "we will provide mutual indemnity, with a cap at fees paid in the prior 12 months." Mutual indemnity makes no sense — the customer doesn't control vendor's product behaviour. The 12-month-fees cap is a vendor-friendly default. The right structure is a one-way indemnity, uncapped for the specific failure modes vendor controls.

This is the clause that law firms procuring voice AI for client intake get right by default, because they live the indemnity logic professionally. Most other enterprise legal teams accept the SaaS-default mutual structure without realising what they've conceded.

6. Data Processing Agreement schedule — UK + EU GDPR specific

The MSA should attach a DPA as a schedule, not reference one by URL. URL-linked DPAs change without notice; schedule-attached DPAs require written amendment. For voice AI specifically, the DPA must contain:

• Article 28 GDPR processor obligations, both for UK GDPR (post-Brexit) and EU GDPR, where vendor processes data in either jurisdiction.
• A specified lawful basis for processing — typically Article 6(1)(b) (contract) for customer-side processing and Article 6(1)(f) (legitimate interest) for vendor's own service-improvement processing, with explicit balancing tests documented.
• Article 9 special category language where the voice deployment may capture biometric data (sentiment analysis, tone analysis, voice authentication all potentially qualify).
• International data transfer clauses — Standard Contractual Clauses (SCCs) for transfers from EU to third countries, UK International Data Transfer Agreement (IDTA) or UK Addendum for transfers from UK, both updated to the current 2024/2025 versions.
• Retention and deletion clocks for each data category — recordings, transcripts, model logs — referencing the five retention clocks that sit on top of EU data residency.
• DPIA obligations: vendor confirms it has completed its own DPIA for the service and will support customer's DPIA on request, including under EU AI Act Article 27 where the deployment is high-risk.

What vendors will push back on: "our standard DPA at vendor.com/legal/dpa applies." Reject. The schedule must be physically attached and version-locked.

7. Latency SLA with material service credits

The operational SLA is not uptime. It is latency. A voice agent that responds in 2.3 seconds is a broken product even if it's "up". The MSA must define latency precisely, measure it correctly, and attach service credits that have material teeth.

What to demand: latency measured as end-of-user-utterance to start-of-agent-response, measured at the P50, P95, and P99 percentiles, over a rolling 30-day window. Specified thresholds (typical enterprise floor: P95 ≤ 800ms, P99 ≤ 1500ms — adjust per use case). Service credits scaled to breach severity (5% / 10% / 25% of monthly fees depending on percentile breach and duration). The right to terminate without cause if P95 exceeds the threshold for three consecutive months.

Vendors will quote latency in marketing material at sub-500ms. The MSA must specify how that number was measured and require the same measurement methodology in production. Otherwise vendor's "500ms" can become 800ms in production because the measurement window or the latency component definition changed. Latency benchmarks under barge-in conditions are particularly worth pinning, because barge-in is where most latency claims fail in production.

8. Audit rights with reasonable notice and breach-driven cost-shifting

The customer needs the right to audit vendor's compliance with the MSA on reasonable notice — typically annual right with 30 days' notice. The audit should cover technical controls (encryption, access logs, sub-processor compliance), data protection (DPA performance), and the service-level commitments (latency, hallucination rate, containment).

What to demand: annual audit right; 30-day notice; vendor to bear audit costs where the audit reveals a material breach; right to use an independent third-party auditor (with reasonable confidentiality obligations); audit-trail retention by vendor of at least 12 months of logs.

What vendors will push back on: "we provide SOC 2 Type II reports; no further audit needed." SOC 2 is a useful baseline but it is not a contractual audit right. The two are not substitutes. The MSA should accept SOC 2 as evidence of certain controls and reserve the audit right for vendor-specific commitments that SOC 2 does not cover — most importantly the auditability of the model's decisions, which is in scope for ICO and EU AI Act expectations but is not in any standard SOC 2 framework.

9. Exit assistance and data portability

The voice AI MSA must specify what happens at termination. The customer must be able to leave with its data and its configuration. Without this clause, the customer is locked in by friction even if the contract is technically terminable.

What to demand:

• Data portability: customer can export, in a non-proprietary machine-readable format (typically JSON or CSV), all Call Outputs, including transcripts, recordings, metadata, and analytics, at any point during the contract and within 60 days of termination.
• Configuration portability: customer can export prompt configurations, intent definitions, escalation rules, integration mappings, in vendor-neutral form, so they can be ported to a successor system.
• Audit logs: customer can export the full audit log (Clause 8 retention) at termination.
• Deletion: after the export period, vendor confirms in writing that all customer data has been deleted from production and backup systems within a specified period (typically 30 days post-export).

What vendors will push back on: "we will export data in vendor's standard format on reasonable request." That's not portability. The format must be specified and the export must be on-demand.

10. Transition services on termination

Distinct from data portability. Transition services are the operational support the vendor provides while the customer migrates to a successor system. Without this, vendor can technically comply with the exit clause while making the actual transition unworkable.

What to demand: a 6-month transition services period at locked pricing (the prevailing rate at termination, not vendor's current rate); a defined transition workplan to be jointly agreed within 30 days of termination notice; vendor staffing commitments (a named transition manager, response SLAs for transition issues, escalation path); a right for the customer to extend the transition period in 90-day increments at the same locked pricing.

This clause matters most when termination is acrimonious — disputed performance, regulatory failure, acquisition by a competitor. Vendor's commercial incentive at that point is to make transition as painful as possible. The MSA must remove that lever.

A real risk in 2026: vendor consolidation in the voice AI market means the buyer's vendor today may be acquired by their competitor tomorrow. Transition services language is the protection.

11. Service credits with teeth — not lip service

The standard SaaS service-credit model gives the customer 5% of monthly fees if the vendor misses uptime by a measurable amount. That model is structurally weak for voice AI: it caps vendor's exposure at a number too small to materially change vendor's behaviour, and it routes the credit through a redemption process that creates further friction.

What to demand: service credits scaled to material levels — 25% or more of monthly fees for material breach; automatic credit issuance (not customer-application-required); credits apply against the next invoice rather than requiring redemption; a chronic-breach trigger (typically: three breaches in any rolling 90 days converts the credits into a termination-without-cause right); a separate, higher service-credit schedule for the regulatory-impact clauses (Article 50 disclosure failure, ICO Code breach attributable to vendor).

What vendors will push back on: "service credits are capped at 10% of monthly fees and are the customer's sole and exclusive remedy." Reject the "sole and exclusive remedy" framing — it converts the service credit into a liability cap by another name. Service credits should be a remedy in addition to, not in place of, the customer's other rights including termination and damages.

The four clauses that actually decide procurement

Of the 11, four are deal-decisive. If vendor refuses to engage substantively on any of these four, walk and find a vendor that will.

Clause 1 (IP ownership of outputs) — because anything else means the customer's call data is captive.

Clause 2 (model training exclusion) — because anything else means vendor builds its product on the customer's commercial confidentiality.

Clause 5 (regulatory indemnity, one-way) — because anything else means the customer carries the regulatory risk of a vendor failure mode the customer cannot control.

Clause 7 (latency SLA with credits) — because anything else means the operational definition of "working" sits with vendor's marketing rather than the customer's contract.

The other seven are negotiable in degree, not in principle. The four above are the procurement gate. We've seen enterprise buyers signal this clearly by structuring their RFI/RFP around these four — and seen procurement timelines compress materially when the four are non-negotiables. Enterprise voice AI vendor evaluation and vendor selection criteria cover the broader procurement structure; this post is the contract-stage backstop.

Sector calibration — what changes by industry

The 11 clauses are the floor. Specific sectors layer additional, sector-specific obligations on top of the floor. The table below sets out the dominant additional clauses by sector — derived from MSAs we've redlined in 2026.

Sectors not listed inherit the 11-clause floor without additional sectoral overlay. But every sector should still pressure-test against the 11. A retailer deploying inbound customer service voice AI has the same regulatory perimeter for transcripts, recordings, model training, and hallucination as a bank — what changes is the magnitude of the worst-case fine, not the architecture.

The procurement red flags

If you see any of the following from a vendor during contract negotiation, you have learned something important about how that vendor will behave in production.

1. Vendor refuses to define hallucination contractually. Translation: vendor will not be accountable for hallucinations. If a hallucination causes a regulatory fine or a customer-service escalation, vendor will argue the model is probabilistic and the loss is the customer's.

2. Vendor pushes mutual indemnity for regulatory breach. Translation: vendor is positioning its own regulatory failures as a shared risk. They're not shared — vendor controls vendor's product, customer controls customer's deployment. The indemnity should be one-way.

3. Vendor offers uptime SLA but no latency SLA. Translation: vendor will be measured on something that is technically easy to honour but operationally meaningless. The customer ends up with a working API that produces an unworkable voice agent.

4. Vendor's model-training clause is opt-out rather than opt-in. Translation: vendor's default position is "we use your data." Opt-out clauses tend to involve form-based processes the customer's procurement team won't complete, and the data ends up in training by default.

5. Vendor refuses to commit on the sub-processor list. Translation: vendor wants the flexibility to change LLM providers, TTS providers, telephony providers, or hosting locations without giving the customer the chance to object. That flexibility is a sub-processor risk surface for the customer's data protection obligations.

6. Vendor offers "industry-standard" service credits at 5% with sole-remedy framing. Translation: vendor's exposure is capped at a level too small to change behaviour. The "sole and exclusive remedy" framing converts this into a liability cap the customer never explicitly agreed to.

Each of these is solvable. Vendors meet enterprise requirements when enterprise procurement teams hold the line. The challenge is that most enterprise procurement teams haven't seen enough voice AI MSAs to know what the floor should look like. This post is the floor.

Where this fits in the broader procurement architecture

The 11 clauses close the contract-stage risk. They don't close the upstream risk — which sits in vendor selection — or the downstream risk — which sits in deployment operations. The full architecture is:

• Vendor evaluation — the enterprise voice AI vendor checklist covers what the buyer should ask in RFI/RFP, including the four-clause walk test as a procurement gate. The 2026 vendor map and the funding-cycle buyer leverage piece cover the market context.
• Procurement framework — build vs orchestrate vs buy and in-house vs vendor vs hybrid operating model decide which class of vendor's MSA you'll be negotiating in the first place.
• Commercial case — the AI voice ROI framework, voice AI TCO with hidden costs, ROI attribution your CFO will sign, and the business case template are the documents the MSA's commercial schedule should reflect.
• Contract — the 11 clauses above.
• Deployment — the pilot-to-scale architecture, avoiding pilot purgatory, and the governance framework for production operation.
• Day-2 governance — containment-rate measurement, auditability and explainability, and the AI tool inventory ICO and FCA expect.

The 11 clauses are the contract-stage point in that chain. Get them right at signature and the rest of the chain has a stable foundation. Get them wrong, and every subsequent stage carries the contract's loose ends.

Want to pressure-test a draft voice AI MSA? You can try Dilr Voice in production ($20 in credits, no commitment), book an AI placement diagnostic for a structured 4–6 week deployment plan, or speak to us about an AI operating model engagement that covers governance, contract, and Day-2 operations end-to-end.

Written by the Dilr.ai engineering team — practitioners who redline voice AI MSAs as part of enterprise deployments. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.