Where Does AI Call Data Actually Go? The Questions That Work

Is an AI receptionist GDPR compliant?

No voice AI product is GDPR compliant or non-compliant in the abstract, because compliance is not a property of software. It is a property of a deployment: who processes what, where, under which contract, for how long. That is why the question as usually asked has effectively one answer in the market, and why the answer carries no information. The word costs nothing to print on a homepage and nothing to say on a sales call, and it is not a lie, because nobody has defined it tightly enough for it to be one.

The question underneath it is mechanical, and nobody can bluff it. Trace one call. A customer speaks. That audio leaves the public phone network and enters something. It is transcribed by something, somewhere. The resulting text goes to a model that runs somewhere, possibly on a different continent from the audio. A summary lands in a diary or a CRM. A recording, if one is kept, sits in storage under a retention policy that somebody chose.

Every one of those hops is a country, a company, a contract and a retention period. You are answerable for all of them: to the person who called you, to your supervisory authority, and increasingly to the procurement team of whichever larger client is currently sending you a supplier assurance questionnaire. Your name is on the answer, not the name of your vendor. The short version of this argument, written for a buyer rather than a reader, is on our page about where the recording of your customer's call actually goes.

Where does the audio of an AI-handled call actually go?

On a single call it passes through several separate companies, and the route set out below has six distinct stops. The useful way to hold this is not as a security diagram, which our guide to voice AI security and data protection already covers hop by hop, and not as an encryption question, which is treated in the data encryption standards guide. Hold it as a route, with four facts attached to every stop: which company, which country, which contract, which clock.

The row most buyers never separate out is the second one. Raw audio and a transcript are not the same asset. A transcript is a reduction: it carries the words. The audio carries the words plus the voice that said them, the hesitation, the third party audible in the background, the child, the argument, the address read out twice. Under Article 4 of the GDPR, personal data is any information relating to an identified or identifiable person, and a recording of somebody speaking is squarely that. It becomes special-category biometric data only where it is processed specifically to identify that person uniquely, which most voice deployments do not do, but the ordinary case is exposure enough.

So the meaningful sub-processor question has two halves. Who is on the list, and which of them hears the customer as opposed to reading a summary of them. Ask the two halves separately and the second one does most of the work.

Where is patient call data stored, and why is a clinic call different?

There is no single storage location, and the fact that buyers expect one is the whole problem. A clinic call produces the audio, a transcript, the model inputs, a summary written into the practice system, and a call detail record sitting with the carrier. That is five copies, potentially in five places, on five clocks, under five contracts. Any vendor who answers "in the EU" and stops has described where their company is registered, not where each copy of your patient is processed.

The clinic case is sharper than the general case for one reason. A caller who says "I have had toothache since Friday and I am on blood thinners" has almost certainly produced data concerning health in the first fifteen seconds, before any form is filled in and before anyone decides whether they are a patient. Article 9(1) places data concerning health in the special categories whose processing is prohibited unless a specific condition applies. Nothing about that changes because the call was answered by software rather than a receptionist. On any ordinary reading that audio is data concerning health from the opening seconds, which makes every hop above a hop carrying it.

This is also where the excuse fails. Small controllers frequently assume that a large supplier's standard terms are simply the terms, and that accepting them transfers the problem. The European Data Protection Board addressed that directly in Guidelines 07/2020 on the concepts of controller and processor (version 2.1, adopted 7 July 2021), at paragraph 110: the imbalance in contractual power between a small controller and a big service provider "should not be considered as a justification for the controller to accept clauses and terms of contracts which are not in compliance with data protection law, nor can it discharge the controller from its data protection obligations". In that arrangement the practice is normally the controller, and the practice answers.

Why can most vendors not answer this question?

Structurally, rather than dishonestly. Much of this category is assembled on top of a handful of specialist suppliers, and a supplier chosen for latency and unit price is not necessarily a supplier chosen for jurisdiction. Where one gets swapped for a cheaper or faster one, the map goes stale without anyone updating it. The honest version of the answer is a list nobody ever wrote down, and writing it down would mean asking their own suppliers questions they have never asked, and living with whatever comes back.

