Voice AI Controller or Processor? The Article 28 Guide

The data processing agreement gets signed somewhere in week six of procurement. Someone in legal reads the vendor's template, negotiates the audit clause, checks that sub-processors need notice, and files it. The box is ticked. Underneath it sits an assumption nobody tested: that your voice AI vendor is your processor, and will stay your processor for the life of the contract.

That assumption does an enormous amount of compliance work. It decides who writes the privacy notice, who answers the subject access request, who reports a breach to the ICO inside 72 hours, and whose name is on the penalty notice. It is also, in a meaningful share of enterprise voice deployments, wrong. Not wrong at signature, but wrong by month nine, once the vendor has started using your call recordings to tune its own models and nobody updated the paperwork.

This matters more now because the deployments are no longer experiments. McKinsey's State of AI, published November 2025, found 88% of organisations using AI in at least one function but only 33% running it in production and 14% able to point to EBIT impact. That gap is where governance debt accumulates: enough deployment to create real exposure, not yet enough maturity to have allocated it.

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.

This post is about the allocation itself, not the contract that follows. For the clause-by-clause commercial paper, our voice AI MSA contract clauses guide covers sub-processor controls, audit rights and exit assistance, and our data residency guide walks the Article 28(3) checklist. Both assume the roles are settled. This one tests whether they are.

Who is the controller when you deploy a voice AI platform?

In almost every enterprise voice AI deployment, the enterprise is the controller and the platform vendor is the processor. Article 4(7) of the UK GDPR defines the controller as the body which, alone or jointly with others, determines the purposes and means of processing. You decided to answer inbound calls with an AI agent, you chose which calls, and you set the retention. That determination is what makes you the controller.

The word doing the work is "determines". It is a factual test, not a contractual one. You cannot become a processor by writing "the parties agree that the vendor is controller" into a schedule, and a vendor cannot escape controller status by declaring itself a processor in its terms of service. The ICO's guidance on controllers and processors is explicit that the analysis turns on who actually makes the decisions.

For a voice deployment the decisions worth naming are narrower than people expect. Who decided that calls are recorded at all? Who set the retention period on transcripts? Who chose which intents get escalated to a human? Who decided whether the audio is used to improve a model? The first three are almost always yours. The fourth is the one that moves.

Run that ladder per processing activity, not per vendor. A single voice AI contract can produce three allocations: the vendor is your processor for live calls, an independent controller for its own billing records, and something you need to argue about for model improvement. Treating the vendor as one undifferentiated role is what produces a record of processing activities that does not survive an audit.

What makes a voice AI vendor a processor rather than a controller?

A voice AI vendor is your processor when it processes personal data on your behalf and only on your documented instructions. Article 4(8) of the UK GDPR defines a processor as a body which processes personal data on behalf of the controller. In practice that means Dilr Voice, or any comparable platform, transcribes, routes and stores calls because you told it to, within limits you set, for purposes you chose, and does nothing else with that audio.

The instruction boundary is the whole of it. Article 28(1) requires a controller to use only processors providing sufficient guarantees on technical and organisational measures. Article 28(2) prevents a processor engaging another processor without your prior written authorisation, which is why the sub-processor chain matters: the speech-to-text provider, the large language model and the telephony carrier all process your callers' personal data downstream of a decision you are supposed to have authorised.

Most vendors in this market behave as processors for core call handling and say so plainly. Vapi, Retell AI, Bland AI and Synthflow all position themselves as infrastructure you instruct, and PolyAI operates the same way for managed enterprise deployments. The same is true of the adjacent stack: Twilio for carriage, Salesforce and HubSpot as the systems of record you write back into. The question is not whether they are processors today. It is whether every activity they perform on your data is one you actually instructed.

The same allocation logic underpins our AI placement diagnostic, a fixed-fee assessment we run before any deployment commitment, because a role that is wrong on paper is far cheaper to fix before the integration than after it.

When does your voice AI vendor quietly become a controller?

