Privacy Policy

Workflow Corporation is the controller of the personal data described here. We trade as Radio Workflow HQ, at 210 Emerson Pl, Suite 300, Davenport, IA 52801, USA, on +1 (563) 275-6409.

Write to [email protected]about anything on this page and mark it for the attention of the privacy team. That is a real inbox that a person reads, which is why it is the only address here: a dedicated privacy alias that nobody watches is worse than a shared one that somebody does. Support is staffed 24/7; the office keeps Monday to Friday, 8:00 AM to 6:00 PM CST.

We have not appointed a data protection officer, and we have no representative in the EU or the UK. That is stated plainly rather than glossed over with a title nobody holds — if you need one of those roles to exist before you can use a service, it does not exist here yet, and the address above is where to say so.

This policy covers the Voice Buddy website, console and API. Where you use Voice Buddy inside a workspace that someone else set up, that organisation decides what goes into it and we process it on their behalf.

Account and workspace

• Your name, email address and a hash of your password. If you sign in with Google or GitHub we store the tokens that identity provider issues instead, plus the profile fields they return — including an avatar image URL if there is one.
• When you were created, when you last signed in, and whether your email has been verified.
• The workspaces you belong to and your role in each, plus the email address of anyone you invite.

Content you put in

• Voice recordings. Every clip you upload to clone a voice, and the reference clip the engine conditions on. These are biometric data and are treated separately — see the Voice Cloning and Biometric Data Notice, which is the detailed document on this point.
• Scripts and text you submit, and any transcript, translation or script the service produces for you.
• Audio and video you upload to re-voice, transcribe, dub, edit or mix, including music beds and sound effects.
• Every finished render, together with the script that produced it, the voice and the settings used, and the seed if you pinned one.
• Stills and backgrounds for a video — the ones you upload, and the ones a model generates for you, stored together with the prompt that produced each and the finished video itself.
• Projects, chapters, mixes, multi-voice scripts and pronunciation dictionary entries.
• Voice agents, and the conversations held with them. What you write an agent to say and do — its instructions, its greeting, the voice and language it uses — and, for each conversation it holds, what was said on both sides, a summary of it, when it started, how long it ran and why it ended. Where the person on the other end is a member of the public rather than someone with an account here, that is their speech in our database, so the retention section treats it separately and the subprocessor list says where the audio goes.

Usage and technical data

• Metering records: characters and audio seconds consumed, per workspace and per user, so allowances and invoices can be computed.
• API request logs: method, path, status code, latency, characters, IP address, user agent, error code, and which API key was used.
• An audit log of consequential actions — who invited whom, who deleted a voice, who changed a plan — with the acting user and their IP address.

Billing

Card details never reach our servers. Your browser tokenises them directly with Authorize.Net, and what we store is two opaque profile identifiers plus four display facts: card brand, last four digits, expiry month and expiry year. We also keep a record of each charge — amount, currency, plan, period, gateway transaction id, authorisation code, and any decline reason. The currency is always US dollars: the merchant account settles in nothing else, so a charge in another currency is not something we could record because it is not something we could take. There is no column in our database that could hold a card number or a security code.

Cookies

Session cookie

Keeps you signed in. Strictly necessary.

vb_org

Which workspace you are currently working in. Strictly necessary.

vb_theme

Whether you chose the light theme. A preference, set only when you press the toggle.

Those three are the only cookies this product sets, and there are no analytics or advertising cookies at all. There is no tag manager, no advertising pixel, no session-replay recorder and no third-party analytics SDK anywhere in the application or in what it depends on. Nothing profiles you across sites, because there is nothing here that could. Even the typefaces are served from our own domain rather than fetched at page load, so opening a page makes no request to anyone but us.

One exception, and it is deliberate: opening the card form on the billing page loads Authorize.Net’s own script from Authorize.Net. That is the mechanism described above — the script is what carries your card details to them instead of to us — and it loads nowhere else in the product.

• To run the service — render speech, clone voices, transcribe, dub, store your work and show it back to your workspace.
• To meter and bill — enforce plan allowances, charge renewals, produce receipts and chase failed payments.
• To keep the platform safe — rate limiting, abuse and fraud investigation, and responding to reports that a voice was cloned without consent. This is what the IP addresses in the request and audit logs are for.
• To improve your own voices — see the training section below, which is the one use most people would not guess.
• To contact you — and there are exactly two messages this product can send: a workspace invitation, and a password reset you asked for. We send no marketing email at all. There is no mailing list, no newsletter and therefore no opt-in to give and no preference centre to manage. If that ever changes it will be opt-in, and this paragraph will change with it. A failed payment is not an exception: dunning is shown on the billing page, not mailed to you.

