A voicebot creates three data records for every call: an entry in the call history, a transcript, and a summary. A recording of the call is only added if the operator enables it for the respective channel. The company decides for itself how long all of this is retained, roles govern who can view it, and every change to the settings is logged. This article walks through what is stored during a call, for how long, for whom, and with what verification records.

What is stored per call

Operations require the first three data records: the team sees what the caller wanted and what the voicebot captured, such as a customer number or a meter reading. Analytics use this data to identify topics and knowledge gaps. The recording is an optional add-on, and it represents the most sensitive file of the call because it contains the voice.

Recording is a separate decision

Anyone recording telephone calls requires a legal basis and must inform callers in advance. In Germany, recording a telephone call without consent is also a criminal offense (Section 201 of the German Criminal Code - StGB). A voicebot should therefore allow recordings to be toggled per channel, with "off" as the default state.

Having a switch per channel serves a practical purpose. A company often operates multiple phone numbers for different purposes, such as customer service and an incident hotline. For one, a recording might make sense—for instance, for quality assurance—while for the other, the transcript is sufficient. The notice to callers must then be included in that channel's greeting, alongside the notice that an AI is speaking.

How long data is retained

The GDPR requires that data is stored no longer than necessary for the intended purpose. The company determines this retention period. The easiest voicebot setup to audit is one where transcripts and recordings follow the same retention period as chat messages. In that case, a single rule applies across all channels, and the data deletion concept remains clear and manageable.

For recordings, a longer retention period may be necessary—for example, if they serve as proof or evidence. This must be clarified before launch, with the purpose and retention period documented in the record of processing activities.

Who accesses call data

In the user interface, roles govern who can view the call history, transcripts, and recordings. Phone numbers are displayed masked so that the call list does not expose full phone numbers. For troubleshooting, searching by number, channel, or content is sufficient.

Via the API, other systems retrieve the data, such as a CRM or a data warehouse. Access must be restricted to a server, using a key that is never exposed in a website or app. Once the data resides in the target system, that system's retention periods and permissions apply. This, too, belongs in the data deletion concept.

For voice output, almost every voicebot works with a voice provider. What matters is what this provider receives. If they only receive the text to be spoken, the caller's voice never leaves the platform at this point. Learn more in our article on GDPR-compliant AI phone assistants.

Which logs verify changes

Two types of logs are often confused. The transcript documents what was said during a conversation. The audit log documents what was configured for the channel: voice, greeting, recording, and the PBX integration. For a data protection audit, the latter is often more critical. It proves when recording was turned on or off and since when the disclosure has been included in the greeting.

This also includes the approval of new service providers. If an additional voice provider is added, it should be documented who approved it and when. For an overview of all the documentation an operator should maintain, see the article on the EU AI Act in chatbot operations.

How Mercury Voice implements this

Mercury Voice creates an entry in the call history for every call, containing channel, timestamp, duration, and a brief summary, with phone numbers masked. In addition, it provides a transcript with speaker roles and timestamps, as well as an automated summary. Both can be retrieved via API, and the UI view is currently in development. Recordings can be toggled per channel and are disabled by default. When enabled, the team can play them back directly within the interface.

Transcripts and recordings adhere to the retention period configured in the project, just like chat messages. Audit-compliant archiving is available as an option. Platform roles govern access permissions, and the API is accessible only server-side via key. Connection setup and every configuration change to a channel are logged under the Activities tab; the approval of a voice provider is saved with the user name and timestamp. The voice provider receives only the text to be spoken. Find out more about the channel on the Mercury Voice page; the rest of the data flow is detailed in the article Where customer data flows in an AI chatbot.

Four settings before the first call

1. Define recording per channel. Default state: off. Enable only with a defined purpose, legal basis, and retention period.

2. Write the greeting. The notice that an AI is speaking belongs right at the beginning, as does the notice regarding call recording if enabled.

3. Configure the retention period. One retention period for chat and phone, plus a clear rule for data transferred to other systems via API.

4. Review roles and permissions. Who can view the call history, who can listen to recordings, and who holds an API key?

Planning a voicebot and want to align data storage and access with your data protection officer in advance? Talk to us.