Back to Blog
Compliance & Security

GDPR and voice AI: plan data rights across the call lifecycle

Map caller data, define controller and processor responsibilities, and test access, correction and deletion workflows for voice assistants.

Burki
(Updated: September 25, 2026)
3 min read

A caller's information can appear in audio, transcripts, extracted fields, tool requests and customer-system records. Reviewing only recording storage misses much of a voice assistant's data lifecycle. Start with a map of those copies and the reason each exists.

Assign responsibility for each processing step

The European Data Protection Board's guide distinguishes a controller, which determines purposes and means, from a processor acting on instructions. Your contractual role depends on the actual processing relationship. Buying a European telephone number or supplying provider keys does not settle that question.

For each system, record the operator, purpose, location, recipient and retention decision. Include model providers, media handling, logs and business integrations. Document which contract governs each relationship and who handles a caller's request.

Design requests around identifiable records

Use a fictional test caller to work through a data-rights request from receipt to completion:

  1. Establish the requester's identity through your approved process without collecting unnecessary new data.
  2. Locate relevant calls and downstream records using the permitted identifiers.
  3. Distinguish what can be corrected, exported, restricted or erased in each system.
  4. Record any applicable exception and the responsible reviewer.
  5. Confirm the outcome from the relevant systems rather than from an assistant's spoken assurance.

The EDPB describes individual rights and their limits. Not every right applies identically to every processing situation. A UI button labeled “delete” is not a legal determination and may not cover third-party records or backups.

Decide what the assistant should collect

For an initial receptionist scenario, public business facts and a narrowly defined request may be enough. Avoid broad instructions to remember everything about callers. Decide what must be retained, what is optional, and what should never enter the model context.

Review caller notices, the applicable lawful basis, any special-category data, automated decision-making and international-transfer requirements with the responsible privacy team. These are scenario-specific decisions; a voice model choice is not a universal compliance setting.

Verify the selected Burki configuration

Burki uses application services, LiveKit media and selected model/tool providers. BYO credentials alter provider access and billing; they do not mean every part of the conversation stays in your infrastructure or region. Ask for the actual data path and available contractual terms before production use.

Test transcript access, recording access when enabled, organization isolation, retention and deletion with synthetic data. Keep any unverified requirement out of customer promises. Begin with the security review questions and the workspace's privacy information.

Ready to try Burki?

Create an assistant and check your available browser practice allowance.

Create your assistant

Trial eligibility and available practice are shown in your workspace.

Related Articles