Your vendor becomes a controller the moment it processes your call data for a purpose it chose rather than one you instructed. The most common trigger in voice AI is model improvement, where the vendor retains your recordings to tune its speech recognition or its agent behaviour. That is the vendor's purpose, serving the vendor's product. Article 28(10) of the UK GDPR converts the role automatically, without anyone amending the contract and usually without anyone noticing.

The statute is unusually blunt about it. Article 28(10) reads:

"Without prejudice to Articles 82, 83 and 84, if a processor infringes this Regulation by determining the purposes and means of processing, the processor shall be considered to be a controller in respect of that processing."

The ICO says the same thing in operational language. Its guidance for processors states that if you act outside your instructions or process for your own purposes, you will step outside your role as a processor and become a controller for that processing. Its determination guidance adds that as soon as a processor processes personal data outside the controller's instructions, it is acting as a controller in its own right for that element. Note the scope in both formulations: the conversion is per activity, not per relationship. The vendor does not stop being your processor for call handling. It becomes a separate controller for the training.

That is what makes the failure quiet. Nothing breaks. Calls keep working. The vendor is still your processor for the thing you are watching, so the dashboards, the SLA reports and the ICO audit preparation file all look correct. What has actually happened is that a second controller has appeared in your processing landscape, with no lawful basis identified, no privacy notice telling your callers about it, no entry in anyone's Article 30 record, and no agreement governing it, because a DPA by definition governs processing done on your instructions.

Three tells, all findable in an afternoon. First, read the model training clause in your contract and check whether it is opt-out rather than opt-in, because an opt-out nobody exercised is a purpose the vendor set. Second, check whether the vendor publishes aggregate benchmarks or accuracy claims derived from customer traffic. Third, ask in writing what happens to your audio after your stated retention period. Our enterprise voice AI vendor checklist turns those into procurement questions, and our vendor consolidation risk guide covers what changes when one supplier holds several.

What does Article 28 actually require your DPA to contain?

Article 28(3) requires a written contract binding the processor to the controller, covering documented instructions, confidentiality, security measures, sub-processor authorisation, assistance with data subject rights, breach support, deletion or return at the end of the contract, and audit rights. Article 28(9) requires it in writing, including in electronic form. Those headings are well trodden ground, so this guide will not re-derive them.

We have covered that clause substance twice, so no third pass here. The data residency guide walks the Article 28(3) list as it applies to a voice pipeline, including the storage-versus-processing distinction most vendor DPAs blur. The MSA clause guide covers the commercial paper around it: sub-processor notice periods, audit rights with cost-shifting, and exit assistance.

What is worth adding is the limits of those clauses. A DPA is evidence of the allocation, not the source of it. If your vendor in fact determines a purpose, the most carefully drafted Article 28(3) schedule does not make it your processor for that purpose. This is why "we have a signed DPA" is a weak answer to a regulator and in diligence. The strong answer is a per-activity map, plus evidence it matches what the system does. One UK-specific detail: Article 28(8) as it applies in the UK gives the Commissioner, rather than the European Commission, the power to adopt standard contractual clauses, a substitution made by the EU Exit Regulations (S.I. 2019/419) with effect from 31 December 2020.

Are you and your voice AI vendor ever joint controllers?

Occasionally yes, and it is under-diagnosed. Article 26(1) of the UK GDPR provides that where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers, and it requires them to determine their respective responsibilities in a transparent arrangement. Joint control is not about sharing data. It is about jointly deciding why the processing happens, which is a much narrower and much more specific test.

In voice AI the realistic joint-control scenarios are few. A co-branded service where vendor and enterprise jointly design what the agent is for. A referral or lead-generation arrangement where both parties take commercial value from the same call data and both shaped how it is captured. A consortium running a shared agent across member organisations. If any of those describe your deployment, the Article 26 arrangement is a separate document from the DPA, and its essence must be made available to data subjects.

Joint control cannot be created or avoided by preference. If you and your vendor genuinely co-decide the purpose, you are joint controllers whatever the contract says. Where a deployment sits close to that line we redesign the processing so the roles separate cleanly, because unpicking joint control after launch is harder than designing around it. That is what our AI operating model consulting engagement settles before build.

