Voice AI DSARs: Manifestly Unfounded or Excessive Requests

A caller rings your voice AI line, then follows up asking for a copy of every recording of every call they have ever made to you. A week later they ask again. Then they ask for the transcripts, the retention logs, and the name of everyone who listened. Somewhere in the thread they mention that all of this will stop if you waive their outstanding balance. Your team looks at the pile of recordings, the hours of redaction, and asks the obvious question: do we have to do all of this, every time, for everyone?

The honest answer is that there is a gate, but it is a narrow one. UK GDPR gives a controller a limited power to charge a fee or refuse where a request is manifestly unfounded or excessive. It is not a filter for requests you find inconvenient, and the burden of justifying it falls on you. Getting that gate wrong is expensive twice over: a wrongful refusal invites a regulator complaint, and a lazy compliance because refusing felt risky trains every future requester that persistence pays.

Across the enterprises we work with, roughly 88% now use AI in at least one function while only around 6% report material earnings impact, according to McKinsey's State of AI published in November 2025; Stanford's AI Index 2026 finds fewer than 10% of firms have fully scaled AI in any function. A voice channel that records every call turns that adoption into a standing data-subject-rights liability, and the requests arrive whether or not the programme is ready for them.

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 a manifestly unfounded or excessive request?

A manifestly unfounded or excessive request is one that clears the high bar set by UK GDPR Article 12(5), the only point at which a controller may charge a reasonable fee or refuse a data-subject-rights request. It is a deliberately narrow gate. For a Dilr Voice programme it covers requests for call recordings, but the caller has to be doing something the law treats as abusive or disproportionate, not merely asking for a lot.

Two points set the scope. First, Article 12(5) is not a subject-access provision on its own; it sits across the data subject rights, so the same test governs an access request for a recording, an erasure request, or an objection. This post scopes it to access requests for call recordings, which is where voice programmes feel the pressure. Second, refusing under Article 12(5) is a different route from withholding under a DPA 2018 exemption, such as legal privilege or third-party data. This post holds the refusal-and-fee gate; it cedes the general subject-access mechanics, the redaction of other people on the call, and the exemptions to our DSAR call-recordings guide, and the response clock to our Article 12A deadline guide.

One clarification worth making early, because it is the most common mistake we see. The word manifestly does real work. It is not enough for a request to be arguably unfounded or somewhat burdensome; the ground has to be clear on the facts in front of you. If your team is spending an afternoon constructing the argument, that is a signal the gate probably does not apply, and you should be answering the request instead.

When is a request manifestly unfounded?

A request is manifestly unfounded, in the ICO's view, in two situations. The first is where the person clearly has no intention of exercising their right of access, for example where they make a request but offer to withdraw it in return for some benefit from the organisation. The second is where it is clearly malicious and used to harass, with no real purpose other than to cause disruption. Intent, not inconvenience, is the test.

The ICO's right-of-access guidance, reviewed on 8 December 2025, gives the harassment example teeth: someone who explicitly states, in the request itself or in surrounding communications, that they intend to cause disruption, or who makes unsubstantiated accusations against you or specific employees, or who systematically targets an individual member of staff out of personal grudge. The caller in our opening example, offering to drop everything for a fee waiver, is close to the first limb. But you still have to record why, on these facts, the intention is manifest.

What manifestly unfounded is not: a request from someone you dislike, a request that arrives during a live dispute, or a request that would be embarrassing to answer. The ICO is explicit that you should deal with each request on its own merits and must not have a blanket policy. A voice programme that batches similar-looking requests into a single refusal template has already lost the argument, because the whole point is that the finding is specific to the request in front of you.

When is a request excessive?

To decide whether a request is excessive, the ICO says you should consider whether it is clearly or obviously unreasonable, taking into account all the circumstances. Those include the nature of the information, whether responding is proportionate to the burden and cost, your relationship with the person, whether refusal could cause them substantive damage, your resources, and whether the request repeats or overlaps earlier ones. No single factor decides it.

Here is the factor that catches voice programmes out, and it is worth stating plainly because it runs against instinct. A request is not excessive simply because the person asks for a large amount of information. A caller who wants forty recordings has not made an excessive request just by virtue of the volume; a governed platform such as Dilr Voice can retrieve and package forty recordings, so the retrieval burden alone does not carry the argument. Excessive is about unreasonableness in the round, and volume is only one input to it.

Where excessiveness genuinely bites for a voice channel is repetition and overlap. A caller who asks for the same recordings every fortnight, when nothing has changed and a reasonable interval has not elapsed, is building an excessive pattern. So is one whose new request overlaps information you have already provided by other means. The discipline is to hold the history: an AI operating model that logs what was asked, when, and what you supplied is what lets you show a pattern rather than assert one.

Do we have to prove a request is unfounded or excessive?

