Your voice, their training set

Listen instead · voiced on a MacBook Air, offline

In 2005, a voice actor named Susan Bennett spent four hours a day, every weekday of July, alone in a home recording booth reading sentences that meant nothing. Not scripts. Phonetically balanced nonsense, engineered so that every sound combination in American English appeared often enough to be cut apart and reassembled later. She was paid for the session, she signed what was put in front of her, and she went home. Six years later she turned on the news and heard her own voice coming out of a phone, introduced to the world as Siri.

Bennett had not been told, because nobody involved was legally required to tell her. She had recorded a database. What a database gets used for afterwards is a question the recording session does not answer, and in 2005 there was no reason for anyone in that booth to ask it.

The clause underneath the upload button

Twenty years on, the same question is asked of ordinary people thousands of times a day, and it is still not really asked out loud. It lives instead in a subordinate clause. You will find it in almost every cloud voice product, and it usually reads something like this: by submitting content, you grant us a worldwide, non-exclusive, royalty-free licence to use, reproduce and create derivative works from that content for the purpose of operating and improving our services.

Read plainly, that is not a storage policy. It is a licence. Nothing in it is hidden or unusual, and most of it exists for boring technical reasons: a service genuinely cannot stream your audio back to you without a licence to reproduce it. But the phrase doing the heavy lifting is the last one. Improving our services is not defined anywhere, and it is broad enough to include the one thing you probably had in mind when you hesitated over the button.

“Nobody uploads a recording of themselves intending to become a permanent contributor to someone’s model.”On consent that arrives in a subordinate clause

What improvement means technically

It is worth being precise here, because vagueness helps nobody. Your thirty-second sample is not usually dropped straight into a training run. It is too small to matter on its own. What tends to happen is more mundane and more durable.

The clip is stored. It is stored because the service needs it to regenerate your voice on demand, and because storing it is cheaper than asking you for it again. Alongside it goes a speaker embedding, a compact numerical fingerprint of what makes your voice yours, which is the artefact the model actually uses. Then the clip enters the general pool of material the company holds, and that pool is what gets sampled from when the next model is trained, when a quality regression needs investigating, when an evaluation set is assembled, or when a researcher needs examples of a particular accent.

None of these steps are sinister. Each one is a reasonable engineering decision taken in isolation. Their combined effect is that a recording you made once, for one purpose, becomes a small permanent fixture of an infrastructure you cannot see and cannot audit.

Deletion is a promise, not a property

Most services offer a delete button, and most of them honour it. But consider what deletion can actually reach. It can remove the file. It can usually remove the embedding. It cannot remove your voice from a model that has already been trained, because weights are not a filing cabinet and there is no row to strike out. It generally cannot reach backups, which are the entire point of backups. And it cannot reach a copy that has already gone to a subprocessor, which is why privacy policies list them.

So deletion is real, and it is also a promise about future behaviour rather than a fact about the present. It depends on the company continuing to exist, continuing to mean it, and not being acquired by somebody with a different view. Those are decent odds. They are not the same thing as a guarantee. Our own privacy policy is short for much the same reason: there is not a great deal to describe.

Voice cloning with no upload at all

Which brings us to the engineering we actually care about here. Every risk described above is downstream of a single event, and that event is the upload. Remove it and the chain does not need managing, because it does not form.

So Usovo does not have one. When you clone a voice, the recording is captured by your microphone, decoded in the page, re-encoded to plain PCM, and handed to a model process running on your own machine, addressed over your own loopback interface. The reference clip and the resulting voice are written to your disk, inside your user library, as ordinary files you can open, copy or throw away. There is no bucket, no embedding on a server, no subprocessor list, and no delete endpoint, because deleting the folder is the delete endpoint.

The honest framing is this. A cloud service asks you to trust its intentions, and most of them deserve that trust more often than the internet gives them credit for. Local processing asks you to trust its architecture instead, which is a duller thing to promise and a much harder thing to quietly change. Susan Bennett read nonsense sentences into a microphone in a spare room and could not have known where they would end up. The point of doing this on your own hardware is that the question never has to be interesting again.

· · ·