A voicebot, GDPR and the AI Act: where the recording of a patient call actually sits

When a medical practice starts considering a voice assistant to answer the phone, the conversation usually revolves around whether the voice sounds natural and whether the system understands difficult surnames. Those are fair questions. They are not, however, the questions that decide whether the deployment survives its first inspection or its first patient complaint.

Those questions sound different. Where is the recording of the patient call physically kept. On what legal basis do you process it. How long do you hold it and who can listen to it. Who is the processor and who is the controller. And does the patient know they were talking to a machine.

We have not seen those answers in a single offer. So I have gathered in one place what needs settling before such a system ever rings.

A caveat up front, because it matters: we are not a law firm and this is not legal advice. We build systems and we know which technical decisions determine whether these questions can be answered at all. For an actual deployment you will still need a data protection officer or a law firm, and the point of this text is to make that conversation shorter.

The first thing that tends to surprise people: the mere fact that somebody is booking with a particular doctor is already information about their health.

Nobody has to mention symptoms. It is enough that the patient asks for a slot with a psychiatrist, an oncologist or an addiction treatment clinic. The name of the specialty combined with a name and surname says something about that person they would not want to see in someone else's hands.

We have written about this in the context of what GDPR requires from a clinic website, and on the phone the principle is exactly the same, only the channel is different.

GDPR calls this a special category of data and treats it differently from ordinary contact details. The rule is a prohibition on processing, and processing is allowed only where one of the exceptions listed in Article 9 applies. Healthcare providers usually rely here on the ground concerning the provision of health care, but that ground does not cover everything a clinic could conceivably do with a patient's voice.

The practical consequence: booking an appointment and recording the call are two different operations and each needs its own justification. The fact that you may book a patient does not automatically mean you may keep a recording of that call for a year in case of a complaint.

Do you need to record at all. This is the first and most frequently skipped question. To work, a voice assistant needs to turn sound into text. It does not need permanent storage of an audio file to do that. You can build a flow in which the recording lives for a few dozen seconds in memory and what remains is a dry note: who called, about what, which slot was agreed. If the recording is of no use to you, the cheapest compliance is not having it.

How long you keep it, if you do keep it. Retention has to be a number written into the system configuration, not a declaration in a policy. The difference shows up at the first erasure request. „We delete after thirty days" is an answer only if somebody can point to where that thirty is set and what happens to the backups.

Who has access. A recording of a patient call should not be available to everyone who has access to the assistant's admin panel. This is the same problem you know from the practice management system, only in a new place and usually unsolved, because the supplier's panel has one role: administrator.

What happens to the transcript. The text of the call is still the same data. It happens that a clinic handles recordings properly and completely forgets about transcripts, which end up in logs, in a quality analytics tool and in the head receptionist's mailbox.

This is the most common structural mistake we see.

The clinic signs a processing agreement with the company that delivered the assistant and considers the matter closed. Meanwhile a typical deployment involves at least two different entities in the processing: the telephony provider the call passes through, and the language model provider that turns speech into text and formulates the replies. Sometimes it is three, because speech recognition and response generation are done by different companies.

Each of them processes patient data. Each needs a basis and each has to appear in the record of processing activities. If the assistant's supplier uses them as sub-processors, you need consent to that further processing and a list of sub-processors that is kept current rather than written once.

On top of that comes a question worth asking outright and in writing: is data from the calls used to train the model. The answer „no" has to be in the contract, not in an email from a salesperson. Large model providers have separate service modes for this and they do not switch themselves on.

A language model does not have to sit in your country, or even in the European Union. Very often it does not.

That is not automatically a problem, because transfers outside the European Economic Area are permissible where the conditions in Chapter V of GDPR are met. It is very much a problem if nobody checked and documented it, and with health data it is one of the first questions that will come up in an inspection.

The question for the supplier is specific: in which region is the audio processed, in which region is the text processed, and on what basis does any transfer outside the EEA take place. If the answer is „in the cloud", that is not an answer.

For a voice assistant in a medical practice, a data protection impact assessment is in practice unavoidable. Three things come together at once: special category data, new technology, and scale, because we are talking about every patient who calls the clinic.

We treat a DPIA not as a formality to be ticked off after the rollout, but as a document that is produced before choosing a supplier. The reason is practical: the questions in a DPIA are exactly the questions a supplier either can or cannot answer. Surprisingly few offers pass that test.

This is a provision that came into force recently and many suppliers have not yet accounted for it.

The EU regulation on artificial intelligence, Regulation (EU) 2024/1689, imposes in Article 50 a transparency obligation on systems intended to interact directly with people. A voice assistant answering the phone is precisely such a system. The obligation sits with the provider of the system and means the system must be designed so that the person knows they are dealing with artificial intelligence. The information has to reach the person at the start of the interaction, not in terms and conditions on a website.

This obligation has applied since 2 August 2026, meaning it is already in force. Exceptions were provided for, including where it is obvious to a reasonably well-informed person and in situations connected with law enforcement, but none of them covers bookings at a clinic.

In practice it comes down to one sentence at the start of the call. It is worth noting, though, that the same sentence incidentally solves a problem you would have had anyway: patients work out that they are talking to a machine, and those who were let into it without warning feel deceived and write about it in reviews.

A separate boundary, which I described at greater length in the piece on what a voice assistant actually does, but which returns here in its regulatory form.

An assistant that books appointments, informs about slots and transfers to a human is an organisational tool. An assistant that gathers symptoms in order to assess urgency or route the patient to the right specialist is doing something qualitatively different and enters an area with requirements far heavier than anything described above.

The point is not that this cannot be built. The point is that it is a different project, with different documentation, a different budget and a different timeline. A clinic that orders an improvement to its front desk and receives something that quietly assesses health has a problem it will find out about last.

Honestly: a compliant voice assistant does not make a clinic compliant.

If you fall under NIS2, the obligations around risk management, backups and incident reporting do not disappear because a system now answers the phone. What you do gain is one more supplier in the register and one more channel carrying patient data, so this is a new entry in the risk analysis rather than the closing of one.

The same goes for GDPR. The record of processing activities, the information notice and the retention policy need updating, not ticking off.

If you take one thing from this text, let it be this list. Ask these questions in writing before you sign anything.

A supplier who answers those eight questions without evasion is probably doing this seriously. A supplier who opens with „it is all GDPR compliant" has not thought about it yet.

We build voice assistants and we treat these questions as part of the specification, not as a legal annex at the end. The same person who answers them here later writes the integration, so it does not stop at a declaration in an offer. If you would like to walk this list through for your own clinic, write to me. More about how we approach EU regulation in IT projects and what we do for healthcare is on separate pages.