Voice AI Data Breach Notification: The Article 33 Guide

A voice AI estate is a personal data machine. Every inbound call is captured, transcribed, embedded, logged, routed to a CRM and often retained for months. When something goes wrong with that pipeline, a misrouted recording, a leaked transcript, an exposed storage bucket, a debug log left public, the question is no longer only "how do we fix it". It is "do we have 72 hours to tell the regulator, and has the clock already started". Most enterprises deploying voice AI agents have a mature security incident process and almost no muscle memory for the UK GDPR Article 33 notification duty that runs alongside it.

That gap matters more as voice moves into production. McKinsey's State of AI, published in November 2025, found that 88% of enterprises now use AI in at least one function but only 33% have taken a use case into production and just 14% report material EBIT impact. Voice is one of the first AI systems many firms put in front of real customers at scale, which means it is also one of the first to generate a reportable personal data incident. This guide sets out what counts as a breach in a transcription pipeline, who notifies whom, when the Article 33 clock starts, and when the affected callers must be told. It sits alongside our wider guide to the UK and EU compliance rules for voice AI.

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 counts as a personal data breach in a voice AI pipeline?

A personal data breach is defined in Article 4(12) of the UK GDPR as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data". In a voice AI estate that covers a leaked call transcript, a recording emailed to the wrong recipient, a public storage bucket of audio, or a customer record that a prompt injection tricked the agent into reading out.

Availability loss counts too, so a corrupted recording store that leaves you unable to retrieve call data is also a breach.

The trap for voice teams is treating a breach as only a hacker exfiltrating data. Most reported incidents are mundane: a caller's details disclosed to the wrong person, a retention job that deletes recordings you were legally required to keep, an integration that syncs transcripts to an unprotected analytics table. Because call recordings and their retention sit at the centre of a voice deployment, that store is usually the first place a breach surfaces, and the first thing an ICO investigation asks to see.

Who has to notify whom under Article 33?

Article 33 splits the duty by role, and getting the roles wrong is the most common mistake. The controller, normally the enterprise deploying the agent, must notify the ICO. The processor, normally the voice AI vendor, must notify the controller. The primary obligation binds the controller, not the vendor, as the text of Article 33(1) makes plain:

"In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the Commissioner, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons."

Article 33(2) then deals with the vendor. It says only that "the processor shall notify the controller without undue delay after becoming aware of a personal data breach". Note what is missing: the processor has no 72-hour figure and no duty to contact the ICO. The vendor's job is to raise the alarm to you quickly; your job is to run the regulatory clock. This is exactly why the split between controller and processor under Article 28 is not a paperwork detail. If your contract does not pin how fast the vendor must tell you, your own 72 hours can be half gone before you even know.

When does the 72-hour breach clock actually start?

The clock starts when the controller becomes aware of the breach, and awareness has a precise meaning. Recital 87 and the ICO's guidance treat you as aware once you have a reasonable degree of certainty that a security incident has led to personal data being compromised. It is not the moment of the underlying event, and it is not the moment of vague suspicion.

For a vendor-detected breach, your awareness is normally triggered when the processor notifies you under Article 33(2), which is why the notification timeline in the vendor contract is load-bearing.

Operational incident guides often simplify this to "the clock runs from detection". That is close but not exact, and the difference can cost you a day. Our voice AI incident response runbook owns the containment and forensics mechanics; this guide owns the regulatory timing. You cannot game awareness by stalling the investigation. The ICO expects you to prioritise establishing the facts, and a deliberately slow triage designed to delay awareness is itself a compliance failure. Dilr Voice logs a tamper-evident timeline of every incident so the awareness moment is a matter of record, not argument.

Do you always have to report a voice AI breach to the ICO?

No. Article 33(1) requires notification unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons". The ICO frames the same test the other way round: if a risk is likely you must notify the ICO, and if a risk is unlikely you do not have to. The catch is that a decision not to report is one you must be able to justify, so a defensible risk assessment is not optional.

A single caller's name disclosed and immediately recovered may not be reportable; a leaked set of transcripts containing financial or health detail almost certainly is.

Whatever you decide, Article 33(5) requires the controller to "document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken". That breach register covers every incident, reportable or not, because the ICO uses it to verify your judgement calls. A voice deployment that quietly resolves incidents without logging them has no evidence it applied the test at all. The same discipline that governs the right to erasure of call data applies here: the record is the compliance.

When must you tell the affected callers?

Telling the ICO and telling your customers are two different thresholds. Article 34(1) requires the controller to communicate a breach to the data subject "without undue delay" only "when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons". High risk is a deliberately higher bar than the risk test for notifying the ICO, so many reportable breaches never require a customer notification at all.

When you do notify callers, Article 34(2) says the message must use "clear and plain language" and carry the same core detail you gave the regulator.