The EDPB itself concedes how hard the exercise is. In Recommendations 01/2020 on measures that supplement transfer tools (version 2.0, adopted 18 June 2021), the very first step of the six-step roadmap is called "know your transfers", and the text observes that "recording and mapping all transfers can be a complex exercise for entities engaging into multiple, diverse and regular transfers with third countries and using a series of processors and sub-processors". That is the regulators' own board saying the work is real work. It is not a reason to skip it. It is a reason that the vendors who have done it can prove it in a way the others cannot imitate.

Which brings up the distinction that catches the most vendors: where a company is registered versus where the audio is processed. Those are different facts and they are frequently different countries. A company incorporated inside the European Union can send audio to a transcription service in one place and text to an inference region in another, under contracts you have never seen, with nothing on the website contradicting the phrase GDPR compliant in the footer. The registration is not evidence about the path. It is evidence about a filing.

And where a hop does sit outside the EEA, Article 44 reaches further than most buyers expect. It applies to transfers "including for onward transfers of personal data from the third country or an international organisation to another third country or to another international organisation". A sub-processor of your vendor sending the data on again is still your problem. Our page on EU data residency for voice AI covers the default side of this, and the comparison of GDPR-compliant voice AI platforms by data residency covers how vendors position on it.

What does the law actually entitle you to ask for?

More than most buyers realise, which is why the request tends to land harder than a polite question deserves. Article 28 does four things at once. Paragraph 1 obliges you to use only processors providing sufficient guarantees. Paragraph 2 forbids the processor from engaging another processor without your prior specific or general written authorisation, and, where you have given general authorisation, requires it to inform you of intended additions or replacements so you can object. Paragraph 3(h) requires the contract to oblige the processor to make available to you all the information necessary to demonstrate compliance with the obligations in Article 28, and to allow for and contribute to audits. Paragraph 4 imposes the same obligations down the chain, with the first processor remaining fully liable to you for the performance of the next one.

In October 2024 the EDPB pushed this further in Opinion 22/2024 on certain obligations following from the reliance on processors and sub-processors. Its conclusion is that controllers, while acknowledging this is not explicit in the provisions themselves, "should have the information on the identity (i.e. name, address, contact person) of all processors, sub-processors etc. readily available at all times", regardless of the risk of the processing, and that the processor "should proactively provide to the controller all this information and should keep them up to date at all times". It also makes clear that the ultimate decision to engage a given sub-processor, and the responsibility for verifying its guarantees, stays with you rather than transferring to the vendor who proposed it.

The same opinion is honest about the limit, and quoting the limit is how you tell someone has actually read it: the EDPB takes the view that a controller does not have a duty to systematically demand copies of the sub-processing contracts themselves, and should judge case by case whether it needs them. So the entitlement is to the identities and the picture, not automatically to every contract in the chain. That is exactly the right scope for a procurement conversation.

Two more provisions turn the list from a nice-to-have into an operational necessity. Article 30(1) requires your own record of processing activities to contain "the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organisations" and, where transfers happen, "the identification of that third country or international organisation". You cannot complete a document you are legally required to maintain unless your vendor tells you what goes in it. And Article 15(1)(c) gives the caller a right to know the recipients. In Case C-154/21, RW v Österreichische Post AG, decided on 12 January 2023, the Court of Justice held that the right of access "entails, where those data have been or will be disclosed to recipients, an obligation on the part of the controller to provide the data subject with the actual identity of those recipients", unless identification is impossible or the request is manifestly unfounded or excessive. Categories are the exception, not the default.

In the UK the architecture is the same and the ICO spells out the contract requirements in plain bullets, currently flagged as under review following the Data (Use and Access) Act: the contract must say the processor will not engage a sub-processor without prior authorisation, will tell you of intended changes under a general authorisation and give you a chance to object, will impose equivalent obligations downstream, and remains liable to you for the sub-processor's compliance. On transfers, the ICO guide to international transfers opens its own checklist with the same instruction: map out the contracts and flows of personal information between you and the organisations outside the UK. The UK-specific framing is covered further in our UK GDPR and ICO compliance guide for AI receptionists.

