A document does not exist as one copy inside a translation service. Uploading it creates a chain: the stored original, an extracted text representation, possibly OCR output, chunked segments queued for processing, cached results, the assembled output file, and log entries describing all of it. "Zero retention" almost always refers to the first and last of those — the uploaded file and the delivered translation — and says nothing about the middle. The questions that determine your actual exposure are which derived artefacts exist, how long each lives, whether removal is a deletion or an expiry, and whether any of it is written into the contract rather than a help page.
This guide follows a file through that lifecycle stage by stage, then covers how to verify a vendor's answers in terms you can enforce.
The Lifecycle Has More Stages Than the Marketing Page
Trace a single upload and the stages are consistent across most architectures, whatever the branding.
The file arrives at an ingestion endpoint and is written to object storage. An extraction stage parses it — unzipping an Office container or walking a PDF's content streams — and produces a structured text-plus-layout representation. If the document is a scan, an OCR stage produces a second text representation. The text is segmented and queued; queue payloads contain content. Segments go to the translation engine, which may cache results keyed on the source segment. The translated segments are reassembled into the original file structure and written back to storage. The user downloads it. Throughout, services emit logs, metrics and traces.
That is seven or eight places a copy or a fragment of your document exists, created by one upload. A retention answer that addresses one of them is not wrong, exactly. It is partial.
Zero Retention Is a Scope Claim
"Zero retention" is a real and valuable commitment, but it is a claim about a scope, and the scope is rarely stated in the phrase itself.
Read it as answering three questions and ask which ones it actually covers. Does it mean the uploaded source file is deleted immediately after processing? Does it extend to the translated output — which is genuinely useful to retain for re-download, and which many services keep for that reason? And does it reach the derived artefacts listed above, or stop at the two files a user can see?
There is a fourth reading that matters more than the other three: some vendors use "zero retention" to mean content is not retained for training, which is a different commitment entirely and compatible with keeping your file for thirty days. Both are worth having. They are not the same promise, and the word "retention" is doing different work in each.
Ask for the sentence, not the phrase. A vendor who means it will happily give you the sentence.
Derived Artefacts Outlive the Source
The extracted text is the artefact most likely to survive the file it came from, and the one with the highest information density — no formatting, no images, every word of the document in a form built for machine reading.
Ask about each derived artefact separately, because they usually have different lifetimes and different owners:
Extracted text and layout model. Where stored, for how long, encrypted at rest with which key?
OCR output. Same questions, plus whether the page images produced during OCR are retained.
Queue payloads. Message queues have their own retention settings, frequently defaulted and rarely reviewed.
Translation caches. A cache keyed on source segments is a searchable copy of your sentences. Ask whether it is per-tenant or shared, and whether it can be disabled.
Temporary working files. Container filesystems and scratch volumes; ask what cleans them and when.
A shared translation cache deserves particular attention, because it is the one artefact whose purpose is to be reused. The answer you want is per-tenant isolation, or an opt-out.
Logs Are Usually the Longest-Lived Copy
Observability retention is set by an infrastructure team for operational reasons and rarely appears in a privacy discussion. It is frequently the longest retention period in the system.
Two questions matter. Do logs contain content — a request body, an error carrying the failing segment, a trace attribute holding the input? And do they contain metadata that is itself sensitive? In legal and M&A work the file name is often the most confidential string in the system; a log line reading Project Hesperus — SPA v11 — Sanchez.docx discloses the deal, the stage and a party without containing a word of the document.
So ask for the log retention period, whether content is redacted or hashed at the logging layer, whether file names count as content or metadata, and who inside the vendor can query the log store. If logs are kept for a year in a system with broad internal read access, that is your real retention period. The same reasoning applies to third-party assistants — is Gemini safe for confidential documents works through that case.
Deletion and Expiry Are Different Guarantees
Two vendors can both say a document is gone after seven days and mean quite different things.
An expiry is a lifecycle policy: an object store rule marks the object for removal after N days, and a background process eventually reclaims it. It is reliable in aggregate, imprecise in timing, and it does not act on a request — you cannot make it happen sooner.
A deletion is an action taken on demand: the object is removed when you ask, and the operation returns a result. Deletions also cascade, or should — the request must reach the derived artefacts, the cache and the queue, not only the object you named.
Ask which one the vendor operates, and then ask the awkward follow-up: is deletion a hard delete or a soft delete with a tombstone and a recovery window? Soft deletes are good engineering and honest vendors admit to them. What you need is the recovery-window duration, in writing, because that is when the document is actually gone rather than merely invisible.
Backups Deserve a Straight Answer
Backups are where retention answers most often quietly break. A responsibly run service takes backups and cannot selectively excise one customer's document from a backup set without restoring it, which defeats the purpose of the backup.
The honest position, and the one to look for, is: backups exist, they are encrypted, they roll on a fixed cycle of N days, deleted content persists in them until it rolls out of the window, and backups are not used as a source for anything other than disaster recovery. That is a defensible answer and most regulators treat it as such.
The answer to be sceptical of is "your data is deleted everywhere immediately," which either means there are no backups — operationally alarming — or that nobody asked the platform team. Under GDPR, erasure obligations are assessed with reference to what is technically feasible; a vendor who explains the backup window is demonstrating exactly the kind of specificity that survives an audit. Contributors to a thread on privacy-compliant translation software reach the same conclusion from the practitioner side.
Deletion Should Be Callable, Not Requestable
For anything running at volume, deletion through a support ticket is not a control. It is a favour with a queue in front of it.
What you want is a delete endpoint that takes a document or job identifier, and it should behave like a real API: idempotent, so a retry is safe; returning a status that distinguishes deleted from already-deleted from not-found; and cascading to derived artefacts rather than the stored file alone. A bulk variant matters if you translate data rooms, where the retention obligation attaches to the matter and closing it should clear hundreds of documents in one call.
Two further asks make it auditable. A deletion receipt — a record with a timestamp and identifier you can file — and a status endpoint that confirms an identifier no longer resolves. Where the vendor uses sub-processors, ask how deletion propagates to them and on what timeline. Integration considerations around this are covered in the document translation API guide.
Verification Is Contractual, Not Conversational
Everything above is worth exactly as much as its position in your paperwork. Help pages change without notice and cannot be relied on in a dispute.
Get five things into the data processing agreement. Retention periods as durations for source, output and derived artefacts. An explicit training and human-review clause. Deletion on request with a maximum completion time and a defined backup exclusion. The sub-processor schedule with a change-notification period. And an evidence right — realistically the ability to request the current SOC 2 Type II report and the ISO/IEC 27001 certificate with its scope statement, annually.
Then run one practical test during the trial. Upload a document, translate it, delete it through whatever mechanism exists, and attempt re-download immediately, after an hour and the next day. Note what each attempt returns — it tells you whether deletion is a state change or a scheduled hope. Ask Bluente the same questions you would ask anyone else; the answers belong in your agreement, not in a blog post. Teams handling regulated filings can start from GDPR compliant document translation.
Sources and Further Reading
Regulation (EU) 2016/679 — GDPR, official text, including Articles 17 and 28
Data privacy compliant translation software — practitioners comparing retention and deletion terms across translation tools
Related Reading
Last reviewed 24 August 2026 by the Bluente document engineering team, who build and test the pipeline described here. We update these guides when the underlying standards, regulations or file formats change.
Know where the copies are before you upload the first file. Try BluTranslate free.