Voice AI DSARs: The Third-Party Balancing Record

When a caller asks for a copy of their call recording, they are asking for a file that almost never contains only their own personal data. Another customer named on the line, the human agent who took the transfer, a relative in the room during an outbound call: their voices and their details are captured too. A subject access request forces the enterprise to decide what to hand over and what to hold back, and the harder half of that decision is being able to prove, months later, that the choice was reasonable.

That second half is where voice AI DSAR programmes come unstuck. The redaction itself is a solved engineering problem. The exposure is the undocumented judgement call: withholding another person's data with nothing on file to explain why. When the requester complains, the Information Commissioner's Office (ICO) does not ask to hear that you redacted a recording. It asks to see the decision. The ICO received 42,315 data protection complaints in 2024/25, up from 39,721 the year before. When a subject access request touches other people's data, mishandling the withholding decision is one way an organisation joins that caseload.

This guide is the deployer-side method for one specific artefact: the third-party balancing record. It covers the legal basis for withholding, the statutory factors you must weigh, how this differs from a legitimate interests assessment, and what a defensible record actually contains. It cedes the redaction mechanics themselves, identifying voices and cutting audio, to our companion guide on subject access requests for call recordings.

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 third-party balancing decision in a DSAR?

A third-party balancing decision is the judgement a controller makes when a subject access request would reveal personal data about someone other than the requester. Under UK GDPR Article 15(4), the right to a copy must not adversely affect others, and DPA 2018 Schedule 2, Part 3, paragraph 16 says the controller is not obliged to disclose data that identifies another individual unless that person consents or disclosure is reasonable without consent.

The statute frames it as a limit on the copy the requester is entitled to, not as a general licence to withhold. Article 15(4) is deliberately narrow:

"The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others."

UK GDPR, Article 15(4)

Paragraph 16 then does the operative work. Sub-paragraph 16(1) removes the obligation to disclose only "to the extent that" doing so would reveal another identifiable individual. Sub-paragraph 16(2) restores the obligation where the other person has consented, or where it is reasonable to disclose without their consent. So the default is not blanket refusal and it is not blanket disclosure. It is a case-by-case call that the enterprise, as controller, has to make and stand behind. Note that the newer Article 15(1A), added by the Data (Use and Access) Act 2025, first narrows the scope: you owe the requester only what a reasonable and proportionate search surfaces, which sets the pool of recordings you then assess for third-party content.

Which factors decide whether disclosure is reasonable?

Paragraph 16(3) is explicit about the test. In deciding whether it is reasonable to disclose without consent, the controller must have regard to all the relevant circumstances, and the statute names five: the type of information that would be disclosed; any duty of confidentiality owed to the other individual; any steps taken to seek that person's consent; whether they are capable of giving consent; and any express refusal of consent.

Each factor is a distinct question that leaves a trace you can record. This is the enumerated list that most voice AI DSAR processes skip. Many programmes stop at "identify the third party, then redact", which is the mechanic. The reasonableness test asks something different: given who this third party is and how the information was captured, is disclosure defensible? The ICO calls paragraph 16(3) "a non-exhaustive list" and states plainly that "ultimately, it's your decision" as controller. That decision has to be made per factor, per third party, per request. The table below maps each statutory factor onto the kind of evidence a voice AI programme can actually capture.

The point of tabulating it is not bureaucracy. It is that a reasonableness decision made against five named factors is far easier to defend than a one-line note that says "redacted for GDPR". The data minimisation and redaction pipeline removes the data; the balancing record explains the choice.

How is this different from a legitimate interests balancing test?

They are different statutory tests that share a word. A legitimate interests assessment sits under UK GDPR Article 6(1)(f) and asks whether your interest in processing is overridden by the individual's rights, the familiar three-part purpose, necessity and balancing test used to establish a lawful basis. The third-party DSAR test sits under DPA 2018 Schedule 2 paragraph 16 and asks something narrower: whether it is reasonable to disclose one identified person's data to a different person who has requested it.

Confusing the two is a common and expensive error, because the paperwork, the factors and the timing all differ. A legitimate interests balancing test is done once, up front, to justify running the processing at all. The paragraph 16(3) reasonableness assessment is done reactively, inside a live DSAR, against a one-month clock. If your governance treats them as the same document, you will either over-disclose other people's data or miss the response deadline under Article 12A. Keep the two records separate and cross-referenced.

What does a defensible balancing decision record contain?

A defensible balancing record is a per-request artefact that captures who the third parties were, how each paragraph 16(3) factor was weighed, what was decided, and who authorised it. The ICO's own guidance is direct: you should "keep a record of what you decide and why", for example why you chose not to seek consent, or why seeking it was inappropriate. That sentence is the whole reason this record exists.

Without it, a reasonable decision and a careless one look identical after the fact. In practice the record needs a small, fixed set of fields so it can be produced quickly and read consistently by whoever reviews it later. The workflow that populates it is short, but every gate leaves an entry.

