Voice AI and the right to restriction of processing

Most enterprise voice AI programmes have a runbook for erasure. They can delete a caller's recording, purge the transcript, and evidence it. Far fewer have a runbook for the quieter right sitting next to it: the right to freeze how a caller's data is used without deleting a byte of it. When a caller says "stop using my call while I dispute what it says," they are exercising the UK GDPR Article 18 right to restriction of processing, and a system that can only delete or ignore has no correct answer to give.

The volume behind these requests is not trivial. The Information Commissioner's Office received 42,315 data protection complaints in 2024/25, up from 39,721 the year before. Restriction is one of the least-drilled individual rights, which makes it one of the easiest to get wrong at the moment a caller is already unhappy.

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 is a practitioner's guide to Article 18 for voice AI: what restriction means, the four grounds that trigger it, how you technically freeze a record without deleting it, the duty to warn before you lift the freeze, and where restriction sits alongside erasure, rectification and objection. Every legal point below is checked against the current text of the UK GDPR on legislation.gov.uk, including the changes the Data (Use and Access) Act 2025 did and did not make.

What is the right to restriction of processing under Article 18?

The right to restriction of processing lets a data subject require a controller to freeze the use of their personal data while keeping it stored. For a voice AI deployment, that means a caller can stop you analysing, sharing, routing or training on their recording and transcript without asking you to delete it. Dilr Voice treats Article 18 as a distinct operational state a record can be placed into, not a variant of erasure.

Restriction is deliberately narrow. It is not a general "pause button" a caller can press for any reason; it attaches only when one of four specific grounds applies, and even then it does not wipe the data. The record stays in your systems, but almost everything you would normally do with it stops. That combination, keep but do not process, is what makes restriction awkward for architectures that were only ever designed to store or delete.

When can a caller restrict processing of their call data?

UK GDPR Article 18(1) gives four grounds, and a caller needs only one. They can restrict processing where accuracy is contested and you are verifying it; where processing is unlawful but they oppose erasure; where you no longer need the data but they need it for a legal claim; or where they have objected under Article 21 and the balancing test is open. Each maps onto a voice AI record.

Ground (a) is the one voice AI teams meet most often. A caller hears the automated summary of their call read back, disagrees with it, and contests its accuracy. Until you have verified whether the transcript or extracted field is right, the caller can require you to freeze processing of that record. It runs in parallel with the right to rectification for inaccurate call records: rectification fixes the data, restriction holds it still while the dispute is live.

Ground (d) carries a change worth flagging. Article 18(1)(d) triggers restriction when a caller "has objected to processing pursuant to Article 21(1)." The Data (Use and Access) Act 2025 amended Article 21(1) itself, inserting a reference to point (ea) of Article 6(1) with effect from 5 February 2026, so the objection right now reaches processing based on the new recognised legitimate interests basis as well as the older public-task and legitimate-interests grounds. The text of Article 18 did not move, but the set of processing a caller can freeze through ground (d) widened with it. This interlocks with the right to object under Article 21, which is worth reading alongside this one.

What does "restrict" actually mean for a recording or transcript?

Restriction means you may keep storing the data but must stop almost everything else. Article 18(2) is explicit: once processing is restricted, the data may, "with the exception of storage," only be processed with the caller's consent, or to establish, exercise or defend a legal claim, or to protect another person's rights, or for important public-interest reasons. For a voice AI record that rules out analytics, quality scoring, model training, onward sharing and re-use in live routing.

The practical test is simple. Storage is allowed; almost every active use is not. That is why restriction cannot be implemented as a soft convention that engineers are trusted to honour. It has to be a hard state on the record that downstream systems read and obey, because "important public interest" and "legal claims" are the only doors left open, and a general voice AI pipeline should treat both as closed by default until legal counsel says otherwise. An AI operating model that governs how records flow between systems is where that state actually gets enforced.

How do you technically restrict a call record without deleting it?

You flag the record and freeze its downstream processing while leaving storage intact. In practice that means setting a restriction status on the recording, transcript and any extracted fields; stopping analytics, training and routing jobs from reading it; suppressing it from onward feeds to a CRM, warehouse or quality tool; and logging who set the restriction, when, and on which ground. The point is that the byte survives while every active use of it halts.

The hardest part is propagation. A voice AI call rarely lives in one place: the audio sits with the telephony layer, often carried over Twilio or a similar carrier; the transcript lands in your platform; extracted fields sync to Salesforce or HubSpot; and copies feed analytics and training sets. A restriction that only flags the master record but leaves the CRM copy processing freely is not a restriction. Mapping where the data actually flows before you deploy is exactly what our DATS methodology is built to do. Vendors that expose record-level status controls, as Dilr Voice does, make this enforceable; vendors that do not push the whole burden onto your own systems.

Do you have to tell the caller before lifting a restriction?

Yes. Article 18(3) imposes an explicit duty: a caller who has obtained restriction must be told before you resume processing. This is one of the clearest obligations in the whole right, and it is easy to breach by simply reactivating a record once a dispute is resolved. The notification has to come first, then the processing resumes. The statute puts it plainly:

