UtteraUttera

What we do with your data

The short answer: process it and hand it back. Nothing else. Uttera is not an archive or a backup: the audio you send comes in, becomes what you asked for, goes out and disappears.

DataWhat happens to itHow long
The audio you uploadProcessed in memory and discarded when we answer.As long as the request takes
The transcript, the translation, the analysis, the summaryThey travel in the response. They are not stored anywhere.Nothing
The audio we generateCached so we can repeat it back to you cheaply. You can turn it off on every request.1 hour, or nothing
The text you give us to readUsed to synthesize. Its hash identifies the cache entry.1 hour
What we've charged youThe last ten charges, so we can show them to you.1 hour
Connection logDate, IP, path, size and response code. No content.180 days
Your accountEmail, plan and keys. While you're a customer.Until you delete it

We don't train on your data, and we don't aggregate it

This section exists because it's where almost everyone keeps a door open for themselves. The usual formula is "we don't use your personal data" and, underneath it, permission to use that same data once aggregated or "anonymized". That door isn't here:

And it doesn't depend on our good intentions. A promise not to use something you have stored is worth only as much as whoever signs it. Here the promise is stronger because it's a consequence: no copy survives to do it with. Audio is processed in memory and discarded when we answer; the only thing that survives an hour is the audio we generate for you, and it deletes itself.

The models learn nothing from what passes through them: every request begins and ends without leaving a trace in the model.

What this does not say

It pays to be exact, because the short sentence — "we don't train models" — says more than we mean. This is not a promise never to train. Training a model is legitimate and it is how this technology advances.

If one day we fine-tune a model of our own, it will be for what is actually needed: better pronunciation — Spanish from Spain has sounds that open models tend to swallow — better intonation, the way people actually speak, and better delivery of what the text asks for. And it will be with lawfully obtained material: public-domain corpora, purchased licenses, or recordings commissioned and paid for by us. It will be said here when it happens.

The line that is not crossed is the other one, above: what passes through a customer's API never goes in there — not with implicit permission buried in some terms, not aggregated, not "anonymized". That distinction is precisely the one almost nobody makes, and it's the one we care about.

If we ever wanted to use customer material to improve a model, it would take asking, explaining, and somebody saying yes — that is, it would be a different product and you'd know about it. It is not something that can happen through a silent change to terms of service, because today there is nothing stored to activate.

The voice cache lasts one hour

When you turn text into speech, we keep the resulting audio for 60 minutes. If within that hour you ask for exactly the same thing — same text, same voice, same format — we serve it from disk in a few milliseconds instead of generating it again, and it costs you 10%. The response tells you so with the X-Cache: HIT header.

The file name is a hash of the request, not a customer identifier. It is computed from the text, the voice and the parameters, and that's all there is: nothing on disk says who asked for it. Two customers asking for the same text with the same voice share the entry, which is why the cache cannot know whose it is — it isn't anyone's.

What the file does contain is what was said, because it is the audio. That's why it is treated as data and not as something harmless: it lasts an hour and is deleted.

It exists for a concrete reason: in a real integration the same announcement, the same menu or the same welcome sentence gets asked for hundreds of times. Regenerating them every time would be slower for your user and more expensive for you.

After the hour, the file is deleted from disk. It is not marked expired and left there: a periodic process removes it. The difference matters — an "expired" file still on disk is still stored data — and that's why the deletion is real.

And if your case can't accept even that hour, you decide, without asking us for anything. Any request can stay out of the cache: just "cache": false in the body or the Cache-Control: no-cache header. The audio is generated and delivered to you the same, but nothing is written to disk. The response confirms it with X-Cache: BYPASS, so you don't have to take our word for it. The cost is that you pay full price, because it's generated every time. How it's done.

Where the system is

Everything — the API, the models, the graphics cards doing the work and the little disk that gets used — is in our own data centers in Andalusia, southern Spain, inside the European Union. There is nothing on another continent, nothing in a third-party cloud, and no "just in case" replica in another jurisdiction.

This matters more than it seems. When a vendor processes personal data outside the European Economic Area, the transfer needs its own legal basis — standard contractual clauses, impact assessments, and the uncertainty they've carried since Privacy Shield fell. Here that problem doesn't exist: there is no international transfer to justify because no data leaves.

Nothing is sent to third parties

Your audio and your text do not leave our infrastructure. Not to transcribe, not to translate, not to summarize. Specifically:

