What to Consider About Personal Data Before Building a Voice Assistant

What a voice assistant actually produces

When a conversational flow runs it leaves behind several distinct kinds of data, and they are not equivalent. Until you separate them, you cannot judge how much of it you actually need.

• The raw audio — the sound of what the person said. Audio is personal data to the extent it can identify the speaker.
• The transcript — the same speech as text. It may contain names, addresses, health or financial details.
• Collected fields — what the flow deliberately asks for: name, phone, date, amount.
• Uploaded documents — an ID, invoice or report. The image itself and the fields extracted from it are separate data.
• Technical records — IP address, browser details, session time.

How data protection law frames this

In the EU and UK this sits under the GDPR, which defines personal data as information relating to an identified or identifiable natural person. In Türkiye the equivalent framework is Law No. 6698 (KVKK), which uses a comparable definition. A recording or a transcript can fall within either.

Two obligations come up in practice almost every time: you need a lawful basis for processing the data, and you need to inform people about that processing. Informing people is a separate duty — it does not disappear because you also collected consent.

Some categories, such as health and biometric data, are treated as special and carry stricter conditions. Whether a voice recording counts as biometric data depends on what you do with it: using a voiceprint to identify someone is different from simply transcribing what they said.

Questions to answer before you build

The following are design questions rather than legal ones, but their answers directly shape your legal position. Answering them before you build saves you from going back to clean up data later.

• Do you need to keep the raw audio, or is the transcript enough? If the transcript is enough, do not store the audio at all.
• How long will you keep transcripts? Keeping them indefinitely is not a decision — it is the absence of one.
• Does the flow ask for anything you do not actually need? Data you never collect is data you never have to protect.
• If the extracted fields are enough, do you need to retain the document image?
• Who inside your organisation will be able to see this data?
• At what point in the flow does the person learn that the conversation is being recorded?

The part that flow design solves

A large share of the data protection work is settled by the flow itself rather than by a policy document. Data you never collect is data you never have to secure, store or delete.

A few approaches that work in practice: make the first step an informing message; review every field against "do I genuinely need this"; extract only the fields you need from documents; and leave people the option to type instead of speak.

In agenola, whoever builds the flow decides which step is asked, which document is requested and what gets recorded. Collected fields and transcripts stay in your workspace and are visible from your panel. That does not make the tool compliant on your behalf — it means the decisions are yours.

Three common mistakes

• Recording everything and planning to filter later. Data creates responsibility from the moment it is collected.
• Putting the notice at the end of the flow. Someone is not informed after they have already handed over the data.
• Relying on a tool being "compliant". Compliance is a property of the organisation processing the data and its purpose, not of the software.