Do you have to tell the caller they are speaking to a machine
Two different texts require it of you, and they do not ask for the same thing. The GDPR requires that the person knows their data is being processed, who is doing it and why: that is the information obligation of articles 13 and 14. The European regulation on artificial intelligence adds an obligation of its own, that of knowing one is addressing an automated system and not a person. That second text applies on a staggered timetable: have your counsel check it rather than relying on a date read somewhere.
In practice it runs to one sentence at pick-up. It says three things and not one more: on whose behalf the line is answering, that the answer is automated, and that the caller can ask for a person. The rest, the detailed purpose, the retention period, the rights, lives on an accessible page and gets mentioned in a word.
What is not enough: writing it into terms and conditions nobody opens, saying it at the end of the exchange when everything has already been collected, or relying on the voice sounding synthetic. A voice that passes for human makes the announcement more necessary, not less. And it is you that a failure to inform exposes, not the vendor who wrote the sentence for you.
What the pick-up sentence has to carry, in this order. Read it aloud: if it runs more than a few seconds, it is too long and the caller checks out before the end.
- 1 On whose behalf the line is answering. That is your business, not the vendor’s name.
- 2 That the answer is automated. Said plainly, without jargon and without apologising for it.
- 3 That a person remains reachable, and how to ask for one.
- 4 Where to find the detail: an information page, named in a word, not recited.
Recording, transcript, summary: three processes people confuse
This is the point almost everyone muddles, suppliers included. An automated phone reception can produce three very different things from the same call, and they carry neither the same value nor the same risk. The recording keeps the voice. The transcript keeps the text of the exchange. The summary keeps what the system retained, which is to say an interpretation.
None of the three is compulsory. That is worth knowing, because plenty of installations record by default without anyone having decided it was necessary, and a processing operation you could not justify is one better not carried out. The question to ask about each is the same: what is it for once the appointment has been booked?
The summary deserves particular attention, because it is the only one of the three that produces data nobody dictated. A system that notes « unhappy customer » or « seems in a hurry » is writing an assessment, and an assessment can be corrected, disputed and deleted like anything else. Look at what yours actually writes, on real calls, before deciding to keep it.
| What is produced | What it contains | Compulsory | What to plan for |
|---|---|---|---|
| Recording | The caller’s voice, as it was | No | The hardest of the three to justify, and the shortest retention |
| Transcript | The text of the exchange, word for word | No | Same regime as the recording, but easier to purge and to correct |
| Summary | What the system retained, so an interpretation | No | Read it back on real calls: it can write an assessment nobody dictated |
A process you could not say the purpose of once the appointment is booked is one to switch off, not one to document.
Where your caller’s voice actually goes
This is the most useful question on the page, and the one the trade answers worst. « Data hosted in Europe » describes where the files sleep, not the journey they make during the call. An automated reception moves the voice, then the text, through several successive providers, in a few hundred milliseconds, and each of them is a processor within the meaning of article 28.
We are well placed to say so, because we got it wrong ourselves. Our home page claimed for months, in six languages, that the data never left the continent. The servers are indeed in the Union, but the audio of every call crosses several providers without a European region having been pinned in the configuration. The sentence was pulled on 26 August and the privacy policy now names each of those parties.
What you should be able to get from a supplier runs to a list: who is involved in the chain, what each of them sees, where they process it, and under what contractual framework when the processing leaves the Union. A supplier who cannot name their own chain has probably not mapped it, and you will not be able to fill in your record of processing with their answers.
1
Telecoms carrier
Routes the call. Sees the number and the audio.
2
Speech recognition
Receives the audio, returns text.
3
Language model
Receives the text, decides the answer.
4
Speech synthesis
Receives the text, returns audio.
| The question | The expected answer | What a bad answer tells you |
|---|---|---|
| Who is involved in a call? | A named list, provider by provider | « Our partners »: the chain has not been mapped |
| What does each of them see? | Audio for some, text for others | Silence, or an answer that muddles the two |
| Where is it processed? | A region, not a country of incorporation | « In Europe » without saying for which part |
| Under what framework outside the Union? | The standard contractual clauses, named as such | « We are compliant »: that is not a framework, it is an assertion |
How long to keep a call, and who can read it back
The GDPR sets no duration. It requires the duration to be determined, justified by the purpose, and respected. That sounds more comfortable than a fixed figure, and it is actually more demanding: you have to have decided, to have written the decision down, and to have a mechanism that applies it on its own. A duration nobody enforces is not a duration, it is an intention.
The right method is to treat the three products of the call separately rather than giving them a common duration. The audio is the one that justifies itself for the shortest time. The transcript holds as long as it can be useful to check what was said. The appointment and whatever feeds the customer record follow the life of the relationship, not the life of the call.
That leaves the question of access, which is separate and often forgotten. Who, in your team, can listen back to a call or read a transcript? The honest answer is rarely « everybody », and yet that is often what the delivered configuration allows. Look at who has the right before an access request forces you to look at it in a hurry.
| What you keep | The question that sets the duration | What has to happen at the end |
|---|---|---|
| The audio | What is it for once the appointment is booked and checked? | Automatic deletion, with no human gesture |
| The transcript | How long can it be useful to check what was said? | Deletion, or anonymisation if the content still serves to improve the answers |
| The appointment and the record | They follow the customer relationship, not the call | The life of the customer file, decided elsewhere and documented |
A duration no mechanism enforces is not a duration. Ask to see the deletion run, not the checkbox that promises it.
Health, regulated professions, minors: where the step is higher
Three situations change the nature of the problem rather than its degree. They are not settled by tightening retention periods, they are settled by deciding what the automated reception is allowed to do, and often by deciding that it does almost nothing.
What these three cases have in common is that sensitive or protected data can arrive without being asked for. Nobody asks a caller about their health; they say it themselves while explaining why they want an appointment. It is the reason for the call, not a form, that brings sensitive data into the system.
The practical consequence is the same in all three: the scope of what the reception records has to be decided in advance, kept narrow, and checked on real calls. A reception that books a slot without recording the reason processes far less sensitive data than one that summarises everything it heard.
Three cases where the general rule is not enough, and what they change in practice.
- Health: the reason for a medical appointment is health data, even said spontaneously and even approximately. The sensitive-data regime applies, and the question becomes not collecting it rather than keeping it well.
- Regulated professions: at a solicitor’s, a notary’s or an accountant’s, professional secrecy sits on top of the GDPR and does not answer to the same rules. It is not negotiated with a supplier, it is translated into the scope of what the reception is allowed to hear and note.
- Minors: nothing tells the system it is talking to a minor, and it has no reliable way of knowing. That is one more reason for the collection scope to be narrow, rather than relying on a detection that does not exist.
What you have to write, and nobody will fill in for you
The controller is you, not the software vendor. That often comes as a surprise, and it does not move by contract: the supplier is a processor, it acts on your instructions, and it is your record of processing that has to describe the operation. A serious vendor gives you the material to fill it in; none of them fills it in for you.
The good news is that the material runs to a page for a phone reception, and that it is made almost entirely of decisions you would have had to take anyway: what the reception records, for how long, who has access, and what happens when somebody asks to see or to erase.
That last point is the one people prepare worst. An access or erasure request arrives rarely, and when it does it comes with a deadline. Knowing in advance who receives it, where you go and look, and in how many moves you erase, turns an incident into a formality.
Six lines to write once, to review when the configuration changes. They are enough for a phone reception.
- 1 The purpose: answering incoming calls, giving information, booking appointments. Written in one sentence, not a paragraph.
- 2 The legal basis, and why you chose it rather than another.
- 3 The categories of data: identity, contact details, reason for the call, content of the exchange. Name what you actually collect, not what the software can do.
- 4 The recipients: your team, and every processor in the chain, named.
- 5 The durations, decided separately for the audio, the transcript and the file.
- 6 The route of an access or erasure request: who receives it, where you look, in how many moves you erase.
| You | The supplier | |
|---|---|---|
| Role | Controller | Processor |
| Decides purposes and durations | Yes | No, it applies them |
| Keeps the record of processing | Yes, and it cannot be delegated | Keeps its own, not yours |
| Answers an access request | Yes | Must give you the technical means |
| Frames its own sub-processors | No | Yes, and must be able to name them |
Common questions
- Do you have to obtain the caller’s consent?
- Not systematically. Consent is one of the possible legal bases, and rarely the most suitable for a phone reception: answering someone who rang you sits more naturally under performance of a relationship or legitimate interests. Consent becomes the route to examine as soon as sensitive data is involved. That is a question to settle with your counsel, not with your supplier.
- What do you say to a caller who asks not to be recorded?
- The right answer is to be able not to record them, and to know how to do it during the call. Check before signing that the switch exists, that it covers the transcript too and not just the audio, and that whoever is on the line knows how to trigger it.
- Can an automated reception handle health requests?
- It can, provided that is decided and framed rather than endured. The reason for a medical appointment is health data even when said spontaneously. The safest setting is to book the slot without recording the reason: the service is the same, the sensitive data never comes in.
- Can the supplier call itself the controller in our place?
- No, and a clause claiming so would not change the reality of the role. You decide the purposes and the durations, so you are the controller; the supplier acts on your instructions, so it is the processor. What it owes you is a compliant contract, the list of its own sub-processors, and the technical means to answer an access request.