WorkWho does it
Transcribing and analyzing the voiceOur own models on our GPUs.
Text to speechOur own engines on our GPUs.
TranslatingA translation engine that runs on each node, locally.
SummarizingA language model that runs on our own hardware.

The summary deserves its own paragraph, because it is where nearly everyone ends up calling somebody else's API. We don't: the language model is installed on our machines and only listens on its local interface. There is no call to OpenAI, to Anthropic, to Google or to anyone. The network route to make one doesn't even exist.

There are two third parties, and they're the usual ones: your payment gateway — Stripe, which handles your billing data and never sees your audio — and, if you sign in with Google or GitHub instead of with your email, the provider you identify with. Neither of them touches the content you send us.

Everything encrypted in transit

The connection between your system and ours runs over HTTPS with TLS 1.2 and 1.3, with a certificate issued by a public authority. Cleartext traffic is not accepted: port 80 only redirects to 443.

Inside our facility, traffic between the edge and the compute nodes runs over a private network that is not routed to the internet and that nobody outside can reach. The edge also runs isolated in its own container, without access to the rest of the machine hosting it.

What we do keep, and why

No serious system runs without logs. Ours are designed so we can answer "what happened to this request" without keeping what was inside it:

LoggedNot logged
Date and time · source IP · method and path · response code · bytes · duration · node that served itThe audio · the text · the transcript · the translation · the summary · any analysis result

That log is kept for 180 days and then destroyed. The usage counters store numbers — how many requests, how many credits, how many seconds of audio — never what was in them.

And it is kept deliberately. It is the only way to investigate an incident: an abuse, an attempted fraud, a customer asking what happened to a particular request, a node that failed at three in the morning. A service that cannot answer "this is what happened" isn't more respectful of your data, it's simply worse. The GDPR doesn't prohibit it: network security is an expressly recognized legitimate interest (art. 6(1)(f) and recital 49). What it requires is that the period be defined and proportionate. Six months is: it's the period commonly used for security logs, and it comfortably covers the time in which an incident is detected, investigated and closed, without becoming a historical archive.

The X-Request-Id header returned by every request is the thread that ties your report to our log. It is also the reason we can help you without keeping your content: the identifier is enough.

Why this complies with the GDPR

"We comply with the GDPR" is something everyone says. This is what's behind it, article by article:

PrincipleHow it's met here
Minimization (art. 5(1)(c))Only the audio you send is processed, and only for as long as the request lasts. We ask for not one item of data beyond what is needed to provide the service and bill it. And the only thing written to disk — the generated audio, for an hour — you can disable request by request, without asking anyone's permission.
Storage limitation (art. 5(1)(e))Everything has an expiry and deletes itself: content, none; cache, one hour; charges, one hour; logs, six months.
Integrity and confidentiality (art. 5(1)(f) and art. 32)Encryption in transit, unrouted internal network, edge isolated in a container, API keys revocable instantly, and separation between accounts.
No international transfers (arts. 44 to 49)Processing happens entirely in Spain. There is no transfer to justify because none occurs.
Right to erasure (art. 17)Immediate by construction: there is no copy of your content to delete. Of your account there is, and it is removed when you ask.
Access and portability (arts. 15 and 20)There is a Download my data button in your account that hands you a JSON with everything we hold about you: account, keys, subscription and usage. A screen does not satisfy article 20; a file a machine can read does.
No secondary use (art. 5(1)(b))Data is processed to give you the service and for nothing else: it trains no models, it isn't aggregated and it isn't "anonymized" for reuse. Purpose limitation here isn't a policy, it's that no copy survives.
Automated decisions (art. 22)We don't make them. The speaker profile is an acoustic estimate and we say so everywhere: it must not be used to decide anything about a person.
Processor (art. 28)You are the controller of your users' data; we process it on your behalf and only to give you the service. The processing agreement is available to sign.
What this doesn't take off your plate. If you record people, the duty to inform them and to have a lawful basis for doing so remains yours: we are the tool, not the controller. And in Spain a voice is personal data — it identifies whoever is speaking — even if no name is said.

Special categories of data

This is worth saying plainly because almost nobody warns about it: tone analysis and speaker profiling produce inferences about a person from their voice. Depending on what they're used for, they can come close to what the GDPR calls special categories (art. 9).

Our position is the one already written in the documentation of those services: they are acoustic estimates, they get things wrong, and they must not be used for anything with consequences for a person — not for hiring, not for scoring, not for deciding who gets served. If your use case comes near that line, it's a case that calls for an impact assessment before an integration.