Data Security 5 August 2026
Where Does the Data Sent to Machine Translation Engines Go?
Machine translation integration is switched on by default in most translation tools, and it sends every sentence to an external server. We follow the path the data takes, step by step.
When machine translation is used on a translation project, the text makes a journey before it appears on the translator’s screen. Every stop on that journey is a point at which data is processed. The purpose of this article is to make that path visible.
Contents
The path the data takes
In a typical set-up the sequence runs like this:
- The document is loaded into the translation tool and split into sentences (segments).
- The tool first looks each segment up in the translation memory.
- Segments for which no adequate match is found in the memory are sent to the machine translation engine that has been configured.
- The engine returns a suggestion and the tool displays it on the translator’s screen.
- The translator accepts, edits or deletes the suggestion; the result is written to the memory.
The critical step is the third one. The segment leaves the computer the tool is running on and travels to the provider’s server. The whole document is not sent in one go, but every new sentence is sent in turn; in the end most of the text has been transferred.
Why does nobody notice?
Because the process is silent. The translator sees only the suggestion that appears on the screen; the visual cue showing where that suggestion came from is usually minimal. Once an engine has been configured, it carries on working across every project unless it is specified otherwise.
It is precisely to offset this invisibility that memoQ, one of the industry’s widely used tools, shows an explicit warning dialogue while an engine is being configured. The warning passes responsibility to the user, but at least it makes the risk visible.
Why do retention policies differ?
Different products from the same provider may be subject to different data policies. The general tendency is as follows:
| Product type | Typical data policy | Suitability for corporate use |
|---|---|---|
| Free web interface | Broad retention and usage rights | Not suitable for confidential documents |
| Free or low-quota API | Usually no commitment to delete | Should be assessed carefully |
| Paid enterprise API | May carry a commitment to delete after processing | Usable once the contract has been read |
| In-house (on-premise) engine | Data never leaves the organisation | Highest level of confidentiality |
The table shows the general tendency; what governs is each provider’s own contract. The real message here is this: the sentence “we use such-and-such a firm’s engine” says nothing at all on its own. You have to ask which product they use, and on which plan.
How much of the text does the engine see?
A common misconception is that the risk is limited because the machine translation engine does not receive the document as a whole. Look closely at the mechanism and that consolation falls apart.
Translation tools divide the text into units called segments; a segment is usually a sentence. What goes to the engine is these segments. But because almost every new sentence in the document is sent in turn, nearly all of the text ends up being transferred, just piece by piece and within seconds.
What is more, splitting at sentence level does not protect sensitive information. The sentence “Patient X. Y. was admitted on 12 March 2025 with a diagnosis of Z” is a complete personal data record in its own right. Fragmenting the text does not anonymise the data.
The one exception is segments that come back from the translation memory as high-rate matches: these are never sent to the engine at all. So in a document with a high repetition rate, the proportion of text that goes out falls. But this is not a safeguard designed for confidentiality; it is a side effect of an efficiency mechanism, and it cannot be relied on.
Is an in-house engine really the answer?
When data must not leave the premises at all, the first solution that comes to mind is to run the engine in-house. In theory it is flawless: the data never leaves the organisation’s network. In practice there are three cost items.
- Hardware. An engine that runs at a reasonable speed demands serious processing power; that investment can rarely be justified for small and medium-sized organisations.
- Maintenance. Model updates, security patches and monitoring call for a permanent technical team.
- Quality. In-house engines generally work with less data than the engines of the large providers. In relatively low-resource languages such as Turkish, that gap becomes pronounced.
Taken together, the total cost of these three items exceeds the annual translation budget of most organisations. That is why the fields in which in-house engines are common are narrow: the defence industry, the licensing files of pharmaceutical companies and the litigation documents of multinational law firms. What these fields have in common is that translation volume is high and the confidentiality threshold is strict; without one of the two, the investment cannot be justified.
An in-house engine therefore only makes sense in organisations where translation volume is very high and the confidentiality threshold is very strict (defence, pharmaceuticals, large law firms). For everyone else the more sensible route is not to use an engine at all: on a confidential document, human translation is both cheaper and safer than investing in in-house infrastructure.
Designing the workflow by document class
Laying down a single rule (“machine translation always on” or “always off”) is wasteful in both directions. The first puts confidential documents at risk; the second needlessly raises the cost of high-volume work to which there is no objection at all.
The arrangement that works is two separate workflows tied to the document class:
| Flow A – open content | Flow B – confidential content | |
|---|---|---|
| Machine translation | On (enterprise plan) | Off |
| Translation memory | Shared corporate memory | Project-specific, destroyed at the end |
| Processing location | Unrestricted | Domestic |
| Subcontractor | Subject to notification | Subject to approval or prohibited |
| Typical document | Catalogue, web content, manual | Contract, litigation file, personnel file |
The hardest part of setting this distinction up is not technical but administrative: defining who decides which flow a document goes to. If the deciding authority is unclear, in practice every document falls into the default flow, which is usually Flow A.
Why is machine translation weaker in Turkish?
Alongside the data security argument there is one more practical question: how much benefit do you get in return for the data you send to the engine? For Turkish in particular the answer is markedly lower than for pairs such as English-German. There are three structural reasons for this.
1. Data volume
Machine translation engines perform in direct proportion to the amount of parallel text they are trained on. For the English-French pair there are vast parallel corpora, such as decades of EU documents. For the Turkish-English pair that volume is far smaller; for pairs between Turkish and the other EU languages it shrinks further still, and engines frequently translate indirectly via English. Every indirect step adds fresh error.
2. Agglutinative structure
In Turkish a single word can stand for a whole sentence in English. The order of the suffixes determines the meaning, and the number of possible word forms is very high. This increases the likelihood that the engine will meet word forms it has never seen before, which is the known weak point of neural engines.
3. Free word order
In Turkish, emphasis is carried by word order. “Sözleşmeyi dün müdür imzaladı” and “Müdür sözleşmeyi dün imzaladı” convey the same information with a different emphasis. Machine translation usually flattens that difference in emphasis. In an everyday text the loss is trivial; in a legal text it can turn into a shift of meaning.
Conclusion and decision checklist: high risk, low benefit
When these three factors come together, an interesting equation emerges for official and legal texts in Turkish: machine translation is both riskier and less useful. You send the data out, but the draft you get in return does not meaningfully reduce the editing burden.
The area where machine translation genuinely helps in Turkish is technical texts with a high repetition rate and simple sentence structure: product descriptions, parts lists, standard operating instructions. In such texts there is usually no confidentiality problem either, so benefit and risk diverge in opposite directions. Once you see that divergence, deciding becomes easier.
If you are not sure which side your document falls on, ask us; we will work it out together.
Four questions are enough when you are deciding whether machine translation should be used on a document. If you can say “yes” to all four, the engine can stay on; if even one answer is “no”, it should be turned off.
- Is the document free of personal data?
- Does it carry no information subject to a confidentiality obligation?
- Is there no third party’s data in it?
- Is the text of the kind the engine handles well (repetitive, technical, simple sentences)?
The fourth question is the quality question and it is often skipped: leaving the engine on for a complex but non-confidential legal text creates no data risk, yet it costs time by increasing the editing burden.
These four questions need to be asked afresh on every project; a decision taken once should not be treated as automatically valid for the documents that follow. Because the settings persist across the whole tool, an engine left unchecked can stay on for months.
The Türkiye context
The servers of the widely used machine translation engines are outside Türkiye. Sending a segment containing personal data to an engine therefore counts as a transfer abroad under the KVKK. The fact that the transfer is “only one sentence” does not change the outcome.
Another Türkiye reality: in machine translation engines, Turkish is a language trained on less data than pairs such as English-German. Because of its agglutinative structure and free word order, output quality drops noticeably in official and legal texts. In Turkish documents, in other words, machine translation is both riskier and less useful.
What does this mean for you?
Four questions are enough when you talk to your translation supplier:
- Is machine translation being used on my project?
- Which provider, and which of their plans? Where are the servers?
- How long is the data that is sent retained?
- Can you turn the engine off, and will you confirm in writing that you have done so?
With us, machine translation is off by default on confidential projects, and that commitment is written into the contract. If you are not sure which class your document falls into, ask us; we will settle on the right workflow together.
Frequently asked questions
Is machine translation integration on by default?
In many translation tools, once an engine has been configured it runs automatically on every project. It can be turned off project by project, but that has to be done actively.
How long is the data sent to the engine retained?
It varies by provider and by plan. Enterprise API plans may carry a commitment to delete after processing; free and low-cost plans usually do not.
How can I tell whether a translation agency uses machine translation?
Ask directly, and have the answer written into the contract. On confidential projects, ask for a written undertaking that the engine has been turned off.
Does the price go up if machine translation is turned off?
With some providers it may, because editing after machine translation can move faster. On confidential documents, though, that difference is small set against the data risk.
Sources
- Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, pp. 22–25.
- Doherty, S. (2016). The Impact of Translation Technologies on the Process and Product of Translation. International Journal of Communication, 10, pp. 947–969.
This article is for general information only and is not legal advice; for current requirements, check official sources and, where necessary, a legal adviser.