Voice AI and Data Portability: The Article 20 Guide

Data portability is the data-subject right most enterprises get wrong, because it looks like a subject access request and is not one. When a caller invokes it against a voice AI deployment, the question is not "send them everything you hold about the call." It is narrower and sharper: which of the caller's data must you hand back in a structured, machine-readable format, and which of it can you keep out of the export because your own systems created it. Get the line wrong in either direction and you either leak inferred data you never owed or withhold observed data the caller is entitled to move.

The exposure is growing because the volume is growing. McKinsey's The State of AI (November 2025) found that 88% of organisations now use AI in at least one business function and 33% run generative AI in production. Every one of those production voice deployments captures caller data on consent or on contract, which is exactly the trigger condition for Article 20. As adoption normalises, portability requests stop being theoretical.

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 guide for the compliance owner, the data protection lead and the engineering lead who share responsibility for a live voice agent. It covers what Article 20 actually says, which call data is in and out of scope, the recording-versus-transcript question, how portability differs from a subject access request, the legal-basis gate, the format and direct-transfer duties, and what the Data (Use and Access) Act 2025 did and did not change.

What is the right to data portability under Article 20?

Article 20 of the UK GDPR gives a data subject two linked rights: to receive the personal data they provided to a controller in a structured, machine-readable format, and to transmit it to another controller. For a voice AI deployment, a caller can demand a reusable copy of the data they gave your agent and ask you to move it elsewhere. It is a re-use right, not just a read right.

The statute is precise. UK GDPR Article 20(1) states: "The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided." The Information Commissioner's Office treats it as a right to move, copy or reuse data easily, which is why the machine-readable format matters as much as the data. This distinction runs through the UK and EU compliance picture for any conversational system.

Which voice AI call data is covered by data portability?

Data portability covers data the caller provided and data you observed, but not data your systems created. The ICO is explicit that "provided to" is not limited to details a caller actively states; it also includes personal data resulting from observation of an individual's activities. For a voice agent, what the caller said and the raw record of the call are in scope, while the scores and profiles you built from them are not.

In practical terms, sort every field your voice AI platform holds into three buckets. Provided data is what the caller actively gave: their name, account number, the address they confirmed, the appointment they booked. Observed data is the raw record generated by their use of the service: the audio, the verbatim transcript, timestamps, the DTMF keys they pressed. Both are in scope, because in the ICO's words the "provided to" test reaches "personal data resulting from observation of an individual's activities" such as raw usage data.

Derived and inferred data is the third bucket, and it is out of scope for portability. This is anything your models or agents created from the raw material: the sentiment score, the intent classification, the confidence value, the risk flag, the summary an agent wrote after the call. The ICO gives the direct example that if you use data an individual provided to create a user profile, that profile is not in scope. You built it; the caller did not provide it. Keeping this bucket out of the export is the correct reading of the right, not withholding.

Is a call recording or transcript covered by Article 20?

Yes, subject to the gates, and this is where teams draw the line in the wrong place. A call recording and its verbatim transcript are the raw, observed record of what the caller provided during their use of the service, so they fall within the ICO's "provided to" meaning, not outside it. The recording feels excludable because of the format phrase in Article 20, but that phrase governs how you deliver data, not what qualifies.

That matters because the hard problem then moves from scope to delivery. Article 20 requires a structured, commonly used and machine-readable format, and raw audio is none of those things in the sense the article intends. So the practitioner question for a voice deployment is not "is the recording in scope" but "what structured export represents it." A reasonable answer is a machine-readable package: the transcript as structured text, the field-level data the caller confirmed as JSON or CSV, and call metadata as structured records, with the audio supplied alongside where it is genuinely part of the provided data. This is a delivery-design decision, and it is distinct from the access-to-the-recording question a DSAR raises, which is about giving a copy rather than a reusable, transferable dataset.

How is data portability different from a subject access request?

Portability and access are different rights with different scopes. A subject access request under Article 15 gives the caller a copy of all their personal data, including derived data and the recording, with no re-use duty attached. Article 20 portability is narrower on scope but heavier on format: it covers only provided and observed data, only on a consent or contract basis, and it must arrive structured, machine-readable and transferable. Access is about seeing; portability is about moving.

The practical consequence is that the two requests pull different data and produce different deliverables, so you should not run one process for both. Our post on DSARs and call recordings owns the access side: how you locate, redact and hand over a copy of everything, recording included. This guide owns the portability side: how you isolate the provided-and-observed subset, exclude the derived scores, and export it in a reusable format with a direct-transfer path. Portability also sits apart from the right to rectification, which corrects an inaccurate call record, and from the right to object under Article 21, which stops processing rather than moving data.

Which legal basis lets a caller port their voice AI data?

Only consent and contract trigger portability, which quietly excludes a large share of voice AI processing. Article 20 applies where processing rests on consent under Article 6(1)(a), explicit consent under Article 9(2)(a), or a contract under Article 6(1)(b), and where it is carried out by automated means. If your voice agent processes a caller's data on legitimate interests, that data is not portable. The legal basis, not the data type, is the switch.