"A data subject who has obtained restriction of processing pursuant to paragraph 1 shall be informed by the controller before the restriction of processing is lifted."

That single sentence has a real design consequence for voice AI. Lifting a restriction cannot be an automatic side effect of, say, closing a complaint ticket or verifying accuracy. It needs a deliberate step that fires a notification to the caller and only then clears the restriction flag. Bake it into the workflow and the duty is met every time; leave it to human memory and it will eventually be missed on the busiest day. Our AI execution office exists precisely to turn obligations like this into standing operational steps rather than one-off good intentions.

How long do you have to respond to a restriction request?

A restriction request is a data subject request, so the usual clock applies: you have one month to respond. The Data (Use and Access) Act 2025 moved this deadline into a new Article 12A, framed as one month "beginning with the relevant time," with a stop-the-clock for identity checks and an extension of up to two months for complex requests. The mechanics are the same across every right, so treat them as a shared control.

Because the timing rule is cross-cutting, this guide does not rebuild it here. What matters for restriction specifically is that "respond within a month" does not mean "resolve the underlying dispute within a month." You must action the restriction and tell the caller what you have done inside the deadline; verifying contested accuracy or settling an Article 21 objection can legitimately take longer, during which the record stays frozen. Getting that distinction wrong is a common way a well-intentioned team turns a simple request into an ICO complaint.

How does restriction interlock with erasure, rectification and objection?

Restriction is the "hold" that sits between the other rights. It often begins because a caller has contested accuracy or lodged an objection, and it ends in rectification, erasure or resumed processing once the question is settled. Keeping the rights distinct matters: a caller who asks to "restrict" may in substance want correction or deletion, and the wrong reflex either over-deletes or under-protects. The table below maps each right to what it does to a voice AI record.

One overlap deserves care. Under ground (b), a caller can meet processing that is unlawful with a choice: they may ask for erasure, or they may oppose erasure and ask for restriction instead, for example to preserve evidence. Your workflow has to honour that choice rather than default to deletion. A subject access request frequently arrives in the same message, so the intake step should separate what the caller is actually asking for before any record is touched.

What is the best way to handle Article 18 restriction in a voice AI deployment in 2026?

The best approach is to make restriction a first-class record state that your platform, not just your policy, can enforce, then judge every voice AI vendor on whether it exposes that control. Self-serve builders hand you the primitives and leave the compliance state for you to construct; managed providers are likelier to ship status flags and audit logging. The right answer depends on where your call data lives and who is accountable for it.

The market splits along exactly this line. Self-serve platforms such as Vapi, Retell AI, Synthflow and Bland AI give you the primitives but generally leave record-level compliance states for you to build. Managed providers such as PolyAI and Dilr Voice are likelier to offer restriction status flags and audit logging out of the box, which shifts less of the burden onto your own stack.

There is an honest concession here. A low-volume, single-flow deployment that keeps recordings briefly and processes them nowhere but a single system may reasonably handle rare restriction requests manually, and a dedicated restriction workflow would be over-engineering. The calculus changes the moment call data fans out into a CRM, a warehouse and a training set, because at that point a manual freeze cannot keep pace and a missed downstream copy becomes the breach. Weigh restriction alongside the cost of getting compliance wrong: an Article 18 failure is a data-subject-rights infringement in UK GDPR's upper penalty tier under Article 83(5), carrying fines up to £17.5 million or 4% of total worldwide annual turnover, whichever is higher.

Building restriction into the voice AI operating model

Restriction rewards teams that treat it as infrastructure rather than a policy paragraph. The four grounds tell you when a freeze attaches; the store-but-do-not-process rule tells you what the freeze must do; and the Article 18(3) notification tells you what has to happen before you lift it. Wire those three facts into the record lifecycle and restriction becomes a state your systems handle automatically, evidenced end to end, rather than a scramble every time a caller disputes a call. That is the difference between a compliant deployment and a defensible one, and it is the standard we hold Dilr Voice and every DATS engagement to. If you are mapping your own voice AI compliance posture, restriction is the right that most often exposes whether the rest of the architecture is honest about where data goes.

Is the right to restriction absolute?

No. The right to restriction is not absolute; it attaches only when one of the four Article 18(1) grounds applies, and even then storage continues and some processing remains lawful. A caller cannot demand an open-ended freeze for any reason. But once a valid ground is established, the store-but-do-not-process rule and the duty to warn before lifting are firm obligations, not discretionary courtesies, and the ICO expects them to be evidenced.

Did the Data (Use and Access) Act 2025 change the right to restriction?

Not directly. The Data (Use and Access) Act 2025 did not amend the text of Article 18, which still reads as it did apart from a 2020 EU-exit correction. What changed sits upstream: the Act amended Article 21(1) from 5 February 2026 to cover the new recognised legitimate interests basis, so restriction ground (d), which triggers on an objection, now reaches a wider set of processing. The right survived unchanged; the reach of one ground moved.

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.

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.