AI Detection Translated Text: Why Your Human Translation Flags
By DeAIze Team · ·2266 words
A client ran your human translation through an AI detector and it came back flagged. You did the work yourself. So why does AI detection translated text trip the tool, and what do you actually hand the client now? The answer sits in the difference between translation artefacts and generation signals, and in how you document the work you did.
Key takeaways
- Translation produces parallel structure, calques and consistent register. Detectors read those same patterns as machine generation.
- A translation pattern comes from the source text. A generation pattern comes from a model predicting likely next words. They look similar on the surface and differ underneath.
- Document the translation with CAT tool logs, revision history and translator notes before the client asks.
- A detector score is a probability estimate, not proof of authorship. Say that plainly, without sounding defensive.
- Push back when the flag contradicts documented process. Adjust your delivery format when the flag is really about readability.
- Our own measurement on 2026-09-19 found a human-written sample of 46 DeAIze guides scored a mean of 27% AI, with 17 of 46 flagged at a 30% threshold. Human text flags too.
Why does my translation show as AI?
Because translation and generation leave overlapping fingerprints. A detector does not read meaning. It measures surface statistics: how predictable each word is given the words before it, how much sentence length varies, how often the same syntactic shape repeats.
A translator working from a source text inherits the source’s rhythm. If the German original uses long subordinate clauses, the English version carries that shape. If the French uses nominalisations, the English version leans nominal. You did not choose those patterns freely. The source did. But a detector sees low variance and consistent structure and reads it the same way it reads model output.
Add the ordinary constraints of professional translation and the overlap grows. Terminology stays consistent across a document because it must. Register stays flat because the brief says so. Sentence openings repeat because the source repeats them. Every one of those is a mark of care. Every one of them also raises an AI score.
Our own measurement makes the point from the other direction. On 2026-09-19 we scored 46 hand-written DeAIze guides with the DeAIze detector at a 30% flag threshold. The mean AI score was 27%, the median 25%, and the range ran from 0 to 55. Seventeen of the 46 were flagged. Those are human-written guides about AI detection, written by people who know the tells. Human text lands in the same band as machine text often enough that a single flag proves very little.
Translation artefacts versus generation signals
This is the distinction that wins the client conversation, so it is worth being precise about it.
A translation artefact is a trace of the transfer process. It comes from the source language, the domain convention, or the translator’s decision to preserve meaning at the cost of natural rhythm. Examples: a calque that keeps the source’s preposition, a passive construction that exists because the source used one, a term repeated verbatim because the glossary says so.
A generation signal is a trace of next-token prediction. It comes from a model choosing the most probable continuation. Examples: a paragraph that opens with a definition and closes with a summary, a list of three items that all have the same grammatical shape, a transition phrase that adds nothing.
The two can look identical in a single sentence. They diverge when you look at the document as a whole.
| Signal | Typical in translation | Typical in generation | How to tell them apart |
|---|---|---|---|
| Parallel structure | Yes, inherited from source syntax | Yes, from template-like output | Check the source: does the parallelism exist there? |
| Consistent register | Yes, required by brief and glossary | Yes, from uniform model voice | Ask whether the brief demanded it |
| Repeated terminology | Yes, glossary and TM driven | Sometimes, from low lexical variety | Check the termbase and TM matches |
| Flat sentence length | Common in technical translation | Common in unedited model output | Compare against your own earlier work in the same pair |
| Generic transitions | Occasional, from source connectives | Frequent, from discourse templates | Count how many transitions carry no new information |
| Named entities, dates, figures | Dense and specific | Often vague or absent | Translation preserves facts; generation sometimes invents them |
That last row is the strongest discriminator you have. A translation carries the source’s specifics: names, numbers, dates, product codes. Unedited model output tends to hedge or invent. If your document is dense with verifiable specifics, that is evidence, and it is evidence a client can check without trusting you.
We also counted AI-tell frequency in the same 2026-09-19 run: 3 per 100 words in the human sample versus 1 per 100 words in the unedited model output. That is worth sitting with. The human-written guides contained more surface tells than the raw model text. Tell-counting is not a reliable authorship test, which is exactly why a flagged translation is not a verdict.
If you want to see which specific sentences carry the signal rather than arguing about a single document score, run the translation through the DeAIze AI detector — it scores the whole file and highlights each sentence by AI probability, so you can point the client at the lines in question.
Why does a detector treat translated text differently from native writing?
Three mechanisms do most of the work.
Predictability. Detectors estimate how surprising each word is in context. High-frequency words in high-probability positions lower that surprise. Translation into a second language often lands on the standard rendering rather than the idiomatic one, and the standard rendering is, by definition, the predictable one. Native writing in the same genre drifts more.
Burstiness. Human writing varies sentence length and structure unevenly. Translation smooths that variation because the source’s rhythm is imposed on top of the translator’s. The result reads steady, and steady reads machine-made to a detector tuned on unedited model output.
Register uniformity. A model writes the whole document in one voice. A translator does too, when the brief calls for it. The detector cannot tell why the voice is uniform, only that it is.
None of this means the detector is broken. It means the detector measures a proxy, and translation produces the proxy without producing the thing the proxy stands for.
How do you document a human translation?
The documentation is your case. Build it during the job, not after the flag.
- Export the CAT tool log. Most CAT environments record segment timestamps, edit history and match statistics. A log showing segments typed over hours, with fuzzy matches from your own TM, is process evidence. Save it as a file alongside the delivery.
- Keep the revision history. If a second translator or a reviewer touched the file, keep the tracked changes and the review notes. Two sets of human edits on the same segment is a pattern no model produces.
- Write translator notes for anything contested. A short note explaining that a construction is a deliberate calque because the client’s style guide requires source fidelity is worth more than a paragraph of denial. Keep it factual and specific to the segment.
- Preserve the source and the reference material. The source file, the glossary, the TM export. These let a client verify independently that the English follows the German, or the Japanese, rather than a model’s guess.
- Record your queries. If you asked the client about an ambiguous term, keep the email. That exchange is dated, human and specific.
If you want the general shape of a documentation pack, the workflow in AI Detection Take Home Assignment: What to Document maps closely onto translation work: timestamps, drafts, notes, and a short written rationale.
How do you talk to a client who trusts the detector score?
The client is not being unreasonable. They paid for original work and a tool told them it might not be original. Your job is to move the conversation from the score to the process, without dismissing the tool.
Start by agreeing on what the score is. A detector output is a probability estimate, not proof of authorship. Most tools say so in their own documentation. You are not asking the client to distrust the detector. You are asking them to treat it as one signal among several.
Then hand over the process evidence. Not a defence. A folder. The CAT log, the revision history, the notes, the source, the termbase. Let the client draw the conclusion.
Then offer the sentence-level view. A whole-document score invites an argument about the document. A sentence-level breakdown invites a conversation about specific lines, and specific lines are where you can explain each choice. If the client wants to see it themselves, point them at a tool that reports per-sentence probability rather than a single figure.
Finally, be honest about the limit. You cannot promise a particular score on any detector. Nobody can, because the models behind those scores change without notice and none of them publish a stable threshold. What you can promise is a documented process and a willingness to discuss any segment.
When should you push back, and when should you adjust?
Push back when the flag contradicts documented process. If you have a CAT log, a revision history and a source text that explains every flagged construction, you have a stronger case than the score does. Hold your ground, politely, and put it in writing.
Adjust when the flag is really a readability complaint wearing a detector’s clothes. Sometimes a client flags a translation as AI because it reads flat, and the flatness is a genuine quality issue. Calques that preserve source syntax at the cost of English idiom are defensible in a legal text and indefensible in marketing copy. If the client’s real objection is that the target text reads like a translation, that is fixable work, and fixing it will usually lower the score as a side effect.
A middle path: deliver the faithful version plus a lightly naturalised variant for the segments the client cares about. You keep the source-fidelity argument intact and give the client something to approve.
What do you do when the flag is on your own English?
Translators who work into a second language face a second layer of this problem. Their own prose carries the same markers that get non-native writers flagged, and those markers stack on top of the translation artefacts. The patterns are well documented in Why an AI Detector Flags Non Native English Writers, and the practical response is the same: document more, and edit for idiomatic variation in the segments that will be read closely.
If you are cleaning up a draft that genuinely had machine help in it — a first pass through a machine translation engine, for instance — that is a different situation, and it needs a different answer. You would be looking at Translated Text AI Detection: Spot MT Artifacts Before Detectors Do rather than a process defence.
A short worked example
Illustration only. Suppose the source German sentence runs long and stacks three subordinate clauses. A faithful English rendering keeps all three, uses one passive, repeats a noun rather than a pronoun, and opens with a prepositional phrase. A detector may mark that sentence as high-probability AI.
A naturalised rendering splits it into two sentences, promotes the agent to subject, and swaps the repeated noun for a pronoun. The score on that sentence typically falls.
Neither version is wrong. The first is what the brief asked for. The second is what the detector prefers. Knowing which one you delivered, and why, is the whole conversation.
What a detector score can and cannot tell a client
A score cannot tell a client who wrote a sentence. It can tell them that a sentence resembles the statistical profile of unedited model output. Those are different claims, and conflating them is how good translators end up defending work they did by hand.
What a score can do is start a review. If a client treats it that way — a triage signal that says “look at these lines” — the tool is useful. If they treat it as a verdict, the tool is doing something it was never designed to do. For a longer treatment of that gap, see How AI Detection Works: The Signals Behind the Score.
Ready to see which sentences read machine-made?
When a client sends back a flagged translation, the fastest way to move the conversation is to show them the lines. Paste the file into the DeAIze AI detector and you get a document score plus a per-sentence AI probability, so you can walk through each flagged segment and explain the choice behind it.
If the flag lands on segments you want to soften rather than defend, the humanizer rewrites only the flagged sentences, checks that the meaning survived, then re-scores and reports before and after. It is built for your own drafts. It is not a way to pass off someone else’s work.
You can try it on 200 words at signup with no credit card. When you are ready to run a full job, pricing is pay-as-you-go, credits never expire, and there is no subscription. Word documents keep their fonts, styles and tables through the rewrite, which matters when the deliverable is a formatted file rather than plain text.
One last thing, because it is the part clients ask about: text you paste is processed for the current task only. It is not used for training and it is not resold. If a client wants that in writing before they will let a file near a tool, the FAQ covers it.
Part of our guide to ai detector.
Want to clean up a machine-made draft?
200 free words once you confirm your email — check, rewrite, read it back.
Get started freeRelated reading
Best AI Detector for Teachers: What to Evaluate Before Buying Seats
A school buyer's checklist for AI detectors: false positives on non-native writers, sentence-level reporting, appeal workflow, cost per student and staff training.
AI Detectors Penalise Non Native Writers: What to Document
Why AI detectors penalise non native writers, how to raise a false positive with your institution calmly, and how to edit without erasing your own syntax.
Claude Watermark Punishes the Wrong People: What to Do Now
The Claude watermark story is hitting careful non-native writers hardest. What changed, who it affects, and the editing fix that actually helps.
Frequently Asked Questions
Why does my human translation show as AI?
Translation inherits the source text's rhythm, so sentence length, structure and register stay unusually even. Detectors read that evenness as machine generation, because unedited model output looks the same way. Consistent terminology and a fixed register add to the effect. The work is human; the surface statistics just overlap with what the detector was trained to flag.
Is AI detection translated text reliable evidence of machine translation?
No. A detector score is a probability estimate, not proof of authorship, and no tool publishes a stable threshold. In our own measurement on 2026-09-19, 17 of 46 hand-written guides were flagged at a 30% threshold. Human text flags regularly, so a single score cannot establish that a translation came from a machine.
How do I prove a human translation to a client?
Build the evidence during the job. Export the CAT tool log with segment timestamps, keep the revision history and tracked changes, write short notes on any contested segment, and preserve the source file, glossary and TM export. A folder of process evidence is far more persuasive than an argument about the score.
Should I rewrite a translation just to lower the detector score?
Only when the underlying complaint is readability. If the client's real objection is that the target text reads flat, naturalising the flagged sentences is legitimate work and the score usually falls as a side effect. If the flag contradicts a documented, brief-compliant process, push back instead of degrading a faithful translation.