Voice AI and the Right to Erasure: A 2026 Guide

A caller phones your AI voice agent on Monday, discloses more than they meant to, and emails on Friday: delete everything you hold about me. That single sentence now has to travel across a pipeline most enterprises never mapped. The recording. The transcript. The machine-generated summary. The sentiment and intent labels. The embeddings sitting in a retrieval store. The analytics warehouse. Last night's backup. Honouring the request means reaching every one of those copies, not just the audio file the agent obviously produced.

The regulator is watching this space closely. In 2024/25 the Information Commissioner's Office received 42,315 data protection complaints, up from 39,721 the year before, and Article 15 access requests already account for most of that caseload. Erasure is the sibling right, and it is harder to satisfy because deletion has to land on every artefact rather than assemble a single copy for disclosure. At the same time, McKinsey's State of AI (November 2025) reports that 88% of enterprises now use AI but only 33% have taken it into production, so most voice estates were engineered for adoption speed, not for deletion on demand.

This guide sets out what the UK GDPR right to erasure actually requires across a voice AI estate, which requests you can lawfully refuse, who is responsible when a third-party vendor holds the audio, and how to architect the pipeline so a deletion request is a routine operation instead of a forensic project.

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.

What is the right to erasure, and when does it apply to voice AI calls?

The right to erasure, also called the right to be forgotten, is set out in Article 17 of the UK GDPR. It lets an individual ask a controller to delete their personal data, and Dilr Voice treats every inbound call as data that falls within it. The ICO is explicit that the right "is not absolute and only applies in certain circumstances", so a programme has to know which statutory ground a request engages before it acts.

Under Article 17 of the UK GDPR, the ICO sets out that individuals have the right to have their personal data erased where the data is no longer necessary for the purpose it was collected for; where consent was the lawful basis and the individual withdraws it; where processing rests on legitimate interests, the individual objects, and there is no overriding interest to continue; where the data is used for direct marketing and the individual objects; where the data has been processed unlawfully; where erasure is needed to comply with a legal obligation; or where the data was collected from a child for an online service. A voice AI deployment can trip several of these at once, because a single call may rest on consent for one purpose and legitimate interests for another, and a withdrawal of consent for AI voice calls engages the second ground directly.

One detail catches teams out. The ICO notes that the right "only applies to data held at the time the request is received. It does not apply to data that may be created in the future." That matters for voice, where a live agent might still be generating a summary or a follow-up task at the moment the request arrives. The request freezes the current estate, and every artefact already produced from that caller becomes in scope. Where the same caller has also asked to see their data, the neighbouring subject access request obligations run on a parallel clock and should be handled together.

What must a voice AI programme actually delete when a caller asks?

When a valid request lands, Dilr Voice has to erase far more than the audio file. A single call fans out into a recording, a transcript, an AI-generated summary, sentiment and intent labels, embeddings held in a vector store, copies pulled into analytics or a training set, and every backup that captured them along the way. Article 17 reaches all of it, because each artefact is personal data derived from the same caller and the same conversation.

The failure mode is predictable: the audio gets deleted, the team reports the request closed, and the caller's transcript, summary and vectors quietly persist in three other systems. The law does not recognise that distinction. If a fragment can still be tied back to the individual, it is still their personal data, and the deletion is incomplete. Mapping the full derivative inventory, ideally in your record of processing activities, before you ever take a request is the difference between a clean erasure and a breach waiting to be found in an audit.

The statute anticipates this spread. Where personal data has been made public or shared, Article 17(2) requires the controller, "taking account of available technology and the cost of implementation", to take reasonable steps to inform other controllers processing the data that the individual has requested erasure of "any links to, or copy or replication of" that data. In a voice estate the equivalent is internal: your deletion job has to fan out to every store that ever ingested a copy. That is why erasure is an architecture question long before it is a legal one, and why the practical answer sits close to the discipline behind an AI operating model rather than a one-off script.

Can you delete a caller's data from a trained AI model?

Not cleanly, and Dilr Voice is designed so that you never have to. Once personal data has been used to train model weights, removing one person's contribution is not a reliable production capability. Machine unlearning remains an active research field rather than a guarantee you can offer a caller. The honest, defensible answer is architectural: keep raw call data out of the training path by default, so an erasure request never depends on un-training a model that cannot be un-trained.

This is where the distinction between a training set and a set of trained weights earns its keep. A training set is a collection of files. It is personal data, it lives in storage you control, and it can be deleted like any other copy, so it belongs firmly inside the erasure cascade. Trained weights are different: the individual's data has been mathematically diffused across millions of parameters, and there is no supported operation that surgically extracts one caller while leaving the model intact. Promising a caller that you have scrubbed them from the model is a claim most enterprises cannot actually stand behind.

The architecture that resolves this is prevention, not deletion. Treat any reuse of call data for training or evaluation as further processing that needs its own lawful basis and its own record, rather than a silent default. Pseudonymise or strip identifiers before anything reaches a training pipeline, so what does flow through is no longer tied to a named caller. Done this way, an erasure request stays contained to files you can genuinely delete, and the model never becomes the un-eraseable liability. Where the reuse rests on a balancing test, our note on the legitimate interests balancing test walks through documenting it defensibly.

How long do you have to respond to a voice AI erasure request?

Under the UK GDPR you must act without undue delay and within one calendar month of the request, extendable by up to two further months where it is complex. For a Dilr Voice estate that clock covers live systems and backups alike: the ICO expects erasure to reach backups too, even where data cannot be overwritten at once. The standard the regulator sets for backups you cannot instantly purge is that data must be put "beyond use".

