Voice AI sub-processors: an Article 28 authorisation guide

When an enterprise signs with a voice AI vendor, it signs one contract. What it inherits is a supply chain. The vendor almost never processes calls alone: it runs on a large language model provider, routes audio through a telephony carrier, and often passes the stream to a separate speech-to-text service. Each of those is typically a sub-processor touching the caller's voice, and under UK GDPR the controller carries the accountability for every link in that chain. In 2026 this is not a theoretical exposure. McKinsey's State of AI, published in November 2025, found that roughly 88% of enterprises now use AI in at least one function, yet only about 6% capture material earnings impact, and the firms that pull ahead are the ones that treat governance as part of the deployment rather than a document produced afterwards.

The gap most buyers miss is that authorising a processor is not the same as authorising its sub-processors. Article 28 of the UK GDPR sets a specific, testable sequence for adding a downstream processor, and it is the sequence procurement teams are least likely to have evidenced when the ICO or an enterprise auditor asks. This guide walks the authorisation chain end to end: what a sub-processor is in a voice deployment, what Article 28(2) requires before one can be added, how general and specific authorisation differ, what the Article 28(4) flow-down actually obliges, how to keep a live register, and what the Data (Use and Access) Act 2025 did and did not change.

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

What is a sub-processor in a voice AI deployment?

A sub-processor is a third party a voice AI vendor engages to process personal data on the controller's behalf, sitting one step further down the chain than the vendor itself. In a typical Dilr Voice or competitor stack that means at least three: the model provider that generates responses, the telephony carrier that carries the audio, and the transcription service that turns speech into text. Each processes the caller's voice, so each is inside the controller's accountability.

The scale of that inheritance is easy to underestimate. Twilio, one of the most common telephony carriers behind voice agents, publishes a sub-processor list that ran to more than 40 entities as of April 2026, and its own list names Anthropic, OpenAI and Deepgram among them. So an enterprise that contracts only with a voice vendor built on Twilio inherits an AI and infrastructure supply chain it never directly signed. OpenAI, in turn, publishes its own sub-processor list, last updated in July 2026. The European Data Protection Board's Guidelines 07/2020 on the concepts of controller and processor, adopted in final form on 7 July 2021, are explicit that a processor may engage a sub-processor only with the controller's authorisation and remains answerable for it.

This is where an AI placement diagnostic earns its keep before contracts are signed, because the chain has to be mapped, not assumed. Vendors such as Vapi, Retell AI, Bland AI and Synthflow assemble their stacks from third parties by design, so the question is never whether sub-processors exist but whether they are disclosed, authorised and governed.

What does Article 28 require before a voice AI vendor can add a sub-processor?

Article 28(2) of the UK GDPR sets the gate. A processor may not engage another processor without the controller's prior authorisation, and where that authorisation is general rather than specific, the processor must give notice of any intended addition or replacement so the controller can object first.

For a voice AI deployment this means the vendor cannot quietly swap its transcription provider or add a new model host and treat the change as an internal engineering decision. The authorisation, and the notice, are the controller's rights.

The statutory wording is worth reading directly, because it is the whole obligation in two sentences:

"The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes."

UK GDPR, Article 28(2)

That obligation also has to be written into the contract itself. Article 28(3) requires the controller-to-processor contract to bind the processor to the sub-processor conditions, so a voice AI data processing agreement that is silent on sub-processors is defective on its face. The direct controller-versus-processor split, and who owns which role in a mixed deployment, is a separate question we cover in the Article 28 controller-or-processor guide; this piece is about the downstream chain that hangs off it.

What is the difference between general and specific written authorisation?

Specific authorisation means the controller approves each named sub-processor individually, so any new one requires a fresh sign-off before it can process data. General written authorisation means the controller approves the vendor's use of sub-processors in principle against a published list, and the vendor may change that list provided it gives notice and honours the right to object.

Almost every voice AI vendor operates the general model, because per-caller sign-off does not scale, which makes the notice mechanism the real control.

Under the general model the practical safeguards are the notice period and the object window. A defensible voice AI contract states how the vendor will notify a change to its sub-processor list, how many days' notice it gives before the change goes live, and what happens if the controller objects, whether that is a right to work through the concern, to pause the change for that controller's data, or ultimately to exit without penalty. When those terms are missing, general authorisation collapses into no authorisation at all, and the same diagnostic logic that underpins our AI operating model consulting treats an unbounded notice clause as a finding, not a footnote. The reason to fix it early is that a change to the model provider or carrier can move where a caller's audio is processed, which is why this interacts directly with the voice AI international transfers rules.

What are the flow-down obligations under Article 28(4)?

Article 28(4) requires that when a processor engages a sub-processor, the same data protection obligations set out in the controller-to-processor contract are imposed on that sub-processor, in particular the duty to provide sufficient guarantees of appropriate technical and organisational measures. In plain terms, the protections you negotiated with the voice AI vendor must flow down unchanged to its model provider, carrier and transcription service. The vendor cannot offer you strong terms and then sub-contract on weaker ones.

The statute puts the flow-down in one clause:

"Where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor ... shall be imposed on that other processor by way of a contract or other legal act."

UK GDPR, Article 28(4)

