Speech-translation pilots should delete the audio by default

My default proposal for a multilingual AI startup would be: evaluate the pilot, document the results, then delete the raw customer recordings. Keep privacy-preserving metrics for accuracy, dialect coverage, error patterns, and latency, but resist turning a short experiment into a permanent archive of identifiable voices and conversations.

There is a real engineering tension here. More audio can reveal accent and dialect failures, background conditions, and odd latency cases, yet it also captures incidental speakers and sensitive context. I would want consent to distinguish raw audio, transcripts, extracted features or embeddings, human review, and model-training use—not bury all of that under “service improvement.” Customers should get a clear deletion deadline, not vague retention language. Is this too conservative for useful iteration? Developers, privacy-minded users, and founders: disagree or share how your teams handle pilot data.

Strong default. I would add that embeddings are not automatically harmless leftovers; depending on how they are produced and used, they may still be personal data. “We deleted the audio” should not become shorthand for “we deleted everything linkable to the speaker.”

The product objection is that some customers will explicitly want improvement from their samples. That can be supported without making it the default: separate opt-in, stated purpose, stated retention, and a way to withdraw. Consent should not be a single giant checkbox.

The metrics distinction is useful, but “privacy-preserving” needs documentation rather than branding. Pseudonymized records can remain linkable. I would record what was retained, how linkage was assessed, and which groups or conditions the metrics actually cover.

A deadline also creates an operational forcing function. If a team cannot explain why a recording still exists by that date, it probably should not exist. The counterargument is that small startups may lack the tooling for fine-grained deletion, which is precisely why the default should be simple.

From a threat-model view, raw audio is a high-value liability: identity, content, and possible voice-impersonation material in one object. Access controls reduce exposure; they do not remove the archive. Deletion is the cleaner control when the data is no longer needed.

I disagree with making deletion universal after evaluation. Rare dialect and noisy-environment failures may only become visible when revisiting examples later. I would support a short default window plus a genuinely separate opt-in for longer research retention, with narrower access and a real deletion mechanism.

The consent categories matter because users understand “translate this call” very differently from “train future models on my voice.” A good interface could ask those questions at the moment they matter, instead of presenting a paragraph that nobody can meaningfully parse.

The edge cases are where this breaks: support exports, evaluator copies, cached transcripts, analyst downloads, and backups. A deletion promise needs an inventory and an owner. Otherwise the deadline is just a sentence in the privacy notice.

Enterprise buyers will ask for the retention schedule, deletion evidence, subprocessors, and whether embeddings survive deletion. “We use it to improve the service” will not answer those questions. Clear boundaries can be a procurement advantage, not merely a privacy cost.

For a small team, I would store aggregate error counts and carefully sampled, consented test cases—not every customer conversation. Better instrumentation is cheaper than discovering later that the database became an accidental voice archive.

If the recording is no longer needed, delete it. Apparently this remains a controversial feature request.