Voice AI DPIA template: a working data protection impact assessment

Why voice AI requires a DPIA

Article 35 of UK GDPR (and the equivalent in EU GDPR) requires a Data Protection Impact Assessment whenever processing is likely to result in a high risk to the rights and freedoms of natural persons. Voice AI deployments trigger at least three of the ICO's listed criteria: large-scale processing, automated decision-making with significant effect, and — wherever voice biometrics are present — processing of special-category data.

The DPIA is not a launch artefact. It is a living document maintained by the data controller, refreshed at every material change to the processing, and produced on demand to a regulator. A DPIA that was signed off six months before launch and never updated is evidence of a failed governance process, not evidence of compliance.

The nine sections a defensible DPIA contains

These map directly to the ICO's published template and to the EDPB's Article 35 guidance. Other jurisdictions add sections (CNIL adds a French legal-basis box; the Irish DPC adds a vendor-management appendix) but the core nine are universal for UK and EU voice AI deployments.

1. Description of the processing — what data, from whom, to whom, for what, retained how long
2. Necessity and proportionality — why voice AI rather than a less intrusive alternative
3. Lawful basis under Article 6, and Article 9 condition if special-category data is in scope
4. Consultation — DPO sign-off, and where required, customer or works-council consultation
5. Risk assessment — likelihood and severity of each identified risk to the data subject
6. Mitigations — technical and organisational measures that bring residual risk to acceptable
7. Automated decisioning analysis under Article 22 — and the human-in-the-loop design where it applies
8. International transfers — sub-processor map, transfer mechanism, transfer impact assessment
9. Sign-off and review cadence — who owns it, when it is next reviewed, what triggers an off-cycle review

Section-by-section: what to write

Description of processing: enumerate the data categories in the call path — caller phone number, transcript, intent labels, identifiers used for authentication, payment data if in scope, and any biometric voice template. State the source (caller, internal system, third party), the recipient (each sub-processor by name), and the retention period for each category.

Necessity and proportionality: do not write 'because it is cheaper'. The defensible answer is that voice AI handles a defined intent set faster than the human-only alternative, with measured quality, and that less-intrusive options (DTMF IVR, web self-service) were considered and have known coverage gaps for the in-scope use cases.

Lawful basis: contract performance (Article 6(1)(b)) covers most servicing calls; legitimate interest (6(1)(f)) covers measurement and quality monitoring with a documented balancing test; consent is rarely the right basis for inbound calls because it cannot be freely given when the customer needs the service.

Article 9 condition: only relevant when voice biometrics are used for authentication. The condition is normally 'explicit consent' (9(2)(a)) — and the consent flow has to be auditable per caller.

Article 22 analysis: a call that routes to a human, books an appointment, or quotes a balance is not Article 22 decisioning. A call that closes an account, declines a transaction, or denies a claim is — and requires either explicit consent, contractual necessity, or a legal basis plus a documented right to contest and human review.

Risk register: the entries that have to appear

A DPIA without a risk register is not a DPIA. The entries below appear in almost every voice AI deployment; missing them is a sign the assessment was templated rather than worked.

Sub-processor map: the artefact procurement actually uses

The DPIA's sub-processor map is the artefact that procurement, security, and the DPO all reach for. It lists every party in the call path — voice platform, STT provider, LLM provider, TTS provider, telephony carrier, recording vendor, analytics processor — with jurisdiction, transfer mechanism, and the contractual purpose limit applied to each.

A platform that cannot produce its sub-processor map without three weeks of internal coordination is a platform with an unmanaged data flow. Treat that gap as a procurement gate, not a DPIA footnote.

Review cadence and triggers

The DPIA is refreshed annually as a calendar event, and off-cycle whenever any of the following changes: a sub-processor is added or replaced, the model provider changes, a new intent is added that introduces Article 22 decisioning, the retention period for any data category changes, or a near-miss incident occurs in production.

Each off-cycle refresh updates the risk register and the sub-processor map, and is countersigned by the DPO. Version-control the document — the regulator will ask for the history, not the latest copy.