The ICO's guidance on what a controller-processor contract must contain is blunt about the consequence: the sub-processor contract must offer "an equivalent level of protection for the personal data", and the processor is liable to the controller for a sub-processor's compliance with its data protection obligations. Article 82(5) then lets the controller recover from the processor for a sub-processor's failings. That liability chain is why a governance failure here is not cosmetic. A breach of the Article 28 obligations sits in the lower fine tier under Article 83(4), which still reaches up to £8.7m or 2% of global turnover, and if the failure enables an underlying breach of the core principles, exposure escalates to the higher tier.

How do you keep a live sub-processor register?

A live sub-processor register is a maintained record of every downstream processor in the voice AI chain, what each one does, where it processes data, the authorisation basis, and the date it was added or changed. It is the artefact that turns Article 28 from a clause into an evidenced control.

Without it, a controller cannot answer the ICO's first audit question, which is simply who touches the caller's data and on what authority. The register should be owned by the controller, fed by the vendor's notices, and reconciled against the vendor's published list on a set cadence.

The register does not sit alone. It is the operational companion to the Article 30 record of processing activities, and in financial services it feeds the third-party mapping that DORA's ICT third-party regime demands. Change management is the part teams skip: a vendor notice arrives, nobody logs it, and six months later the register no longer matches reality. The lifecycle below is the minimum an enterprise controller should be able to evidence before any new sub-processor touches live call audio.

The same discipline is what separates a governed voice AI agent deployment from a demo that happens to work. A register that is current, reconciled and owned is the difference between a two-hour audit and a two-week scramble.

Did the Data (Use and Access) Act 2025 change the sub-processor rules?

No, the sub-processor authorisation mechanics are unchanged. The Data (Use and Access) Act 2025 amended Article 28 in only one place: a wording substitution in Article 28(5), covering approved codes of conduct and certification, which came into force on 20 August 2025 under SI 2025/904.

Article 28(2), the authorisation and object right, and Article 28(4), the flow-down duty, carry no DUAA amendment. The rest of the Act's data protection reforms commenced in bulk on 5 February 2026 under SI 2026/82, but they touched lawful bases, automated decision-making and complaints, not the processor chain.

This matters because a common vendor line in 2026 is that "the new Act changed the rules", used to justify a contract that is quieter on sub-processors than it should be. It did not. The authorisation sequence you would have run in 2024 is the sequence you run now. Our about page sets out why we read the primary source before repeating a vendor's summary of it, and the discipline pays off precisely on claims like this one. For the adjacent question of who is controller and who is processor after the Act, which the DUAA also left largely intact, the split is covered in full across our voice AI compliance library.

Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, see our DATS methodology, or read the UK and EU voice AI compliance guide.

What is the best way to govern the voice AI sub-processor chain in 2026?

The best approach depends on how much of the chain you want to control directly, and there is a real trade-off. A self-assembled stack on Vapi, Retell AI, Bland AI or Synthflow gives you the tightest grip on which sub-processors you use, because you choose the model host, the carrier and the transcription service yourself, but you also own every Article 28 authorisation, flow-down contract and register entry.

A managed platform such as Dilr Voice or PolyAI absorbs that governance work and publishes a maintained chain, at the cost of some direct control over each component.

For most regulated enterprises the managed route wins, because the failure mode is not choosing the wrong model, it is losing track of an unauthorised change six months after go-live. The DATS methodology exists to make that judgement deliberately rather than by default, and our AI execution office runs the register cadence for teams that do not want to staff it. There is a genuine scenario where the build route wins: a single-use-case deployment, a strong in-house data protection team, and a requirement to pin a specific model provider for reasons the managed platforms will not accommodate. In that case direct control of the chain is worth the governance overhead, and the honest answer is to build. Where the estate is multi-line, multi-jurisdiction and audited, the managed chain almost always repays itself, a pattern we see repeatedly in enterprise voice AI procurement.

Can a controller refuse a new sub-processor?

Yes. Under the general written authorisation model in Article 28(2), the controller has an explicit right to object to a proposed addition or replacement before it goes live. What the objection achieves depends on the contract: a well-drafted voice AI agreement gives the controller a defined path.

That path typically includes a window to raise the concern, a commitment that the vendor will not route that controller's data through the disputed sub-processor while it is unresolved, and a right to terminate without penalty if no resolution is reached.

Is a telephony carrier like Twilio a sub-processor or a separate controller?

Usually a sub-processor, but not always. When Twilio carries audio strictly on the voice vendor's instructions, it acts as a sub-processor inside the chain. For some activities, such as its own fraud prevention or regulatory call records, a carrier can act as a controller in its own right for that narrow purpose. The allocation is fact-specific, which is why the controller-or-processor analysis has to be run per activity rather than assumed for the whole relationship.

What happens if a voice AI vendor adds a sub-processor without telling you?

It is a breach of Article 28(2), and it is the controller's problem as much as the vendor's. The immediate compliance gap is an unauthorised processor of personal data, which exposes the controller under Article 83(4) and undermines the Article 30 record.

The contractual remedy should already be written: notice failure as a defined breach, a right to audit, and termination rights. In practice the earliest signal is a register that no longer reconciles against the vendor's published list, which is exactly why the reconciliation cadence is a control and not an administrative chore.

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.