Who pays when the allocation is wrong?

Both parties pay, in different ways, and the enterprise usually pays more. Article 82(2) makes a controller liable for damage caused by processing that infringes the Regulation, while a processor is liable only where it breached obligations specifically directed at processors or acted outside or contrary to the controller's lawful instructions. As controller you carry the broad exposure, and the vendor's liability is real but much narrower.

That asymmetry is why indemnities in a voice AI MSA rarely transfer as much risk as buyers assume. The fine tiers compound it. Breaching Article 28 itself sits in the lower band: under Article 83(4) of the UK GDPR, infringements of controller and processor obligations under Articles 25 to 39 attract fines up to £8.7 million or 2% of total worldwide annual turnover, whichever is higher. But a role misallocation rarely stays an Article 28 problem, because if the vendor is processing without a lawful basis you have a principles failure, and Article 83(5) puts Articles 5, 6, 7 and 9 in the upper band at up to £17.5 million or 4%.

Read that chart as a chain rather than five separate risks. An undiagnosed controller produces an Article 6 problem first, because that processing has no identified lawful basis. It then produces an Article 30 problem, because your record does not describe it, and an Article 13 problem, because your privacy notice does not mention it. Financial services is stricter again: firms in scope of DORA carry ICT third-party accountability alongside the UK GDPR position, and the FCA expects the same clarity of ownership.

What is the best way to fix a mis-allocated voice AI DPA in 2026?

The best fix in 2026 is a per-activity role map produced before renegotiation, not a redrafted DPA. Map each processing activity in the voice estate, name the party that sets its purpose, mark the activities where the vendor has its own use, and only then decide what paperwork each one needs. Dilr Voice deployments run this at design time. The order matters, because contracts written before the map tend to paper over the exact activity that caused the problem.

Judge any proposed fix by four tests. Does it name a role per activity rather than per vendor? Does it produce evidence, meaning logs and configuration showing the system behaves as the map claims? Does it update the Article 30 record and the privacy notice, not just the contract? And would you detect a new vendor purpose rather than discover it at renewal?

Here is the honest concession. If your deployment is a single-vendor, single-purpose contact centre agent with no model training and no co-branding, this is not worth a consulting engagement. Take the ICO's processor guidance, a competent data protection lawyer and an afternoon. Equally, if you are deep inside a PolyAI or Vapi enterprise agreement with a mature privacy function, your incumbent's compliance team may settle this faster than an external party can, and ElevenLabs publishes clear positions on voice data use a good in-house DPO can work from. Where we earn our place is the messier case: several vendors, several jurisdictions, model training somewhere in the stack, and nobody able to say which entity determines what. That is what our AI execution office is built for.

Does using a sub-processor change who the controller is?

No. Adding a sub-processor extends the processing chain without moving the controller role. Under Article 28(2) your processor needs your written authorisation to engage another processor, and it must impose equivalent data protection obligations downstream. You remain the controller throughout. What sub-processors change is the number of places where the Article 28(10) conversion can happen, because a speech-to-text or LLM sub-processor training on your audio raises the identical question one layer further down.

Does the Data (Use and Access) Act 2025 change the controller and processor split?

Not fundamentally. The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025 and its data protection provisions are now in force, with the bulk commencing on 5 February 2026 under the Commencement No. 6 Regulations and a further tranche on 19 June 2026. It adjusts lawful bases, automated decision-making and complaints handling. The controller and processor definitions and the Article 28(10) conversion are unchanged, so the allocation exercise in this guide is unaffected.

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.

Related reading: consent capture for AI voice calls covers the lawful basis layer a misallocation breaks, call recording consent across jurisdictions handles the multi-country case, EU AI Act Article 50 disclosure covers what you must tell the caller, the AI tool inventory guide covers estate-level registration, and the DPIA template covers the assessment that should have surfaced this before launch. The full compliance cluster sits alongside Dilr Voice.

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.