The backup problem is where good intentions go to die, because a nightly snapshot can silently re-import a caller you deleted at lunchtime. The ICO's guidance on erasure and backups is specific:

"If a valid erasure request is received and no exemption applies then you will have to take steps to ensure erasure from backup systems as well as live systems. [...] The key issue is to put the backup data 'beyond use', even if it cannot be immediately overwritten."

That means a Dilr Voice deployment needs a documented backup deletion path: the request is fulfilled instantly on live systems, the affected records are flagged so they cannot be restored into production, and the backup is purged on its normal rotation. You must also, in the ICO's words, be "absolutely clear with individuals as to what will happen to their data", including in backups. A caller who is told their data lingers in a snapshot for thirty more days, then goes, is being handled lawfully. A caller who is told "done" while a backup quietly holds them is not.

When can you refuse a voice AI erasure request?

The right is not absolute. Article 17(3) lists the situations where erasure does not apply, and for regulated callers the one that bites hardest is a legal obligation to keep the record. Dilr Voice separates data held under a genuine retention duty, such as MiFID II call recording, from data kept only for convenience, so any refusal is scoped to a specific record and documented, rather than a blanket claim that the business keeps everything indefinitely.

The ICO sets out that the right to erasure does not apply to the extent that processing is necessary: to exercise the right of freedom of expression and information; to comply with a legal obligation; for the performance of a task carried out in the public interest or in the exercise of official authority; for archiving in the public interest, scientific or historical research or statistical purposes where erasure would seriously impair that work; or for the establishment, exercise or defence of legal claims. In the regulator's own words, "if you are required by law to process individuals' personal data, then the right to erasure will not apply."

For voice specifically, the legal-obligation carve-out is the workhorse. An investment firm cannot delete a call it must keep under MiFID II call recording rules, and a lender may need a recording for the "establishment, exercise or defence of legal claims" in a live dispute. The trap is over-reading the exemption. It covers only the specific data the law actually requires you to keep, for as long as the obligation lasts. The same call may hold a marketing sentiment score with no retention basis at all, and that derivative still has to go. This is exactly the boundary a data protection impact assessment is designed to surface before a request ever arrives, so the refusal is precise rather than reflexive.

Who deletes the data when a third-party voice AI vendor holds it?

The enterprise is almost always the controller and the voice AI vendor a processor, so the duty to honour an erasure request sits with you, but the deletion is executed by whoever holds the bytes. Dilr Voice operates under an Article 28 contract that requires the processor to delete on the controller's instruction and to pass that instruction to any onward recipients, closing the gap where a request stops at the front door and never reaches the vendor's storage.

This is where multi-vendor voice stacks leak. The transcription runs on one supplier, the analytics on another, the telephony through Twilio, and the CRM record lands in Salesforce or HubSpot. Each is a separate processor with its own storage, and an erasure request has to reach all of them. Article 28(3)(g) of the UK GDPR requires a processor to delete or return personal data at the end of the service, and Article 19 requires the controller to inform recipients of any erasure unless it proves impossible or disproportionate. Getting those obligations wired into contracts and pipelines is the practical heart of processor and controller responsibilities under Article 28, and it is the difference between a deletion that completes and one a data subject can later prove never did. We wire these duties into every DATS engagement as standard, and run them through an AI execution office for teams that want continuous governance.

What is the best voice AI architecture for the right to erasure in 2026?

The best architecture is the one where deletion is a keyed operation, not a manual hunt. For a compliance-led estate, Dilr Voice is built for erasure by design: minimise what is captured, tag every derivative with a stable caller identifier, and expose a single deletion instruction that fans out to every store. Platforms such as Vapi, Retell AI and Bland AI excel at rapid build, and where speed to a prototype matters more than regulated deletion, they may win.

The criteria that actually separate a defensible estate from a fragile one are concrete. Can you enumerate every store a call touches, or is the derivative inventory tribal knowledge? Is each artefact keyed to the caller so a deletion can target it, or does erasure mean a full-text search of a data lake? Do you hold a deletion service-level agreement, and can you issue a proof of erasure, a signed record that the sweep ran across live systems and backups? Synthflow and PolyAI compete hard on conversational quality and integration breadth, and ElevenLabs leads on voice realism, so on raw voice experience a specialist may win. Where the deciding factor is the ability to delete a named individual across a regulated pipeline and evidence it, an estate architected around the cascade wins, and that is the ground Dilr Voice is built to hold.

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 regulated systems.

Does the right to erasure apply to call recordings kept for regulatory reasons?

Not while the retention obligation stands. If a recording must be kept under a rule such as MiFID II or FCA record-keeping, Dilr Voice relies on the Article 17(3) legal-obligation exemption and refuses erasure for that specific record, while still deleting anything held beyond the documented retention period. The exemption is narrow: it covers only the data the law actually requires you to keep, and only for as long as that requirement lasts.

What is the difference between the right to erasure and a data retention schedule?

A retention schedule deletes data automatically at the end of a set period, on a timer you control. The right to erasure is triggered on demand by an individual, at any point, and can reach data well inside its retention window. Dilr Voice runs both: scheduled deletion for routine housekeeping, described in our voice AI data retention guide, and an on-request path for Article 17. Confusing the two is a common cause of missed deletions.

Did the right to erasure change in the UK in 2026?

The core right is unchanged, but the grounds were extended. From 31 March 2026 a new Article 17(1)(g), inserted by the Victims and Prisoners Act 2024, gives an erasure right over personal data processed as a result of certain unfounded malicious allegations, in England and Wales. For most Dilr Voice deployments the everyday grounds in Article 17(1)(a) to (f) still do the work, and the wider UK compliance picture is where these changes are tracked.

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.