Voice AI and the DSR Clock: The Article 12A Deadline

A voice AI line records every call it handles, which means it holds personal data about every caller who reaches it. Sooner or later one of those callers will ask for their recording, ask for it to be corrected, or ask for it to be deleted. The moment they do, a legal clock starts, and the enterprise running the line has a fixed, evidenced window to respond. Most operations discover how their deadline tracking really works only when they miss one.

The exposure is not theoretical. The Information Commissioner's Office received 42,315 data protection complaints in 2024/25, up from 39,721 the year before, and the regulator states plainly that Article 15 complaints, about the right of access, "account for most of our data protection complaints work". The right most tied to a call recording is the same right that generates the most complaints. Against a backdrop where around 88% of organisations now use AI in at least one function yet only a small minority are AI-mature, the deadline is where good intentions meet an audit.

This guide is about the clock itself, not the substance of any single right. Under the Data (Use and Access) Act 2025, the response deadline that used to sit inside Article 12(3) of the UK GDPR is now measured against a new Article 12A, and the change is more than cosmetic: it redefines when the clock starts. We set out how a voice AI operation logs a request, fixes the relevant time, tracks the deadline across a queue, and evidences an on-time response.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments where every recording is retained, logged and answerable. Or see DATS, our five-stage AI consulting system.

What is the Article 12A response deadline for a data subject request?

The Article 12A deadline is the window in which a controller must respond to a data subject request under the UK GDPR. The duty to respond still lives in Article 12(3), but the Data (Use and Access) Act 2025 replaced the old "within one month of receipt" wording with a reference to "the applicable time period", which the new Article 12A defines as one month beginning with the relevant time.

For a voice AI operation, that one month covers access, erasure, rectification, restriction, objection and portability alike.

Because the deadline is defined once and applies across every right, it is the single cross-cutting mechanic in a voice AI compliance programme. The substance of an erasure request against call data differs entirely from a portability request under Article 20 or a right to object under Article 21, but the same clock governs them all. Treating the clock as one discipline, rather than re-deriving it inside each right, is what keeps a growing queue of requests from quietly slipping past their dates.

When does the one-month clock actually start?

The clock starts at the relevant time, and Article 12A defines the relevant time as the latest of three events: when the controller receives the request, when it receives any information it asked for to confirm the requester's identity, and when any fee it is entitled to charge is paid.

This matters because a request left on a voicemail on the first of the month does not automatically start a one-month countdown. If the operation needs to verify who is calling, the clock does not begin until that identity information arrives.

The distinction is precise, and the statute is worth quoting exactly. The new Article 12A, inserted by section 76 of the Data (Use and Access) Act 2025, provides:

"the applicable time period" means the period of one month beginning with the relevant time, subject to paragraph 3.

That single sentence carries the whole design. The deadline is one month, but it runs from the relevant time, and the relevant time is defined so that identity checks and any lawful fee shift the start forward rather than eating into the response window. Article 12 was amended in the same section to let a controller delay dealing with a request until identity is confirmed, so a voice AI operation that verifies callers is not penalised for doing so, provided the verification is genuine and prompt.

A concrete case makes the difference visible. Suppose a caller leaves an access request on a voicemail on 1 March and the operation asks for proof of identity the same day. If that proof arrives on 10 March, the relevant time is 10 March, not 1 March, and the one-month applicable time period runs from there. An operation that logged only the 1 March voicemail date would chase a deadline over a week too early, and, worse, would record the wrong date as the one it must defend if the response is ever questioned. The date you write down is the date you will be judged against.

Can you pause or extend the DSR clock?

You cannot pause a running clock to buy time, but there are two legitimate ways the timeline flexes. First, the relevant time already accounts for identity verification and any fee, so those steps move the start rather than interrupting the count. Second, Article 12A lets a controller extend the applicable time period by two further months where a request is genuinely complex or where the same person makes a number of requests.

The extension is not automatic: the controller must give notice before the end of the first month and state the reasons for the delay.

There is one further mechanic that behaves like a genuine stop-the-clock, and it applies only to access requests under Article 15. Where the controller reasonably needs more information to identify what a broad request actually covers, the period between asking for that clarification and receiving it does not count towards the deadline. It is narrow and specific: it exists so a caller who asks for "everything you hold" can be pinned down to a workable scope, not as a general lever for delay. For a voice AI deployment, that means a vague request for "all my calls" can be clarified without the clarification window counting against you, but only if you ask promptly and record that you did.

How do you track the deadline across a queue of voice AI requests?

You track it by logging the relevant time for each request, not just its arrival date, and by driving every request off that one field. A voice AI operation rarely handles requests one at a time. Recordings sit in a telephony platform such as Twilio, Genesys or Amazon Connect, transcripts and case notes sit in a CRM such as Salesforce or HubSpot, and a single caller may touch several of them.