Finally, note what the EDPB said about how changes are communicated. Guidelines 07/2020 paragraph 110 is blunt: any proposed modification by a processor to data processing agreements included in standard terms "should be directly notified to and approved by the controller", bearing in mind the leeway the processor has over non-essential elements, and "the mere publication of these modifications on the processor's website is not compliant with Article 28". The same logic is what you want applied to the sub-processor list: a silently updated page is not notice.

Why does deleting the recording not complete an erasure request?

Because the recording is one copy out of five, and because erasure has a second half almost nobody performs.

Article 17 gives the data subject the right to obtain erasure without undue delay where one of the grounds it lists applies. Article 19 then requires the controller to "communicate any rectification or erasure of personal data or restriction of processing ... to each recipient to whom the personal data have been disclosed", unless that proves impossible or involves disproportionate effort, and to tell the data subject who those recipients were if asked. You cannot communicate an erasure to a recipient you cannot name. An unnamed sub-processor chain does not make Article 19 difficult so much as unperformable, and Article 19 excuses what is genuinely impossible rather than what was never asked. The way out is knowing the names before you sign, not after a request arrives.

Then there are the clocks. The recording expires on one schedule. The transcript on another. Any model inputs held for abuse monitoring on a third, set by a company you have no contract with. The summary in your practice system on a fourth, which is genuinely yours to set. The carrier call detail record on a fifth. Article 5(1)(e) requires personal data to be kept in identifiable form "no longer than is necessary", and Article 5(2) makes you responsible for demonstrating that. Five clocks nobody enumerated is not a retention policy. It is five retention policies belonging to five other companies, with your name on the accountability. The consent and retention side of recordings specifically is treated in our call recording consent and retention guide.

What should you ask a vendor, and in what order?

Five steps, one email each, no legal budget required. The order matters, because each answer constrains the next one and a vendor improvising will contradict themselves by step three.

None of this requires you to become a data protection specialist, and none of it is a substitute for one on a complex deployment. It requires you to treat a routing question as a routing question. The longer procurement version, with the security controls alongside the data path, is our vendor security assessment template, and the broader European framing is in the guide for European businesses and the voice agent GDPR compliance guide.

What does a good answer look like next to a bad one?

You are reading the reply, not the tone of the reply. A pleasant reply and a complete reply are different things. Judge the artefact.

The last row is the tell. A list that only exists after signature is a list that does not exist. There is no commercial secret in the name of a transcription supplier, and a vendor treating it as one is protecting an answer rather than a trade.

On our side of it: we will name every sub-processor in the path and the country each one processes in, in writing, before anything is signed. Contact data and call records are processed on EU-hosted infrastructure with no US-default routing, we sign a Data Processing Agreement per client and act as your processor, and retention is configured by you and written down rather than inherited from a supplier default. What we will not do is answer with one word, since that is precisely the answer this article argues you should refuse. The disclosure side of the call, including the EU AI Act Article 50 duty to tell a person they are speaking to an AI system, which applies from 2 August 2026, is covered in the EU AI Act voice agent checklist, and the number and caller ID layer is on our page about multi-country voice AI compliance. What we hold about you rather than about your callers is in the privacy policy, and the control environment is on the security page.

If it would be useful to run the trace on your own call flow rather than on a page, that is a working session and not a demo. Forty-five minutes: we take the policies your front desk already follows, draw the path a real call would take through them, and find the edge cases that break it. You keep the written data-path map and the question sheet at the end, whether or not anything else follows. Send us the flow and we will work from that. When something does follow, it is one workflow first, usually missed calls and after hours, roughly two weeks, before anything else moves.

This article is general information about evaluating a supplier, not legal advice. Verify the current rules for your own use case and jurisdiction.