Where the law you live under requires a lawful basis to be named, these are ours, in the order above: performance of our contract with you for running the service, for improving your own voices, and for the two messages we send; performance of that contract plus our legal obligation to keep tax and accounting records, for metering and billing; and our legitimate interest in a platform that is not used to defraud or impersonate people, for rate limiting, abuse investigation and the IP addresses the logs keep. There is no marketing purpose in the list, so there is no consent to collect for one.

Voice recordings are the exception, and they run on consent — the speaker’s, held by you. You must have documented permission before you upload a clip; the uploader says so at the control rather than only in a document you read once. Be clear about what that does and does not mean here: the product does not capture a consent artefact. There is no tickbox and nothing stored, deliberately, because a tickbox that records nothing is not a consent record. The obligation is real and the evidence of it is yours to keep — the voice notice sets out what it has to cover. We do not sell voiceprints, do not send them to any model vendor, and do not use them to identify anyone.

Renders kept in your workspace’s history are used as training material for professional clones of your own voices. When an admin of your workspace starts a training run, the service assembles a dataset of that workspace’s finished renders of that one voice — the generated audio paired with the script that produced it — and a GPU job fine-tunes an adapter on it.

• The dataset is filtered to a single workspace and a single voice. Your audio is not pooled with other customers’, is not used to train the shared speech engine, and is never used to make a voice you do not own sound better.
• There is no consent prompt and no per-render opt-out today. Eligibility follows from keeping a render in history. If you do not want a render used, delete it before a training run; the only control that exists is deletion.
• The dataset manifest is written into the speech engine’s own Google Cloud Storage bucket so the training machine can read it. The audio itself stays in our bucket and is read from there. Neither is sent to a third-party model provider.
• Deleting renders removes them from future datasets. It does not remove what an adapter already trained on has learned — retraining or deleting the voice is the only way to undo that.

We do not sell your content, and we do not license it to anyone to train their models.

We use the following categories of subprocessor. Which of them actually receive data depends on what a given deployment has configured — several are optional. Where one is not configured, nothing is routed to a substitute: the control that needs it is disabled, or the job stops and says why. Email is the exception in how it degrades, not in where the data goes — see its entry below.

Google Cloud

Hosting, the object storage holding all your audio, and the GPU machines that run the speech engine and voice training. All of it is in the United States. The console, the database and the bucket your audio sits in are in us-east4; the speech engine and its GPUs are in us-central1; the file converter that lets the script writer read a Word document or a PDF is in us-east1. The engine keeps its own bucket, which is US multi-region — that is where a fine-tuned adapter and a training manifest land, as the retention section explains. All of those are our own services in one Google Cloud project, and nothing is stored or processed outside the United States.

Authorize.Net

Card tokenisation, storage and charging. They hold the card; we hold an identifier and the last four digits. Setting a workspace up at the gateway also sends them the workspace name and the email address of its owner, so the charge has a customer record attached to it.

Resend

Transactional email. Receives the recipient address and the message — which, as above, is only ever an invitation or a password reset. With no mail provider configured those are written to our own server log instead, so the address and the message, including a live password-reset link, sit in our infrastructure logs rather than going to a third party, and the sender is told the message was sent.

A language model — Anthropic, OpenAI or Moonshot

One configuration serves every feature that needs a language model, so which of the three receives the text is whichever a deployment names — and with none named, no model vendor is contacted at all and the features that need one are disabled or stop and say why. What is sent is text: the script, brief or transcript being worked on for the script writer, dubbing translation and the multi-voice converter; the lines of a transcript when the video maker writes prompts for a storyboard that cuts with what is being said; the incidents, conditions and your own station wording when a traffic or weather bulletin is drafted; and, in the assistant, the workspace records it reads on your behalf while answering you — voice names and labels, history entries and the scripts on them. When you give the script writer a PDF with no text in it or a photograph of a page, the page images themselves go too, because reading them is the whole job. No audio ever does.

Replicate

Generated stills and generated moving backgrounds for the video maker. It receives the prompt and nothing else: either the words you type into the generate control, or — for a storyboard — the prompt a language model wrote for each beat from the lines of your own transcript. It returns pictures, which we download and store under your workspace. It never receives your audio, and nothing it returns is speech. Reached only where a deployment has configured an API token for it; without one the generate controls are disabled and uploading your own still works exactly as before.

