AI translation at work: when it’s good enough and when it isn’t.

A buyer pastes a supplier’s English email into a translation tool and understands it in seconds. A colleague does the same with an annex to the supplier contract and sends the Turkish text for signature. Same tool, same fluent output, very different risk.

AI translation is good enough for understanding and internal drafts. It is risky for contracts, regulated text and anything published under your name without review. The difference isn’t made by the tool but by three rules: a glossary, a qualified reviewer for high-stakes text, and a clear rule on what may be sent where.

Where is AI translation good enough?

Wherever a mistake is cheap and visible: reading a supplier’s email, a report from a foreign subsidiary, a colleague’s message in the other language. The reader needs the gist, and anything unclear can be asked. Label machine-translated text as such, so nobody quotes it as the original.

Decide by what a mistake would cost:

The default, when a text fits no row: if it leaves the company under your name or can bind you, a qualified person reviews it before it goes.

Where does it need a human translator or reviewer?

Wherever errors hide in fluent text. The failures that matter are small: a dropped negation, and in Turkish negation is a single syllable inside the verb (“ödenecektir”, will be paid; “ödenmeyecektir”, will not be paid). A number or date reformatted wrongly. An obligation that changes strength. A sentence left out.

The better a translation reads, the less anyone checks it.

Consider an illustrative case. A supplier sends a letter announcing a price change, with an annex amending the supply contract. The buyer runs both through the approved tool. The letter’s Turkish translation is fine as it is: the team needs to understand it, and a follow-up question costs nothing. The annex is different, because its Turkish version will be signed. The machine translation renders “commercially reasonable efforts” as something closer to a firm obligation, and drops a sentence about notice. It goes to a bilingual lawyer, who compares the versions clause by clause, and nothing is signed until the reviewed text is back.

How do glossaries and style rules help?

A glossary fixes the words that must not drift. It lists product and brand names never to translate, legal terms with the rendering your legal team chose (is “cezai şart” a “contractual penalty” or a “penalty clause”?), and false friends: “aktüel” means current, not actual, and “kontrol etmek” usually means to check, not to control.

Enforce it twice. Give the model the glossary entries that apply to each text, and check the output automatically: every glossary term rendered as approved, every protected name untouched, every number and date matching the source. Style rules belong in the same file: “siz” or “sen”, number formats (12.500,00 or 12,500.00) and units. Give the glossary an owner, or it goes stale.

What data should never go to a public translation tool?

Confidential documents go only through tools the company has approved: contracts, personal data such as HR files and customer complaints, unpublished financials, deal documents and source code. Public and consumer translation services may keep or reuse what is pasted into them, depending on their terms, so the approved tool, under an agreement your IT and legal teams have checked, is the only route. A short list of what may go where, like the traffic-light table in an AI acceptable use policy, does more than a long warning. Whether sending a document to a provider abroad counts as a data transfer is a question for your data protection officer.

When should you write natively instead of translating?

When the effect matters more than the words. Marketing and search pages should be written natively in each language: people search in their own words, so keywords are researched per language, not translated, and idiom, humor and rhythm rarely survive translation. Customer replies work better drafted directly in the customer’s language from the facts than translated from an English draft. AI can help native writers with drafts and variations; a native writer owns what is published.

How do you check translation quality?

Test tools on your own texts before approving one: a few dozen real documents per text type, with translations your reviewers accept. Bilingual reviewers score each candidate with a short error checklist: meaning (additions, omissions, negations), numbers, dates and names, glossary terms, register and fluency. Automate what can be counted, such as numbers and dates that match the source, glossary terms, protected names and missing sentences. Back-translation, translating the output back to compare, catches gross errors and misses subtle ones, so don’t rely on it alone. In daily use, review every contract, a sample of customer replies and spot checks of the rest, and track which error types recur.

Start with the table

List the text types your teams translate and put each into a row of the table. Then build a glossary from the few dozen terms that matter most, and make sure everyone knows which tool is approved. Teaching people when machine translation is enough is part of AI enablement; searching and answering across languages in your own documents is knowledge and document intelligence work, covered in more depth in designing AI for teams that work in Turkish and English.

This note is general information, not legal advice.