You've built a voice agent that works. Then your enterprise customer's security team asks: "Is every model provider in your stack zero data retention?"
Suddenly, you're auditing every provider in your stack, one at a time. Some require a form and human approval, with no SLA for how long it takes. Others put ZDR behind a paid tier, a dashboard setting, or a toggle you have to find and enable. Some offer it by default. Every provider handles it differently, and you repeat the entire process whenever you want to try a new model.
This matters because your customers need to answer the same question for their customers. In healthcare, insurance, and other regulated industries, an unclear answer can slow down a security review or block the product from shipping entirely.
Strip away the compliance language and it's simple:
- Don't train models on my conversation.
- Don't let someone at a company I've never heard of read the transcript.
- Don't keep it on a server after you're done with it.
- Don't send it to another company I didn't agree to.
Basically, users don't want their data kept to do anything they didn't ask a provider to do. When customers ask "Are you ZDR?" they're asking if that's true.
How we think about your data#
We use your data only to deliver the service you asked us to run. Not to train models, not to improve our own systems, not for a purpose you didn't choose.
Where retention is core to the feature (like Observability for debugging your agents, or Egress for recording your sessions) we follow the same ethos:
- It exists only to run the feature you turned on.
- It's never used to train models, improve our systems, build datasets, or share data without your direction.
- It's limited in time, and you can delete it whenever you want.
We want to own this so you can focus on building.
What we mean by "zero data retention"#
ZDR is not a certification or a standard test. It means your data isn't retained after we're done with it, isn't trained on, and isn't used for anything you didn't ask for.
Four things can't happen: no retention, no logging, no training, no aggregation. Your data is used to serve your request and nothing else.
This has to hold across our entire platform, and every service we offer meets the same standard.
ZDR is the default for every model in LiveKit Inference#
Every LLM, STT, and TTS model available through inference.LLM, inference.STT, and inference.TTS is configured for zero data retention and no training on your data. ZDR applies to every LiveKit plan. There's no flag to set, plan to upgrade, or dashboard to configure. If you're using LiveKit Inference, you're already covered.
1from livekit.agents import AgentSession, inference23session = AgentSession(4stt=inference.STT(model="deepgram/flux-general", language="en"),5llm=inference.LLM(model="google/gemma-4-31b-it"),6tts=inference.TTS(model="inworld/inworld-tts-2", voice="Ashley"),7)
Nothing in this snippet asks for ZDR. The privacy posture isn't a parameter you pass, it's a property of any model ID you pick.
How we enforce it#
ZDR works differently across providers. Depending on the provider, it may be established through a contract, an approved account configuration, a workspace setting, or a parameter included with every request.
We handle all of this for you. We secure the required contractual commitments and approvals, configure ZDR at the account or workspace level, and enforce any required parameters on every request.
We require every third-party provider to use your data only to process your request: no retention, no logging, no training, no improvement. Providers that can't meet that standard aren't available through LiveKit.
Verified across the full stack#
ZDR has to hold everywhere a request touches: entry point, model provider, infrastructure.
Before any model ships, we confirm it meets our ZDR standard. Existing integrations are verified on an ongoing basis to stay correctly configured in production.
This is why ZDR persists even as the platform grows. Every new provider and model clears the same bar before it ships. A model that can't meet the standard doesn't get added, so you can adopt whatever's next without reopening a privacy review.
Where retention is a feature, the same principles apply#
Three features on LiveKit require storing data because that's the whole point of the feature. We use it only for what you asked: no training, no sharing, no other use. You control the retention.
- Agent observability stores transcripts and audio for 30 days so you can debug your agents. That's it. Deleted automatically after 30 days.
- Egress records your sessions to your own cloud storage. You own it, you control how long it lives. LiveKit's interim files are deleted immediately after upload.
- Voice cloning stores your audio sample so the clone works with new providers as we add them. It's deleted 12 months after last use, or immediately if you delete the clone.
Ready for production#
Production readiness includes knowing your data is handled the same way everywhere. With LiveKit, you get that across the entire platform without needing to verify each component.
Read the full breakdown in our security overview, or jump into the Voice AI quickstart and start building.