ElevenLabs

Three separate features, and a deployment can have any, all or none of them. Sound-effect generationreceives the description you type — “distant thunder over wet pavement” — and returns the effect. Voice designreceives a description of a voice you want, typed by you or assembled from the designer’s own options, together with the fixed sample sentences the designed voice reads, and returns preview audio that we keep in our own storage as an ordinary reference clip. Neither of those ever receives a clip you uploaded or a render you made, and once a designed voice exists nothing about rendering it goes back to them — the waveform is ours from that point on.

Live conversation is the third, and it is the one place in this product where audio goes to somebody else. A voice agent is a spoken, two-way conversation held in real time, and our own speech engine cannot hold one — it renders a file when it is asked to and has no live path at all — so the conversation runs at this provider. Three things go to them. First, the agent itself: its instructions, its greeting, its language and its voice settings are registered in their account, so that a call can be answered with them. Second, and this is the exception to everything else on this page, the speech itself, live, in both directions— what the person is saying goes to them as it is spoken, and the agent’s reply comes back the same way. It goes directly, from the browser holding the conversation, or from your carrier where you have connected a telephone number; it does not pass through this service on the way. Third, once the conversation is over we read the record of it back out of their account — the transcript, a summary, how long it ran and what it cost — which is how a conversation comes to be in your workspace at all.

Two consequences we would rather state than leave you to work out. They keep their own copy of the call, its audio included, in their account and on their retention terms rather than ours; nothing in this product fetches or stores that audio, so what we hold about a conversation is text. And a voice cloned on our engine cannot speak in a conversation unless this provider already holds its own copy of that voice — we do not upload your reference clips to them in order to make one, and the picker marks the voices that will not work rather than failing quietly at the call.

Soundraw

Generated music beds for the mixer. Receives the mood, genre, theme and length you choose — no text of yours and no audio — and returns a track we download and store like any uploaded bed. Reached only where a deployment has configured a key for it; without one the Generate tab is disabled and uploading your own track is unaffected.

Freesound

Creative Commons sound-effect search. Receives your search query, and we download the preview of anything you keep.

A traffic or weather feed — TomTom, HERE or a 511 agency

The bulletin surfaces need live incidents and conditions, which the speech engine has no way to know. What goes out is geography, not content: the bounding box of a coverage area you drew, the coordinates of a market you configured, and the place name you type when searching for one. No script, no audio, and nothing about who is listening. Which vendor is reached, if any, depends on which one a deployment names for each feed and the key that goes with it; with none named the surfaces are disabled.

Google / GitHub

Only if you choose to sign in with them, as identity providers.

None of the audio stored in your workspace goes to any vendor above. Not a clip you uploaded, not a reference clip, not a render, not a mix, not a dub. Speech synthesis, cloning, transcription and training all run on our own engine and our own infrastructure, and nothing in your library is sent anywhere.

Live conversation is the one exception, and it is audio. While a conversation with a voice agent is running, the speech goes to the conversation provider named above as it is spoken and its reply comes back the same way. That is the whole of the exception, and it is worth being precise about its shape: what leaves is what is being said at that moment, never anything stored, and it goes straight from the browser or the carrier to that provider rather than through us. It happens only where a deployment has configured a conversation provider; where none is configured, the control is disabled with the reason on it and no conversation can be started at all.

Everything else that leaves, where a feature needs it, is text — and in the one case named above, page images — as each entry sets out: a script or a transcript to a language model, a prompt to an image model, a description to the sound and voice designers, a search term to Freesound, a bounding box to a traffic feed. Everything they send back we download and store under your workspace, so no vendor becomes a place your work lives.

We also disclose data where the law requires it, and to professional advisers or an acquirer in a corporate transaction, subject to equivalent protection.

The list above is the subprocessor list.There is no separate subprocessor page, and we would rather keep one list right than two lists that disagree. For the current version with each vendor’s location and contract terms, ask [email protected], marked for the attention of the privacy team.

One kind of recipient is deliberately not in that list, because it is not ours to choose: places you tell us to send things. A webhook endpoint you configure receives the event payload and a short-lived signed link to the audio it refers to, and it receives them because you asked it to. We do not pick the recipient, we cannot see what it does with them, and it is your integration rather than a subprocessor of ours.

Your telephone carrier is the same kind of recipient. A number you point at a voice agent is not one we sell you and not one we move: it stays on your own carrier account, you go on paying them for it, and what you give us is permission to answer it — we hold the credential you enter so that we can accept the call and hand the audio on. So your carrier sees your calls because they are your carrier, and they are your supplier rather than ours. What we get from them, and keep, is described under retention below.