The fields that make the record auditable are unglamorous but non-negotiable: a request reference tying it to the DSAR; a list of third parties identified in the recording or transcript; the factor-by-factor assessment; the decision and its reasoning; the name and role of the person who signed it off; and the date. Store it alongside the request, not inside the redaction tooling, because the redaction tool proves what you cut, not why you were entitled to. This is exactly the kind of "prove the decision" discipline the DATS methodology builds into a deployment, and it is why our AI operating model consulting treats the decision log as a first-class part of the system rather than an afterthought.

How do you build this into a voice AI DSAR workflow at scale?

You build it by making the balancing record a mandatory, structured step in the request workflow, not a free-text box someone fills in under deadline pressure. The reasonable and proportionate search of Article 15(1A) defines the recordings in scope. Automated triage then flags which of those contain other identifiable speakers, drawing on speaker separation and the transcript, before any human weighs the factors.

The same diagnostic logic that governs the rest of a voice deployment applies here: instrument the step, log every decision, and make the log the source of truth. Scale is the reason this cannot stay manual. A single enterprise voice programme can generate thousands of hours of recordings a month across platforms such as Twilio and CRMs like Salesforce, with transcripts held in a separate speech-to-text layer. Third-party data is scattered across all three. If your voice AI agents capture structured metadata at the point of the call, who spoke, in what role, flagged for sensitivity, the reasonableness assessment becomes a review of pre-surfaced evidence rather than a fresh investigation per request. The redaction step still happens, and we cover its mechanics in the companion SAR guide, but the decision to redact is now recorded as it is made.

The same discipline underpins our AI execution office, where governance artefacts like the balancing record are treated as operational deliverables, not compliance theatre.

Only the controller can carry this duty. Paragraph 16 binds the organisation holding the data, not the requester and not your technology vendor. A processor can build the workflow and surface the evidence, but the reasonableness decision, and the record of it, is the controller's to own. That distinction matters when you scope sub-processor authorisation for the transcription and storage layers.

What happens if the requester complains to the ICO?

If a requester challenges what you withheld, the balancing record is the first thing that decides the outcome. A complaint to the ICO, or an appeal to the First-tier Tribunal (Information Rights), turns on whether your decision to withhold was reasonable under paragraph 16(3). With a factor-by-factor record, you can show your working: these were the third parties, this is how each factor was weighed, this is who signed it.

Without one, you are reconstructing a judgement from memory against a regulator's timeline. This is the practical case for treating the record as evidence from the start. The ICO's role is to assess whether the controller acted reasonably, and "reasonable" is demonstrated, not asserted. A programme that logs the decision at the moment of the DSAR can answer a challenge from its own records; one that redacts silently has to reconstruct the reasoning after the fact. It is the same reason erasure decisions and rectification decisions on call data should be logged: the artefact outlives the memory of the person who made the call.

Across the wider picture, this is one governance discipline among many that separate the enterprises capturing real value from AI from those that stall. The gap is rarely the model; it is the operating discipline around it. A voice programme that cannot defend a routine rights request is not a programme ready to scale.

How long should you keep the balancing record?

Keep the balancing record for as long as it might be needed to defend the decision, which in practice means at least as long as the underlying recording and the window in which a complaint or appeal could arise. The record is itself personal data about the third party and the requester, so it is subject to the same storage limitation principle as the recording: retained for a defined, justifiable period, then deleted.

Set the retention of the decision log to match your call recording retention schedule, and document that alignment so a reviewer can see the two were designed together rather than left to drift.

Does the requester have to be told why data was withheld?

It is good practice to do so. Telling the requester that some content has been withheld, with a general reason, supports the transparency the right of access is built on, and you can do this without revealing the third-party data itself. You are not required to identify the third party or reproduce what you withheld. A short, consistent statement that some content was withheld to protect others' rights, backed by your internal balancing record, is the proportionate approach.

Can you refuse a whole recording rather than redact it?

Only where redaction genuinely cannot separate the third party's data from the requester's, and even then the bar is high. Paragraph 16 removes the obligation only "to the extent" disclosure would reveal another individual, so the default expectation is partial disclosure with the third-party elements removed. Where a conversation is so interleaved that clean separation is impossible, a summary may be appropriate, and that judgement, too, belongs in the balancing record with its reasoning.

Is the balancing record itself disclosable in a later DSAR?

Potentially, in part. If the third party later makes their own subject access request, elements of the record that constitute their personal data may be within scope, and if the original requester asks again, the same third-party protections apply in reverse. Write the record in the knowledge that it may be read by the people it describes. Factual, factor-based reasoning survives that scrutiny; loose or dismissive notes do not.

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.

For the broader rights-request picture, the compliance library covers the adjacent duties: the one-month response clock, when a request is manifestly unfounded or excessive, and how automated decision safeguards under Article 22C interact with the access right. Each is a decision your voice programme has to make, and each is easier to defend when the making of it was recorded.

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.