This is why mapping your lawful bases per processing purpose is a prerequisite, not a nicety. A single call often spans several bases: the service you deliver under contract, the fraud checks you run on legitimate interests, the marketing you took consent for. The contract and consent portions are portable; the legitimate-interests portion is not. The Data (Use and Access) Act 2025 added a new "recognised legitimate interests" basis under Article 6(1)(ea), and data processed on that basis is also outside Article 20, for the same structural reason: it is not consent and it is not contract. Because voice AI is inherently automated, the "automated means" condition is almost always met, so the basis test does the real filtering. If your special-category handling relies on an appropriate policy document, check whether that processing rests on explicit consent, because only then does it become portable.

What format must the data be in, and must you transfer it directly?

The format must be structured, commonly used and machine-readable, and where technically feasible you must transfer it directly. The ICO points to CSV, XML and JSON as formats that meet the machine-readable test. A flat PDF or a proprietary blob only your platform can open does not satisfy Article 20, because the right exists for downstream re-use. For a voice AI export, that means field-level data as CSV or JSON and transcripts as structured text.

The second duty is direct transfer. Article 20(2) gives the data subject "the right to have the personal data transmitted directly from one controller to another, where technically feasible." A caller can therefore ask you to send their data straight to a new supplier rather than to themselves, and you must do so where it is technically possible. That qualifier is real, but it is not a blanket excuse; it means you should design an export path that can target another controller, not that you can refuse because you never built one. Teams that treat portability as an afterthought discover the direct-transfer duty is the hardest part to retrofit. Building the export interface early, as part of the operating model for the voice estate, is far cheaper than bolting it on under a one-month deadline.

Did the Data (Use and Access) Act 2025 change data portability?

No, the individual Article 20 right is unchanged, and the Act's own portability contribution is a separate regime. Checked against the current statute, UK GDPR Article 20 is up to date with all changes in force on or before 23 August 2026, with no textual amendments to the article. The Data (Use and Access) Act 2025 left the right to data portability exactly as it stood: same scope, same gates, same format and transfer duties.

What the DUAA did add lives in Part 1, "Access to customer data and business data," widely called the smart data framework. These are powers for the government to make sector-specific regulations that force data holders to share customer and business data, extending the Open Banking model into other sectors. They are enabling powers, not a self-executing right, and they have not been switched on for voice or telecoms. So they do not change what a caller can demand from your voice agent today; that is still governed entirely by Article 20. The DUAA did make process changes that touch every rights request, including how the automated decision-making rules under Articles 22A to 22D now work and the Secretary of State powers under Article 22D, but the portability right itself was not among them.

What is the best way to build voice AI for Article 20 compliance in 2026?

The best approach is the one that makes provided-and-observed data separable and exportable by design, and no single platform hands you that for free. General-purpose voice platforms such as Vapi, Retell AI and Synthflow give you build velocity and low-level control over your own data. A managed platform such as PolyAI, or a governed deployment through Dilr Voice, moves more of that responsibility onto the vendor, which suits regulated teams.

Judged on Article 20 readiness specifically, the criteria are concrete: can the platform tag data at capture as provided, observed or derived; can it export the provided-and-observed subset in CSV, XML or JSON without hand-assembly; and can it transmit directly to another named controller. There is an honest concession here: for a low-volume line where portability requests are rare, a general platform plus a manual export runbook is perfectly defensible, and building a bespoke export interface would be over-engineering. The gate is not which vendor you pick, it is whether your data protection operating model has decided, in advance, how each of the three data buckets is stored and released. That decision is what our AI placement diagnostic exists to force, and it is the discipline behind the DATS methodology we run with clients. You can see the wider approach we take to placing AI inside regulated systems, how a governed rollout runs through our execution office, and the product itself at Dilr Voice.

How long do you have to respond to a data portability request?

One month, with a possible extension. Under the Data (Use and Access) Act 2025, the response window is set by the new UK GDPR Article 12A: one month beginning with the relevant time, reaching portability through Article 12(3). You can extend it by two months for complex or numerous requests, and the clock can pause where you reasonably need more information to confirm the caller's identity. For a voice AI deployment, identity checks are the usual reason to pause.

Can a caller ask you to send their voice AI data directly to another provider?

Yes, where it is technically feasible. Article 20(2) gives the caller the right to have their data transmitted directly from one controller to another, so a caller leaving your service can ask you to send their voice AI data straight to a new supplier. The "technically feasible" test lets you decline an impossible transfer, not refuse because you never built the capability. Designing an export that can target another controller is part of the duty.

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

The through-line for every data-subject right is the same: know which data you hold, why you hold it, and under which basis. Portability rewards the teams that answered those questions before the request arrived, and punishes the ones improvising against a one-month clock. If your voice estate cannot yet separate provided data from derived scores at export time, that is the gap to close, and it is closely related to how you handle consent withdrawal mid-call and the rest of the compliance cluster. Read more about Dilr.ai and the operators behind this work.

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.