Everything we hold is stored in the United States, at the regions named above, and everything we process ourselves is processed there. The subprocessors above process what each of their entries says they receive, wherever they themselves operate — which is why that list points you at us for their locations rather than guessing at them here. If you are outside the United States, using Voice Buddy moves your data into it; where the law you live under requires a transfer mechanism for that, we rely on the standard contractual clauses.

No content is deleted automatically. Nothing you make here expires on a timer. It stays until you or we delete it. That is a deliberate statement of fact, not an aspiration — no retention sweep exists in the codebase, so promising one here would be false. The two exceptions are not content: infrastructure logs age out, and so do backups, both covered at the end of this table.

Voice clips and previews

Kept until the voice is deleted. Deleting a voice erases its uploaded clips and its preview from object storage at the same time, not later.

Renders made with a voice

Survive the voice being deleted. The history row is unlinked from the voice, but the generated audio and its script remain in the workspace until deleted individually or with the workspace.

Uploads, transcripts, dubs, mixes, projects

Kept until deleted.

Calls to a phone number you have connected

When you point one of your own telephone numbers at a voice agent, we record that a call happened: the number that was dialled, the number it came from, when it started and ended, how long it ran, and — where an agent answered — what was said and any attempt to transfer the caller to a person. The caller is a member of the public who has no account here, so their own telephone number is reduced to its last four digits 90 days after the call ends, automatically, and that reduction cannot be undone. Everything else about the call is kept until the workspace is deleted, which erases it by cascade like any other workspace row. That reduction is the only thing on a timer here: nothing in this product deletes a transcript after a period, so what was said stays until the workspace goes or you ask us to erase it.

Conversations with a voice agent

Whether it was held down a telephone line or from the console, what we keep of a conversation is text and figures: what was said on both sides, the summary the provider wrote, when it started, how long it ran, why it ended, and what it cost. Same lifetime as the row above — until the workspace is deleted, or until you ask.

This product does not record the call, and it is worth being exact about what that does and does not mean. The audio travels between whoever is speaking and the conversation provider without passing through this service, and nothing here fetches or stores a copy of it — there is no recording in our storage to keep, to hand over, or to lose. It does not mean that no recording exists anywhere: as the subprocessor list above says, the conversation provider keeps its own copy of the call, audio included, in their account and under their retention terms. Purging that one is a request to [email protected], like the other things that sit outside this database.

Deleting a workspace

Removes its rows — voices, renders, transcriptions, projects, API keys, webhooks — by database cascade, and queues a job that deletes every stored object belonging to that workspace. The storage half is asynchronous: it is created in the same transaction as the deletion so the two cannot come apart, then works through the files in pages and retries on failure, so the bytes are gone shortly after rather than instantly.

Rows that outlive a workspace

Mixes, generated scripts, multi-voice scripts, pronunciation entries and reports, and booth sessions and their takes are stored with the workspace id as a plain column rather than a foreign key, so deleting a workspace leaves them in the database. Every query filters on workspace, so they are unreachable in the product — but they are not gone, and a deletion request has to clear them explicitly. Their audio is not among them: that lives under the workspace prefix and the teardown above erases it.

Trained voice adapters

A professional clone’s fine-tuned adapter is written by the speech engine into the engine’s own storage, outside the per-workspace prefix. Nothing in the product deletes it — not deleting the voice, not deleting the workspace. Removing an adapter is a manual request to [email protected].

Training manifests

Starting a training run also writes a manifest — the list of clips the run learned from, each with its script in plain text— into the speech engine’s storage, again outside the per-workspace prefix and at a path derived from the voice’s id. Deleting the voice does not remove it; deleting the whole workspace does, because that teardown is handed the trained voices’ ids and erases their manifests along with the workspace’s own files. So a workspace that deletes one trained voice and carries on still has that voice’s scripts in the engine’s bucket. Ask [email protected] to purge one.

Billing records

Payment and subscription rows belong to the workspace and are deleted with it — closing a workspace takes its charge history out of this database along with everything else. What we keep after that is the accounting record of the charge, which we hold for seven yearsto meet US tax record-keeping requirements: the amount, the date, the plan, the last four digits and the gateway’s reference. Never a card number — there is no column that could hold one.

Logs and audit records

