A translation service is rarely a single company handling your file. It is a chain: the vendor you contracted with, the cloud region storing the upload, and in most cases an upstream model provider performing the actual translation. Your document inherits the retention period, residency and training terms of every link, not just the first one. The buyer's job is to get that chain named in the data processing agreement, with locations and a change-notification clause, before the first file moves — because a sub-processor you cannot name is a transfer you cannot lawfully assess.
This guide covers how the inheritance works, why the sub-processor list belongs in the contract rather than a help page, what to ask about onward transfer, and what to do when a vendor declines to answer.
Inheritance Is the Default, Not the Exception
Buyers evaluate the vendor in front of them. They read that vendor's security page, note its certifications, and stop. The document, meanwhile, keeps travelling.
A typical pipeline for an AI translation product has at least four hops: an ingestion service that accepts the upload, an object store that holds it, an extraction stage that pulls text and layout out of the file, and an inference provider that produces the translated text. Any of those can belong to a different company in a different jurisdiction. If the inference provider retains prompt content for thirty days for abuse monitoring, your contract's zero-retention promise describes only the first hop.
This is not vendor malpractice. It is architecture, and it is disclosed by anyone reputable. The failure is on the buying side, in an assessment that treats the contracting entity as the whole system. Ask what the file touches, in order, and the picture resolves quickly.
Where the Sub-Processor List Actually Belongs
Most vendors publish a sub-processor list somewhere. The location matters more than the content.
A list on a documentation or trust page is a snapshot the vendor can change silently. A list incorporated by reference into the data processing agreement is a contractual object, and changing it triggers whatever notice and objection process the agreement specifies. Under GDPR Article 28, a processor engaging another processor needs your authorisation — general or specific — and must inform you of intended changes so you have an opportunity to object. That right is worth nothing if the list lives on a webpage nobody watches.
So the three things to negotiate are: the list attached as a schedule to the DPA, a notification period before a new sub-processor begins processing (thirty days is a common ask), and a defined objection path. If objection means only "you may terminate," say so out loud in the negotiation, because that is a very different remedy from a change you can actually block.
Reading a Sub-Processor Entry Properly
A useful entry has four fields, and most published lists have two.
Legal entity. Not the brand. "Cloud hosting" tells you nothing; the contracting entity and its country of establishment tell you what law applies.
Function. What this sub-processor does with content — storage, compute, OCR, inference, email delivery, support tooling. Support tooling is the one buyers skip and the one that most often results in a human reading a document.
Processing location. Region-level, including any failover region. A service that normally runs in Frankfurt but fails over to a US region during an incident has a transfer story it needs to tell in advance, not afterwards.
Content exposure. Whether the sub-processor sees document content, metadata only, or account data only. A payments provider on the list is not a document-confidentiality issue; an analytics tool with access to file names might be, because file names in legal and M&A work are frequently the most sensitive string in the system.
Onward Transfer Is the Question Behind the Question
Once you know who the sub-processors are, the follow-up is what happens when they hand the data on again. GDPR Chapter V obligations bite on transfers to third countries, and they do not stop at the first hop.
Ask for the transfer mechanism by name for each cross-border leg — standard contractual clauses, an adequacy decision, or a certification framework — and ask when the transfer impact assessment was last refreshed. Then ask the question that separates paperwork from practice: does the vendor flow equivalent obligations down to its own sub-processors, and can it produce the clause that does so?
For financial-sector buyers, DORA adds a register-of-information requirement covering ICT third-party arrangements and, in substance, their subcontracting chains. If you are already maintaining that register, translation vendors belong in it, and the sub-processor detail you need for the register is the same detail you need for the DPA. Collect it once. This is the same discipline that applies to due diligence document workflows, where the underlying material is often the counterparty's, not yours.
The Upstream Model Provider Deserves Its Own Section
When translation is performed by a general-purpose model accessed through an API, several terms of that provider's enterprise agreement become facts about your document, whichever badge sits on the reseller's website.
The specific terms to trace upstream: retention window for request and response content, whether abuse-monitoring logs retain content and for how long, whether human review is possible under any circumstance, whether content may be used for model training or evaluation, and the processing region for inference. Some providers offer zero-retention configurations only on request or only above a certain tier; a downstream vendor may or may not have enabled it.
The right question is therefore not "do you train on my data" but "which upstream configuration are you running, and can you show me the setting or the contract term that proves it?" A vendor operating a zero-retention arrangement will know exactly what you are asking. The same trace is worth running on general-purpose assistants — is Gemini safe for confidential documents works through that example.
Self-Hosted, Routed, or Somewhere in Between
Architecture determines how long the chain is, so it is worth establishing early which of three shapes you are buying.
A vendor running its own models on its own infrastructure has a short chain — usually a cloud provider and little else — and can answer residency questions crisply. A vendor that routes to a third-party model API has a longer chain and inherits that provider's terms wholesale. A vendor operating a hybrid, keeping some language pairs or document types in-house and routing others, has the most complicated story to tell, because the answer to "where does my document go" becomes conditional.
Hybrid is not a red flag. Undisclosed hybrid is. The question that surfaces it: are there any circumstances — a language pair, a file type, a capacity event — under which my document is processed by a system other than the one you have just described? Ask it in exactly that form, because it is hard to answer evasively without saying something false.
When a Vendor Will Not Name Its Sub-Processors
Refusal is common and usually framed one of three ways: commercial confidentiality, security posture, or a claim that no sub-processors exist.
Take the third at face value only if the vendor also runs its own models and its own infrastructure, which is rare and easy to verify by asking who provides compute. For the first two, the response is procedural rather than argumentative. A processor cannot satisfy Article 28 disclosure while refusing to identify who processes the data, so the refusal is not a negotiating position — it is a statement about whether the vendor can support your compliance obligations at all.
Practical middle grounds exist and are worth offering: disclosure under NDA, disclosure by category and jurisdiction with entity names on request, or a commitment that content-processing sub-processors are limited to a named set. Any of those is workable. "We don't share that" is not. Sub-processor opacity comes up regularly in a discussion of Google Translate alternatives, where users discover that a friendly front end sits on an upstream service with entirely different terms.
A Short Mapping Exercise
Before the contract, draw the chain on one page. Four columns: hop, entity, location, content exposure. Fill a row for each stage from upload to delivered file, including support tooling and logging.
Then ask the vendor to correct your drawing. This inverts the usual dynamic — instead of a questionnaire the vendor answers minimally, you present a model they must fix, and corrections are far more informative than answers. Ambiguity shows up as an entity nobody will place in a region, or a hop with no owner.
Bluente's own position is that this diagram should be answerable in a single call, with the processing chain, retention behaviour and residency stated for each hop rather than summarised. Any vendor handling regulated material should be able to do the same, and the ones that can usually volunteer it. The document translation API guide covers where these commitments intersect with integration design.
Sources and Further Reading
Regulation (EU) 2016/679 — GDPR, official text, including Article 28 and Chapter V
Regulation (EU) 2022/2554 — DORA, ICT third-party risk and the register of information
Google Translate alternatives — a privacy community tracing which front ends route to which upstream services
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.
Ask us to draw the chain. We will name every hop. Try BluTranslate free.