Article 34(3) then sets three carve-outs where you need not tell individuals directly: where the data was rendered unintelligible by measures such as encryption, where you have taken later steps that mean the high risk is no longer likely, or where direct contact would involve disproportionate effort, in which case a public communication will do. For a voice estate this is a strong argument for encrypting recordings and transcripts at rest, because encryption that holds can move a breach below the customer-notification line entirely.

What must an Article 33 notification to the ICO contain?

Article 33(3) lists the minimum content, and you should build a template around it now rather than draft it under a 72-hour deadline. The notification must describe the nature of the breach including the categories and approximate number of data subjects and records affected; give the name and contact details of your data protection officer or other contact point; describe the likely consequences; and describe the measures taken or proposed to address it and mitigate harm.

For a voice AI breach, the "approximate number" is where good call transcript logging earns its keep, because you can enumerate exactly which calls were exposed.

You do not need every detail to start. Article 33(4) allows the information to be provided "in phases", and the ICO expects you to notify within 72 hours even if you do not yet have the full picture, then follow up. The worst outcome is silence past the deadline while you wait for certainty. A rehearsed template, a named decision-maker and a working line to the ICO turn the 72 hours from a scramble into a procedure. That is the difference an AI operating model is meant to build in before the first incident, not after.

How do the PECR and DORA breach clocks differ for a voice estate?

Two other regimes can apply on top of Article 33, and they bind different duty-holders. The Privacy and Electronic Communications Regulations impose a separate breach-notification duty, but only on a "service provider", meaning a provider of a public electronic communications service such as a telco or internet provider. If your enterprise simply uses a voice agent you are not a PECR service provider, and Article 33 is your obligation.

Crucially, the Data Use and Access Act changed the PECR clock from 24 hours to 72 hours from 20 August 2025, aligning it with the UK GDPR window.

Financial services adds a third clock. Under the EU Digital Operational Resilience Act, an in-scope financial entity must send an initial major-incident report far faster, no later than 24 hours from becoming aware of the incident. That regime governs ICT incident reporting to a financial regulator, not personal-data breaches to the ICO, so a UK bank running a voice agent in the EU can face both at once. Our DORA operational resilience guide covers that framework in full; the point here is that a single voice incident can trip more than one deadline, and your runbook must know which apply.

What is the best breach-notification setup for an enterprise voice AI deployment?

The best setup is the one you can execute under pressure, and it has four parts: a breach register that captures every incident per Article 33(5); a data processing agreement that pins how fast the vendor must alert you; a severity playbook that pre-decides the risk and high-risk thresholds; and a rehearsed 72-hour drill with a named owner.

Judge any voice platform on whether it gives you the incident timeline, the affected-call enumeration and the export you need to notify, not on whether it markets itself as "compliant". Compliance is a property of your process, and the platform is one input to it. Building that process is what our AI execution office runs for regulated clients, and it reflects our approach to placing AI where the compliance risk actually sits.

There is one scenario where lighter is better. A single-vendor, single-site pilot handling low-sensitivity calls, with no special-category data and short retention, does not need a change advisory board around its breach process; a clear internal escalation and the vendor's built-in logging are proportionate. Platforms such as Vapi, Retell AI, Bland AI, Synthflow and PolyAI can each support that kind of pilot. Once the estate carries financial, health, children's or identity data across international transfers and multiple integrations like Twilio, Salesforce and Stripe, the full apparatus stops being overhead and starts being the thing that keeps a bad day off the front page.

What is the penalty for missing the Article 33 deadline?

Failing to notify a reportable breach is an infringement of a controller obligation, which sits in the standard penalty tier. Under Article 83(4) of the UK GDPR and section 157 of the Data Protection Act 2018, that carries a maximum fine of the higher of £8.7 million or 2% of total worldwide annual turnover. The higher tier of £17.5 million or 4% applies to breaches of the core data principles rather than to a reporting failure.

Does the 72 hours include weekends?

Yes. The 72-hour window runs continuously from the moment of awareness and does not pause for evenings, weekends or bank holidays, which is why a voice estate needs an out-of-hours escalation path rather than a working-day process. The ICO is explicit that you should notify within 72 hours. A breach discovered on a Friday afternoon does not buy you until Monday, and Dilr Voice alerting is built to reach an on-call owner immediately.

Is a leaked call transcript always a reportable breach?

Not automatically. A leaked transcript is a personal data breach the moment it is disclosed without authorisation, but whether it is reportable to the ICO turns on the risk assessment. A transcript of a low-sensitivity enquiry recovered within minutes may fall below the risk threshold; a transcript containing financial details, health information or credentials will almost always be reportable, and may cross the Article 34 high-risk line that requires telling the caller too. The register records the call either way.

Want this built into your deployment? Try Dilr Voice live, book an AI placement diagnostic, see our DATS methodology, or read the rest of our voice AI compliance writing.

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.