Nothing prunes these on a timer. API request logs and audit rows sit in the workspace’s own tables and go when the workspace goes, by database cascade — except the few audit rows written after an account is closed, which belong to no workspace and stay. Separately, the server’s console output goes to Google Cloud Logging and is deleted after 30 days. Google’s own record of administrative actions on our infrastructure is held for 400 days on a bucket we cannot shorten; that is about who changed a setting, not about your content.

Backups and the week after deletion

Deleted is not instantly unrecoverable, on either half. The database keeps seven automated daily backups and seven days of transaction logs, so a deleted row can survive in a backup until the last one containing it ages out. The audio bucket has no versioning and no lifecycle rules, but object storage keeps a deleted object recoverable for seven daysbefore it is unrecoverable for good. So the honest answer to “when is it really gone” is about a week, both times.

What you can do yourself

• Delete a voice — voices, then the voice, then Danger Zone. Requires the Admin role. This erases the uploaded clips and the preview from storage immediately.
• Delete a single sample from a voice without deleting the voice.
• Delete a workspace — Settings, Workspace, Delete workspace. Owner only, and you must type the workspace name to confirm. This removes the rows and queues the deletion of every stored file the workspace owned.
• Delete your account — Settings, Account. You type your email address to confirm. Workspaces where you are the only member are deleted with the account, and you have to tick a box naming them first. Workspaces with other members carry on without you. If you are the last ownerof a workspace that still has other members, deletion is blocked until you make somebody else an owner — we will not strand other people’s work or leave a workspace nobody can bill.
• Revoke an API key at any time from Settings.

Deleting your account does not delete work you created inside a workspace that survives you. Voices, renders and API keys stay with the workspace that paid for them and simply lose their author.

What you have to ask us for

Email [email protected], marked for the attention of the privacy team, for anything the console cannot reach: purging a trained voice adapter, purging the training manifest of a voice you deleted without deleting its workspace, purging the copy of a conversation the conversation provider holds in their own account, erasing what was said in a conversation, clearing the leftover rows described in the retention section, or a copy of your data.

Depending on where you live you may have rights to access, correct, delete, port or object to the processing of your personal data, and to complain to a regulator — in the United States that is generally your state attorney general, and elsewhere the data protection authority where you live. We do not require you to be covered by any particular law to ask: we answer every request the same way, whoever sends it, because sorting people by which statute protects them costs more than simply doing the work.

We will answer within 30 daysof a request we can verify. Verification is deliberately low-friction and does not involve sending us identity documents: send the request from the email address on the account, and for anything workspace-wide be an owner or admin of that workspace. If we cannot match a request to an account we will say so rather than guess, because handing one person another person’s voice recordings is the failure that matters most here.

Voice recordings get the shortest path we have: if you are the person whose voice was cloned, you can ask us to erase it whether or not you have an account here. Same address, same 30 days. The voice notice is written for you as much as for the account holder and sets out what we will need in order to find the voice.

• Passwords are hashed. API keys are hashed at rest and shown once, at creation, so a stolen database does not yield working keys.
• Every stored object lives under a path prefixed with the owning workspace, and the code builds those paths through a single helper — tenant isolation is structural rather than a filter someone can forget.
• Card data never touches our servers.
• Audio is served through short-lived signed links rather than public URLs.

No system is perfectly secure. If personal data of yours is breached we will tell the affected customers without undue delay, and within 72 hours of becoming aware of it — with what we know at the time, rather than waiting until we have a complete picture, because a late complete answer is worse than an early partial one for anyone who has to act on it. Where the law also requires us to notify a regulator, we will.

Report a vulnerability to [email protected] with “security” in the subject line. We will acknowledge it within two business days. We do not run a bug bounty and have no money to offer, but we will credit you if you want the credit and keep you out of it if you do not.

Voice Buddy is for adults. You must be 18 or older to hold an account.The threshold is 18 rather than 13 because the service takes card payments and processes biometric data, and neither is something to do on a child’s say-so. We do not knowingly collect data from anyone under 18.

Cloning a child’s voice is a separate question from holding an account, and it is allowed only with the consent of a parent or guardian — the voice noticecovers it. If you believe a child’s data or voice is in the platform, write to [email protected] and we will remove it.

Updates are posted here, and the date at the top of the page is when the version you are reading took effect. For a material change — a new purpose, a new subprocessor, a longer retention period — the new version goes up at least 30 days before it takes effect, so there is time to read it and to leave if you do not like it.

We deliberately do not promise to email you about it. As set out above, this product sends two kinds of message and neither is an announcement; there is no list to add you to, and a commitment we have built no way to keep is not worth writing down. Checking this page is the mechanism.