The 24-hour rule, why we delete your audio that fast
Encrypted at rest is true and not enough. The shortest retention you can ship is the strongest privacy posture you can offer. Here is the case for 24 hours.
The phrase "encrypted at rest" is everywhere in vendor marketing. It is true. It is necessary. It is also not the same as "we do not have your data". A file that is encrypted at rest is still a file, sitting in a database, in a backup, in a snapshot, in a region, attached to a customer record, accessible to engineers with the right roles, recoverable in the event of a legal request, and, eventually, caught up in whatever incident the future holds.
The strongest privacy posture is not "your data is encrypted forever". It is "we do not keep your data". The shortest retention period you can ship is the simplest answer to the broadest set of privacy questions. EnClair's answer is 24 hours, for both audio and summaries. This is the article that explains why.
The shortest retention you can ship is the strongest privacy posture you can offer. "Encrypted at rest" is true and necessary; "we do not have it" is stronger. A 24-hour retention window on both audio and summaries removes most of the questions that come up in procurement.
What "indefinite retention" actually means
Most meeting AI products retain audio and transcripts until the user manually deletes them. The marketing language for this is usually some combination of:
- "Your data is yours, you control it."
- "Encrypted at rest with AES-256."
- "Deletable on request."
All of those statements are true. They are also a description of indefinite retention with a deletion endpoint. The default state is "stored". The customer-facing burden is to remember to delete. Most customers do not.
A practical example: a thirty-person team that uses a meeting AI for two years and never explicitly deletes anything has, by the end of year two, somewhere around 1,500 to 5,000 hours of audio recordings, plus the transcripts and summaries, plus the audit logs of who accessed what, plus the backups, plus the snapshots, plus the indexed search artifacts. All of that exists. All of that is potentially in scope for a discovery request, a security incident, a regulator inquiry, or a future change in the vendor's ownership and policies.
"Encrypted at rest" does not change any of that. It changes only the answer to "what happens if someone steals the disk".
Why 24 hours
The summarization workflow looks like this:
T+0 Upload audio
T+0–10 Models process audio in parallel
T+10 Summary files available for download
T+24h Audio deleted, summary deleted, all artifacts gone
Twenty-four hours is enough time for the user to:
- Receive the summary files from the parallel model runs.
- Review them, compare them, pick the one that fits the article or the brief.
- Download the summary they want to keep.
- Run additional summary configurations (different summary type, different length) on the same audio if the first pass was not what they needed.
It is not enough time to forget. Twenty-four hours is short enough that a workflow either uses the summary today or accepts that the audio is gone. There is no slow accumulation. The vendor does not become a long-term archive. The team's recordings of confidential conversations do not sit in a third-party data center for years.
For comparison:
| Retention model | Default behavior | Burden on customer |
|---|---|---|
| Indefinite, deletion on request | Stored until manually deleted | Must remember and execute deletion |
| 30 / 60 / 90 days, automated | Stored for the window, then auto-deleted | Must download what they want to keep within the window |
| 24 hours, automated | Stored for processing window only, then deleted | Must download today |
| Zero retention (true ephemeral) | Not feasible, model needs the audio at least until processing completes | N/A |
24 hours is the shortest practical window where the workflow still functions. Anything shorter and the summary is gone before the user comes back to read it. Anything longer and the vendor is hoarding.
What we delete, exactly
The 24-hour rule applies to:
- Source audio files. The recordings the customer uploaded.
- Generated summary files. The outputs of the model runs, in all their executed variants.
- Intermediate artifacts. Any temporary files used during processing, chunked audio, transcript fragments, model inputs and outputs cached for performance.
- Backup copies and snapshots. The deletion is not just a soft-delete in the primary database; backups roll forward past the deletion window.
What we keep beyond 24 hours:
- Account and team metadata. Who is on the team, billing records, login activity. Standard SaaS account data, with its own retention governed by the GDPR-mandated rules and the customer's own deletion requests.
- Aggregated, non-identifying usage metrics. How many summaries the platform produced last month, in aggregate, for capacity planning. No customer-level or content-level data.
What we do not do, ever
Three things we do not do, at any retention window, on any plan, on any tier:
- Train models on user inputs or outputs. The audio and summaries do not enter any training corpus, ours or anyone else's.
- Sell or share content with third parties for marketing or advertising. No.
- Reuse audio across customers. Each session is isolated. Nothing flows sideways.
The 24-hour rule is part of a larger commitment that the vendor's defaults match the privacy posture a buyer would want. The retention is the most visible part. The non-training and the non-sharing are the invisible parts.
What this means for the buyer
The procurement reviewer asks: "How long do you keep our audio?" The vendors who answer "until you delete" are inviting a longer conversation about deletion automation, lifecycle policies, and audit logs. The vendors who answer "24 hours, then it is gone, on every plan, by default" have already given the buyer the answer the buyer wants to write into the records of processing.
For most teams, that is the answer that ends the procurement conversation in one Friday afternoon.
A note for the security-conscious
If 24 hours is too long for your use case, the answer is not a different retention setting from the same vendor. It is self-hosting, or a contractual zero-retention arrangement with explicit per-tenant ephemerality. EnClair does not currently offer the zero-retention configuration; the self-hosted vs SaaS article covers what the alternative looks like.
For most teams, 24 hours is enough. For the teams where it is not, the right answer is honestly disclosed. We would rather lose those deals than misrepresent the architecture.
What to take from this
The privacy posture of a meeting AI is not in its marketing copy. It is in the default retention period. A vendor that defaults to 24 hours, on every plan, with no manual deletion required, is a vendor whose architecture matches the privacy claim. The full posture is on the security page. The procurement template is on the GDPR-compliant article.
Tags
- gdpr
- Industry
- Workflow