The queue only stays honest if each entry carries the date the clock started, the type of right invoked, and the response due date derived from them.

The operational lifecycle below is the discipline that keeps a mixed queue on time. Each step is a field your log should capture and your AI operating model should own, so that no request depends on someone remembering it.

This is where a voice AI programme differs from a paper-based one. The data is machine-generated, high in volume and spread across systems, so the tracking has to be systematic rather than a diary reminder. The same logic underpins our DATS methodology, which maps where personal data actually lives before any deadline is ever counted.

How do you evidence an on-time response?

You evidence it with a record that shows what was asked, when the relevant time was fixed, what was done and when the response left. A late response is a breach, but so, in practice, is an on-time response you cannot prove, because the burden of demonstrating compliance sits with the controller.

For a voice AI deployment that means keeping the request log, the identity-verification trail, any notice of extension with its stated reasons, and the timestamp of the outgoing response, all tied to the same case.

This is the accountability layer the ICO looks for when a complaint lands. Given that the regulator handles tens of thousands of data protection complaints a year and that access requests are the largest category, "we replied eventually" is not a defence a voice AI operation wants to be running. A clean audit trail, produced from the same log that drives the queue, turns a complaint into a short factual answer rather than an investigation. It is the same instinct behind a clear Article 13 privacy notice: say what you do, then be able to show you did it.

Did the Data (Use and Access) Act 2025 move the deadline out of Article 12?

Not exactly. The Data (Use and Access) Act 2025, at section 76, kept the duty to respond in Article 12 but rewrote how the time limit is measured. Article 12(3) no longer reads "within one month of receipt of the request"; it now points to "the applicable time period", and the new Article 12A supplies that period and the definition of the relevant time.

The change commenced on 5 February 2026, so any request received on or after that date runs on the Article 12A clock, while requests received before it keep the time limits that were previously in force.

For a voice AI operation the practical effect is a subtle but real shift in where the clock starts. Under the old wording the month ran from receipt; under Article 12A it runs from the relevant time, which lets identity verification and any fee move the start forward without shortening the window. The same section also amended Article 12(4), so a decision to refuse a request, or to take no action on it, must be communicated within the applicable time period as well; letting the deadline pass in silence is not a lawful option. It is a controller-friendly clarification rather than a longer deadline, and it rewards operations that log the relevant time properly. Because our own corpus already treats Article 12A as live for rectification and restriction requests, the cross-cutting clock is the piece that ties those individual guides together.

What is the best way to manage the DSR clock in a voice AI deployment in 2026?

The best approach in 2026 is to make the relevant time a first-class field in your request log and let the platform, not a person, calculate the due date and warn before it. Self-serve voice AI builders such as Vapi, Retell AI, Bland AI and Synthflow give you the call flow but leave data subject request tracking to you, which suits a low-volume line where a simple manual log suffices.

For a regulated, high-volume deployment, a governed platform such as PolyAI or Dilr Voice, paired with a defined operating model, is the safer answer because retention, logging and the deadline trail are built in rather than bolted on.

There is no single winner for every case, and honesty matters here. If your voice AI line handles a handful of internal calls a month and nobody outside the business will ever exercise a right against it, a spreadsheet and a calendar reminder will hold the line, and paying for governance you do not need is waste. The moment the line is customer-facing, records at volume, and sits under a regulator that counts access complaints in the tens of thousands, the manual approach becomes the thing that fails you. That threshold, not the technology, is what our work on the DUAA complaints duty and the wider voice AI compliance guides are built to help you find.

The same operating-model logic runs through our AI execution office, which puts a standing team around a deployment so that obligations like the Article 12A clock are owned rather than improvised.

Frequently asked questions

What is the "relevant time" for a data subject request?

The relevant time is the point from which the Article 12A one-month clock is counted, and it is the latest of three things: when the controller receives the request, when it receives any information it asked for to verify identity, and when any fee it may lawfully charge is paid. For a voice AI operation, logging the relevant time rather than the raw arrival date is what makes every downstream deadline accurate and defensible.

Does the one-month deadline differ by which right the caller uses?

No. The Article 12A clock is deliberately cross-cutting: the same one-month applicable time period, running from the same relevant time, applies whether a caller asks for access to a recording, its erasure, rectification, restriction, objection or portability. What differs is the substance of the response, not the deadline. Our individual guides, including the one on subject access requests for call recordings, cover that substance right by right.

What happens if you miss the Article 12A deadline?

Missing the deadline is a failure to comply with the UK GDPR, and the data subject can complain to the ICO, which received 42,315 data protection complaints in 2024/25. A single late response is unlikely to bring a fine, but a pattern of them signals a governance failure and invites scrutiny of the whole voice AI programme. The practical risk is rarely one penalty; it is an investigation that starts with a deadline you cannot prove you met.

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