Two halves must sit together here. The burden is on you, the controller, to justify the ground, but the standard is demonstration, not courtroom proof. UK GDPR Article 12(5) is unambiguous about where the burden falls, and the ICO then clarifies that you do not have to prove the point conclusively, only show that the provision applies in the circumstances with reference to supporting factors. Evidence the decision; do not litigate it.

The statute itself puts it directly. Article 12(5) provides that "the controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request." That is a live provision. The Data (Use and Access) Act 2025 renumbered some of the cross-references inside Article 12, and moved the response deadline into the new Article 12A, but it left the manifestly-unfounded-or-excessive test, the choice between a reasonable fee and refusal, and this burden intact.

What demonstrating looks like in practice is a short, contemporaneous record for each contested request: which limb you relied on, the specific facts that made the ground manifest or the request clearly unreasonable, the factors you weighed, and the decision you reached. The ICO is explicit that a decision to refuse or charge needs strong justifications, supported by clear evidence, that you can explain to the person and, if it comes to it, to the regulator. This is the artefact that turns a defensible position into a defended one, and it is exactly the kind of decision an AI execution office exists to make repeatable rather than heroic.

Can we charge a reasonable fee instead of refusing?

Yes. Where a request is manifestly unfounded or excessive, Article 12(5) gives you a choice: you may refuse to act, or you may charge a reasonable fee and respond. The fee reflects the administrative costs of dealing with the request, such as the labour of retrieval and redaction, not a deterrent priced to make the caller go away. You are never obliged to charge; it is simply the middle path between free compliance and outright refusal.

There is no statutory cap, and there is no set tariff to fall back on. The old ten-pound subject-access fee belonged to the Data Protection Act 1998 and is long gone, so a voice programme that still quotes it is quoting dead law. The ICO's position is that it is your responsibility to ensure the rate you charge is reasonable, which in practice means you should be able to relate it to the actual work involved rather than to a round number chosen for convenience.

For a voice channel the fee route is often the more proportionate answer to a genuinely excessive request, because it keeps you inside the spirit of the right while recovering the real cost of, say, redacting third parties out of dozens of recordings. It is also easier to defend than a refusal: charging a reasonable, cost-based fee is a far smaller step than declining to act at all, and a caller who complains about a modest, well-evidenced fee is on weaker ground than one who was refused outright.

What is the best way to handle unfounded or excessive DSARs in 2026?

The best approach in 2026 is to treat the refusal gate as a rare, well-evidenced exception rather than a workflow, and to build the logging, retrieval and redaction into the system that runs your voice channel. The right tool depends on volume and exposure, not on brand. Judge platforms on whether they give you a defensible audit trail and a way to hold request history, because those are what a contested refusal turns on.

On the tooling itself, be honest about the split. Self-serve voice platforms such as Vapi, Retell AI, Bland AI and Synthflow will give you the call and the recording, but the judgement about whether a request to hand that recording over is manifestly unfounded or excessive, and the evidence behind it, still sits with you as the controller. Governed platforms, including PolyAI and Dilr Voice, differ in how much of the retrieval, the redaction and the audit trail they structure for you, which is where the real time goes.

Here is the concession, because it matters. If you run a small operation, a handful of rights requests a year, recordings that are easy to find, and no history of repeat or malicious requesters, you do not need a governed platform or a formal refusal process at all. A documented, case-by-case judgement and a calendar reminder for the response deadline will serve you better than any software. The governed voice AI route earns its place only when recording volume, redaction burden and audit exposure are all real at once, which for most enterprise contact centres they are.

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 operations.

What happens if we refuse a DSAR wrongly?

A wrongful refusal does not simply pause the request; it moves the dispute onto ground where you are already on the back foot. The requester can complain to you, and then to the ICO, and the controller carries a statutory duty to facilitate complaints under section 164A of the Data Protection Act 2018. A refusal you cannot evidence is what turns a routine request into a regulator file.

Our voice AI complaints-duty guide sets out the acknowledgement and response expectations a rejected requester will invoke.

Does "manifestly unfounded or excessive" apply to requests other than SARs?

Yes. UK GDPR Article 12(5) sits across the data subject rights, not just the right of access, so the same manifestly-unfounded-or-excessive test governs an erasure request, a rectification request or an objection made through your voice channel. The refusal gate and the burden on the controller are the same wherever the right comes from.

The mechanics of an access request for a recording differ, and our DSAR call-recordings guide covers them.

Does an excessive request change the response deadline?

Deciding that a request is excessive does not extend the statutory time limit on its own; the clock, now set by the new Article 12A, keeps running while you assess the ground and communicate your decision. If you intend to charge a fee, the ICO position is that the period can be affected while you await payment, but you must tell the requester promptly.

Our Article 12A deadline guide covers the timing in full.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. This guide is general information, not legal advice; check your own position against the UK and EU voice AI compliance picture, browse our other compliance guides, read more about how we work, and take advice on contested requests. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.