An AI translation policy for game studios: the decisions to write down

Somewhere in your pipeline, machine output is already in use. A designer pastes a line into a chat assistant to get a rough English version for a pitch deck. A community manager translates a reply to a player. A vendor's linguist runs a segment through a tool before editing it. None of that is automatically wrong, but if none of it is written down, your studio has an AI translation policy anyway — an accidental one, set by whoever was most rushed on a given afternoon.

The useful question for a studio is not whether AI translation is good or bad. It is narrower and more answerable: where is it allowed, what text is permitted to leave the building, what do you require your vendors to disclose, and who is accountable when something ships wrong in a language nobody at the studio reads.

What follows is a set of decisions to settle, not a position to adopt. Studios reasonably land in different places on each of them, and a policy that reflects an actual decision beats a stricter one that everybody routes around.

Tier your text before deciding anything

A blanket yes or no fails because the risk is not uniform. The same tool that is obviously fine for understanding a bug report is obviously not fine for a refund policy. Sorting your text into tiers first turns an argument about technology into a series of small, decidable questions.

• Internal and disposable: design notes, placeholder text, reading a bug report someone filed in a language you do not speak. Low risk, and a blanket allow here removes a lot of pointless friction
• Player-facing but cheap to correct: patch notes, social posts, community replies. Machine output with a human read before sending is a defensible default; mistakes are fixable within minutes
• Shipped in the build: UI, systems text, item and tutorial strings. Correctable only by patch, visible to every player in that language, and quoted back at you in reviews
• Narrative and character voice: the part players judge a localization by, and where machine output degrades most quietly — fluent, plausible, and wrong about who is speaking
• Legal, safety, monetization, and store text: terms, privacy notices, age rating questionnaires, purchase and refund flows, anything a platform holder or regulator reads. Errors here are compliance problems rather than quality problems

Most workable policies come out looking like this:

  internal / disposable        -> allowed, no review required
  cheap to correct             -> allowed, human read before publishing
  shipped in the build         -> qualified human author, machine draft optional
  narrative and character voice-> qualified human author, machine draft discouraged
  legal / safety / store       -> qualified human author plus legal review

What text is allowed to leave the building

Unreleased game text is often the studio's most sensitive material: plot, character names, unannounced features, collaboration partners, and dates. Pasting it into a consumer chat tool is a disclosure decision, and it is usually made by someone who did not realise they were making one.

The questions a policy has to answer are concrete. Which services are approved. Whether inputs are used for training under the specific plan you are on, since consumer and business tiers frequently differ on exactly this point. How long inputs are retained and where they are processed. Whether the account is company-administered or someone's personal login, which also determines whether access can be revoked when they leave.

Layered on top of that are obligations you already have. Platform holders and publishing partners impose confidentiality terms that predate any of this, and those terms do not contain an exception for convenient tools. If you are under an embargo, a paste is a transmission.

The practical control is not a ban. Bans without a sanctioned path produce shadow usage you cannot see, which is strictly worse than usage you can. What works is one or two approved, paid, company-administered options, plus a plain statement of which text tiers may be put into them — and an explicit line for the material that goes into none of them.

What you require from vendors

Your policy stops at your own staff unless the contract carries it outward. Vendors and their subcontractors handle the same text under their own norms, and a studio that has carefully controlled internal usage while asking nothing of its suppliers has controlled a small fraction of the exposure.

• Disclosure of whether machine translation or AI is used at any step, and specifically which step
• Honest pricing: post-edited machine output is priced as post-editing, not as from-scratch human translation
• A named process for editing: who edits, what their brief is, and what they are expected to catch
• Flow-down of confidentiality to their subcontractors and to the tools those subcontractors use
• A statement on whether your text is used to train any model, theirs or a third party's
• How machine-drafted segments are marked in the translation memory they hand back, so unedited output does not silently become your reference material for years

The check is the policy

A policy that permits machine assistance anywhere is only as strong as the verification behind it, because the failure mode is not obvious nonsense. It is fluent, confident text that is wrong in a specific quiet way: a dropped placeholder, a term rendered three different ways across a menu, a negation that flipped, a line that reads beautifully and says the opposite of the source.

Split verification into the mechanical and the human, because they scale differently. Mechanical checks — placeholders present and well formed, no untranslated or empty entries, markup tags balanced, length within the field's limit, terminology matching the glossary — apply to every line of every language on every build, and their cost does not rise with volume. There is no reason to spend a native speaker's hour on something a check can catch first.

Human review is the scarce resource, so define its scope explicitly rather than leaving it as an intention. Which tiers get a full read by a qualified speaker, at what point in the schedule, and what happens when the schedule slips. An undefined scope becomes whatever fits in the time left, which on a bad month is nothing.

Then name someone. Sign-off per language per release should belong to a person, recorded, not to a team. Diffusion of responsibility is the most reliable way for unreviewed output to reach players: everyone assumed the check happened somewhere upstream.

Finally, keep a record of how text was produced. When a player reports an error six months later, the question you will want to answer is whether it is an isolated mistake or a symptom of a category that was drafted one way and never fully reviewed. You can only answer that if you wrote it down at the time.

Credit, disclosure, and what players see

Storefronts have added disclosure fields about AI usage to their submission processes, and the specific wording and scope of those requirements have changed more than once. Check the current rules of each storefront you ship on rather than relying on what was true at your last release, and make that check part of your submission checklist rather than someone's memory.

Independently of what is required, decide what you will say. Player communities in several languages react strongly to translations they perceive as machine-produced, and the reaction is almost always triggered by the quality of the result first. A studio that ships good text and is straightforward about its process tends to fare better than one that ships weak text and says nothing, whichever tools either of them used.

Credit the humans. Translators and LQA testers going uncredited is a long-standing grievance in this industry, and it lands harder when a studio is public about its tooling and silent about its people. If a language was translated by a named person, name them.

For support and community work, decide whether machine-assisted replies are labelled, and set a hard exception: nothing machine-drafted goes out unreviewed on a topic where being wrong has consequences. Refunds, account access, purchases, and safety reports are not places to save a few minutes.

Write it on one page and give it an owner

A policy nobody can find at midnight before a submission deadline is not a policy. One page, in the same place as the rest of the team's working agreements, phrased so a new contractor can follow it on their first day without asking anyone.

Two things matter more than the rules themselves. The first is an exception process: without one, the first genuine emergency establishes a precedent set by whoever was awake, and that precedent outlives the emergency. Name an approver, require the exception in writing, time-box it, and review it afterwards. The second is a review date. Tooling, storefront requirements, vendor practice, and audience expectations have all shifted inside single release cycles, and a policy with no expiry quietly becomes a description of the past.

AI translation policy - <studio> - reviewed YYYY-MM - owner: <name>

1. Tiers
   No review required     : internal notes, understanding inbound bug reports
   Human read before send : patch notes, social posts, community replies
   Qualified human author : in-build UI, systems, and narrative text
   Author plus legal review: terms, privacy, store text, age rating, purchase flows
2. Approved tools
   Company-administered accounts only. No personal accounts, no personal keys.
   Unreleased content: approved tool A only, never in any unapproved service.
3. Vendors
   Must disclose AI or MT use per step. Post-edited output priced as post-editing.
   Confidentiality flows down to subcontractors and their tools.
   Machine-drafted segments marked in any translation memory handed back.
4. Before ship
   Mechanical checks on every line, every language, every build.
   Human read of in-build text by a qualified speaker, per language.
5. Sign-off
   Named owner per language, recorded per release.
6. Exceptions
   Approver: <role>. In writing, time-boxed, reviewed at the retrospective.