What happens to your translation memory when you add AI to your workflow?
What happens to your translation memory when an AI translation workflow runs in front of your CAT tool, and how to keep your TM worth trusting.
A translation memory is the one asset in a CAT tool that stays yours. Engines get swapped, subscriptions lapse, tools go out of fashion. The TM survives all of it. So when a team puts an AI step in front of the CAT tool, the first question worth asking is not whether the output reads well. It is what happens to the translation memory when an AI translation workflow sits upstream of it, because that is the part that is hard to walk back. We have watched more than one agency work out, a year in, that its busiest memory had quietly turned into a record of unreviewed machine output with a human name attached.
Where translation memory fits in an AI translation workflow
Two orders make sense, and they leave you with different memories.
TM-first means you pre-translate from the memory, lock the exact matches, and send only what remains to the AI step. Everything the TM already knows stays untouched. The AI sees a thinner file and, if your setup passes any context at all, a worse one, because the segments it receives are the orphans sitting between locked rows.
AI-first means the whole document goes through the AI step and the memory is consulted afterwards, as reference during review or as a check that flags where the new translation disagrees with history.
Which one suits you depends on how much history you have. For a client you have served for six years, with forty thousand reviewed EN-DE segments behind you, TM-first is still the better order. The memory holds decisions nobody wants reopened: how the product tiers are named, whether the company address is translated, which of two legal phrasings their counsel accepted in 2021. For a one-off document from a new client, TM-first does almost nothing except slow you down and pull in matches from an unrelated domain.
The order also decides who wins a conflict. In TM-first, the memory wins by default and the AI never sees the segment. In AI-first, the AI wins unless a human notices. That default matters more than most teams realise when they set it up, because nobody goes back and revisits it. Write down which order each client sits in, and why, before the first project runs rather than after the third complaint.
What actually changes inside the TM
Here is the part that surprises people: nothing changes at all, until you write back. The damage is a policy problem, not a technical one.
Most CAT tools write confirmed segments to the memory automatically. That behaviour was designed for a world where confirming a segment meant a translator had read it and decided it was right. Run AI pre-translation into the same editor, let a post-editor move through the file at four thousand words an hour, and "confirmed" starts to mean something closer to "not obviously wrong at a glance".
One agency we worked with found this out the slow way. Their EN-DE memory had absorbed about a year of post-edited AI output, none of it marked as such. On a later project the analysis showed a healthy proportion of high fuzzy matches, and the reviewer did what reviewers do with a 98% match: skimmed it and moved on. A product name had been left in English in one early segment, and it propagated into roughly forty new ones before anyone queried it. The error was eleven months old. Nobody could say which project introduced it, because every segment carried a human user ID and no origin field.
The fix is unglamorous and it works. Use the fields your tool already has. Trados, memoQ and Phrase all let you attach custom metadata to memory entries, and all of them let you filter on it later. Record origin at minimum: human, AI post-edited, AI raw. Record review state if your process has one. A memory you can filter is a memory you can repair. A memory where every segment looks identical is one you will eventually stop trusting, and an untrusted TM is worth very little.
Fuzzy matches stop meaning what they used to
A 95% match used to carry an implicit guarantee. A human translator produced this sentence, a reviewer probably saw it, a client probably accepted it. The discount grid was built on that guarantee. You charged less for high matches because they needed less work.
Once AI output flows into the memory unmarked, the guarantee is gone and the grid measures something else. The match percentage still tells you how similar two strings are. It no longer tells you whether the stored translation was ever approved by a person.
This plays out in two directions and both cost money. Agencies keep quoting the old discounts on content that now needs full review, so margin leaks on every project. Clients, when they notice, start asking why they are paying anything for segments the machine produced on their own file last month. There is no neat answer to the second question yet. The honest version is that the work inside a high match has shifted from typing to verifying, and verifying unreviewed machine output takes longer than verifying a colleague's work.
None of this applies if your write-back policy is strict and only reviewed content reaches the master memory. In that case your match rates mean what they always meant and the grid still holds. Check rather than assume. Export a sample of your highest-value TM, filter by creation date against the month you introduced AI pre-translation, and read twenty segments from either side. We have done this with teams who were certain their memory was clean. Most of them were right. The ones who were not found out in under an hour, which is a cheap way to find out.
When the AI and the TM disagree
The AI step does not know your translation memory exists unless you tell it. That sounds obvious written down. In practice it produces a specific, repeatable failure that most QA profiles are blind to.
A freelancer we know keeps a legal EN-FR memory she has built over nine years. She started running AI pre-translation last spring on the long contracts, then post-editing in her CAT tool with the memory attached as reference. Her new-word count dropped, as expected. Her hourly output did not improve, which was not expected at all. What she was spending the time on was arbitration. The AI rendered a recurring clause one way, her memory rendered it another, both were defensible French, and she had to decide sentence by sentence which version this client's twelve previous documents had used. The QA profile flagged none of it, because nothing was wrong. It was only inconsistent with nine years of precedent.
The practical bridge is a glossary, not a bigger memory. Pull the terms that actually recur, feed them into the AI step as explicit instruction, and the arbitration load drops sharply. Terms, though, not phrasing. A glossary can fix what you call the thing. It cannot fix a preferred sentence structure or a register choice, and for those the TM stays the authority and the AI output stays a draft.
There is a limit here that is easy to miss. If the memory is small, or stale, or stitched together from several clients, the conflict may be the TM's fault rather than the AI's. Old memories accumulate decisions that were wrong when they were made and never got revisited. Letting AI output overwrite that is sometimes the right call. Segment by segment, though, never in bulk.
Moving AI output into your memory without locking yourself in
If the AI step happens outside your CAT tool, you have a transport problem: getting source and target back into the memory in a form your tool accepts.
TMX is the format built for exactly this. It is an XML standard for exchanging translation memories between tools, originally published by LISA and maintained under GALA stewardship since LISA closed in 2011. Every serious CAT tool imports it. If your AI step can emit TMX, that is the shortest path, and we have written separately about how TMX files move between CAT tools.
The more common reality is a bilingual table: source segment in one column, target in the next. Each tool gets there differently. memoQ imports delimited text into a memory directly. In Trados the usual route is to run the bilingual Excel through the built-in filter and update the memory from the finished file, or convert to TMX first. We have walked through the per-tool steps in our guide to importing a bilingual Excel file into Trados, memoQ and Phrase. The table route is less elegant than TMX and it has one real advantage: you can read it, sort it, and delete rows before anything touches your memory. For a first import from an unfamiliar tool we prefer the table every time. You will delete rows.
Whichever route you take, import into a project memory rather than the master, and promote later.
This is also where our own tool fits. SnapIntel takes a DOCX, XLSX or PPTX, runs a structured AI translation workflow in which you review and approve the glossary and the translation prompt before anything is translated, and returns the translated file along with a neutral source/target XLSX export and a QA report. That export is deliberately vendor-neutral: a plain bilingual table you can clean up and import into whichever CAT tool you already use. Nothing to install on the CAT tool side, and no dependency on a particular one.
A write-back policy you can enforce
Policies that depend on everyone remembering something do not survive a busy month. The ones that hold are built into the tool settings.
Two memories per client is the structure we see working best. A project memory, which everything writes to, no questions asked. A master memory, which only receives segments after review, through a deliberate promotion step at delivery. The promotion is a filtered export and import, it takes a few minutes, and it means the master never contains anything nobody read.
If you cannot run two memories, the fallback is penalties. memoQ and Trados both let you apply a match penalty by memory or by metadata, so AI-origin segments surface at, say, 90% instead of 99% and land in front of a human instead of under a lock. Cruder than separation, better than nothing.
Then there is the write-back setting itself. Turn off automatic write-back for machine-translated segments if your tool distinguishes them. Several do. Most teams never open that setting.
One more decision, less about tooling: what to do with raw AI output that a client signed off on but nobody post-edited. We have seen this argued both ways. Our position is that it goes in the project memory and never the master, because client sign-off on a delivered document is not the same as a linguist confirming a segment is safe to reuse in a different context next year. Reasonable people disagree. What matters is that your team makes the call once, in writing, instead of making it differently on every project.
Where to start if AI content is already in your memory
Assume it is. Most teams running AI pre-translation for more than a few months have unmarked machine output somewhere in their main memories, and the ones who are certain they do not are usually the ones who have not looked.
Start with the memory that earns the most: the biggest client, the one with the standing discount grid. Export it. Sort by creation date. Find the month AI pre-translation went live, pull thirty segments from after that date, and read them against the source properly, the way you would review a new translator's test. Within an hour you will know whether you have a problem and roughly how big it is.
If it comes back clean, write down what you did right and leave the other memories alone until you have a reason to look. If it does not, do not try to clean the whole thing. Split it at the date, keep the earlier portion as your trusted master, and treat everything after as a working memory that gets reviewed on contact. Repairing forty thousand segments by hand is not a project anyone finishes. Quarantining them is a project you can do on a Friday afternoon.
Then fix the write-back setting, before the next project starts. The cleanup is the expensive part. The setting that caused it takes two minutes.