The Chief Localization Officer of a global medical-device company had four localization-AI policies, which is another way of saying she had none. The pharma division had one, written by a compliance-minded director who forbade machine translation on anything that touched a patient, full stop, and quietly enforced it by refusing to enable MT in their instance of the translation-management system. The consumer-electronics division had a different one, an enthusiastic two-page memo that treated any large language model as fair game for any content, because their content was "just UI strings." The Japanese subsidiary had inherited a third from an acquisition, a beautifully formatted twelve-page document in a shared drive that nobody had opened since the acquisition closed. And the fourth policy, the one that actually governed most of the daily work, was unwritten: it lived in the habits of a few senior linguists and the reflexes of two project managers, and it changed every time one of them left. When a European regulator asked, during a routine audit, to see "the company's policy on the use of artificial intelligence in translating regulated content," the CLO could not produce a single document that was true across the company. She could produce four documents, three of which contradicted each other and one of which she had never read. The auditor did not need to find a shipped error to write a finding. The absence of one coherent, followed, enforceable policy was the finding. This lesson is about how you write the one policy that does not have that problem: a single enterprise localization-AI policy that holds across every content type, every language, and every engine, and that actually gets followed rather than admired, ignored, or contradicted.

What a Policy Is, and What It Is Not

Let us define the object precisely before we build it, because the word "policy" carries a lot of baggage and most of that baggage is what makes policies fail. A policy, in the localization-AI sense we mean here, is the enterprise's single authoritative set of standing rules for how machine translation and large language models may be used across all multilingual content, stated clearly enough that any person in the operation can read it and know what they are allowed to do, required to do, and forbidden to do, without asking anyone. It is not a strategy, which describes where the operation is going. It is not a set of guidelines, which suggests good practice and leaves compliance optional. It is not a training deck, which teaches. A policy tells you the rules, and it does so in a form that is enforceable, meaning there is a real consequence and ideally a real system control behind each rule, so that following it is the path of least resistance and breaking it is hard.

Two acronyms recur throughout, so we fix them once. MT is machine translation, the automated rendering of a source segment into a target language by an engine. LLM is a large language model, the general-purpose text engine that can translate, draft, and rewrite, and that is more fluent and more confidently wrong than classic MT. When this lesson says "engine," it means either. The TMS is the translation-management system, the platform that routes and tracks jobs; the CAT tool is the computer-assisted translation environment the linguist actually edits in; the TM is the translation memory, the store of previously approved translations; and MTPE is machine-translation post-editing, the workflow in which a human edits the engine's draft. We will define the more specialized terms, quality tier and MT-forbidden and governance, at the moment we first lean on them.

The distinction that matters most, and the one the four-policy company got wrong, is between a policy that exists and a policy that governs. A policy exists when it has been written and saved somewhere. A policy governs when it is singular (there is exactly one, and everyone knows which one), authoritative (someone with real power owns it and it overrides local habit), current (it reflects the engines and rules in force this quarter, not the ones from two years ago), and followed (the daily work actually conforms to it, because it is clear enough to follow and enforced enough that not following it is difficult). Most enterprise localization operations have several policies that exist and no policy that governs. The entire craft of this lesson is closing that gap.

A policy that merely exists is a document. A policy that governs is singular, authoritative, current, and followed. The four-policy company had four documents and zero governance, and the auditor recognized the difference on sight.

Why One Policy, and Not Many

It is tempting to let each division, each language team, each big client keep its own rules, because localization is genuinely heterogeneous and a rule that fits pharma package inserts seems absurd applied to marketing microcopy. Resist this. The heterogeneity is real, but the answer to it is one policy with tiers and content classes inside it, not many policies that each cover a slice. The reason is exactly what happened to the CLO: the moment you have more than one policy, you have contradiction, gaps, and unanswerable questions. A content type that lives between two divisions falls into the gap between two policies. A linguist who moves teams inherits a different rulebook. A client who buys services across divisions gets two different answers to the same question. And an auditor, a regulator, or your own leadership cannot get a straight answer to "what is your policy," because there isn't one, there are several, and they disagree. One policy is not a bureaucratic preference. It is the only structure that can be true across the whole operation at once, and being true across the whole operation is the entire point.

What the Policy Must Cover: The Seven Domains

A localization-AI policy that holds across content, languages, and engines has to answer a specific and knowable set of questions. Miss one and the gap becomes the place the operation gets hurt, because an unaddressed question does not stay unasked; it gets answered ad hoc by whoever hits it first, which is precisely the ungoverned state the policy exists to end. Seven domains form the mandatory coverage. We will walk each one slowly, because the difference between a policy that works and a policy that fails is almost always in how precisely these seven are written, not in whether they are mentioned.

Approved Engines and Approved Use

The policy must state which engines are approved, and for what. This is the domain a vague policy handles worst, because it is tempting to write "use approved engines" and leave the approved list somewhere else, or worse, to write nothing and let each team pick. The discipline is to make approval explicit and scoped. Approval is not a global blessing granted to an engine forever; it is a permission attached to a specific engine, for a specific class of content, valid until revoked. The same engine can be approved for high-volume marketing content and forbidden on regulated content in the same breath, because the axis that matters is not "is this engine good" but "is this engine good enough on this content given what a failure costs." The policy states the principle (only engines on the current approved list, used only within their approved content scope) and points to the living approved-engine list that the governance function maintains, so that the policy itself does not go stale every time an engine is added or a model regresses. Approved use also covers the mundane but consequential rules: whether linguists may paste source content into a public consumer LLM (almost always no, for confidentiality reasons we come to below), which internal or contracted engines are sanctioned, and whether an individual may reach for an unsanctioned tool "just to check something." The answer to that last one has to be explicit, because the informal shadow use of a convenient public chatbot is one of the most common ways confidential source content leaks out of an enterprise.

MT-Forbidden Content

The policy must name the content that the machine must never touch. MT-forbidden content, a category this program uses deliberately, is content that no engine may translate at all, not even as a draft that a human afterward post-edits, because the consequence of a fluent error in that content is a harm that no post-editing efficiency could ever justify risking. The canonical examples are the ones where a single flipped word is catastrophic: a drug dosage or a contraindication on a medical label, an indemnity or liability clause in a contract, a safety warning on industrial equipment, a financial disclosure where an inverted negation misstates a company's obligations. The reason MT-forbidden must be a named policy category rather than a matter of judgment is that the engine's danger here is precisely its fluency: it will produce a grammatical, confident, natural-sounding rendering of a contraindication that means the opposite of the source, and a post-editor skimming a smooth draft is more likely to miss that inversion than to catch it. Drawing this line is a risk judgment, and the policy must state both the line and how it is drawn, so that a new content type can be classified against a stated principle rather than a coin flip. The principle is consequence-based: content is MT-forbidden when a plausible fluent error in it could cause physical harm, legal liability, or regulatory violation that the operation is not willing to risk against any efficiency gain. Everything downstream of that principle, the specific list, gets maintained by governance, but the principle lives in the policy so the list is never arbitrary.

Quality Tiers and Gates

The policy must define the quality tiers and the gates that let content pass from one stage to delivery. A quality tier is a named level of translation quality with a defined production workflow and a defined guarantee attached, so that "high quality" stops being a feeling and becomes a specification. A workable enterprise tier ladder usually has four rungs: raw MT (engine output shipped with no human edit, appropriate only for the lowest-stakes, highest-volume, internally-consumed content), light post-editing (a human fixes only errors that impede understanding, leaving stylistic imperfection), full post-editing (a human brings the output to a quality indistinguishable from human translation, correcting every accuracy, terminology, and locale error), and full human translation (a professional translates from the source, with MT either absent or used only as a reference the human is free to discard). Each tier names its workflow and what it guarantees, and the policy ties each content class to a minimum tier, so that a content type cannot be quietly served at a cheaper tier than it warrants. The gate is the go/no-go checkpoint that decides whether output at a given tier may ship, and the policy must state the gate in absolute terms: output is scored against a defined error typology (the MQM-aligned Critical, Major, Minor severities that ISO 5060, the 2024 evaluation standard, formalizes), and a single Critical error fails the file regardless of how clean the average looks. That last rule, one Critical fails delivery, is the load-bearing sentence of the entire quality section, because it is the rule that a fluent, high-scoring, mostly-clean file cannot buy its way past on the strength of its average. Averages hide the single lethal error; the gate exists to catch it, and the policy must forbid ever averaging a Critical away under deadline pressure.

Terminology and Translation-Memory Rules

The policy must govern how approved terminology and translation memory are used and protected, because these linguistic assets are both the enterprise's competitive advantage and, if mishandled, its infection vector. The terminology rule has two halves. First, engines and post-editors must honor the client's or the enterprise's approved term, and where the engine drifts to a common synonym, the approved term wins; the policy states this and points to the requirement that engines be grounded on the current termbase so the approved language is fed to the engine rather than left to its preferences. Second, the termbase itself is a governed asset: it has an owner, a version, and an authority, and no one edits an approved term casually. The TM rule is a discipline of cleanliness. A translation memory compounds quality when it stores verified, approved translations, and it compounds error when it stores unverified machine output that then leverages into future projects as if it were trusted. The policy must therefore state which content may write back to the TM (verified, human-owned output only, never raw MT) so that the memory stays an asset rather than becoming a mechanism that propagates a single unverified error across a thousand future segments. This is one of the least glamorous domains and one of the most expensive to get wrong, because a poisoned TM does its damage silently and for years.

Data and Confidentiality

The policy must state what may be sent to which engine, and under what data terms, because the moment source content leaves the enterprise's controlled environment for an external engine, confidentiality becomes a live question. This domain covers several rules that a mature policy makes explicit. Which engines are approved from a data-handling standpoint, meaning their contracts and configurations guarantee that submitted content is not retained, not used to train the vendor's models, and not exposed. Whether confidential or personal-data-bearing content may be sent to an external engine at all, or must stay on engines that run inside the enterprise's own trust boundary. The absolute prohibition, in almost every enterprise, on pasting source content into a public consumer chatbot, because that content may be retained and is outside any contract. And the handling of personal data under the applicable privacy regimes, because a name, an address, or a medical detail in source content carries obligations that do not evaporate because the content is being translated. The confidentiality domain is where the localization policy meets the enterprise's broader security and privacy policy, and the localization policy's job is to translate those enterprise obligations into concrete engine-use rules a linguist can follow: this engine yes, that engine no, this content class never leaves the trust boundary, that content class may.

Human Accountability

The policy must state, without softening, that a human owns the quality of every shipped deliverable and that "the engine wrote it" is never an answer when an error ships. This is the cardinal rule of the whole discipline rendered as policy. Accountability does not transfer to the model, and it does not diffuse into the pipeline; it attaches to a named human role at the point of delivery, the post-editor, the reviewer, or the project manager who signs the file out. The policy states who that accountable human is for each tier and content class, and it states that the accountable human must hold the competence to own that content, which for regulated or high-liability content means a professional-translator-level linguist, in keeping with the revised ISO 18587, the post-editing standard whose current revision expands its scope to cover AI and LLM output and insists the post-editor hold full professional-translator competence. Writing accountability into the policy does two things. It removes the excuse, so no one can hide behind the engine when a Critical ships, and it removes the loneliness, so a linguist knows exactly what they are and are not accountable for and is not silently carrying a risk that the policy never named. A policy that assigns accountability clearly is fairer to its people, not just stricter, because ambiguity about who owns a shipped error is itself a form of injustice to whoever ends up blamed by default.

Incident Handling

The policy must state what happens when a Critical error ships or a near-miss is caught, because a policy that only describes the happy path is incomplete in exactly the place that matters most under pressure. Incident handling has a containment half and a learning half. Containment is the immediate response: how a shipped error is reported (and to whom), how the affected deliverable is corrected and the client notified, and how the operation stops the same error from shipping again while the root cause is investigated. The learning half is the review: a standing, blameless examination of what in the system allowed the error through, aimed not at the individual who shipped it but at the systemic gap, the engine that was unapproved for that content, the tier that was too low, the gate that missed it, the intake that mis-classified the content. The policy states that incident review feeds back into the policy itself, so that a shipped Critical becomes a policy change (an engine de-approved, a content type moved to MT-forbidden, a gate strengthened) rather than a one-time cleanup and a quiet hope it does not recur. A policy without an incident section teaches the operation, by omission, that incidents are to be handled informally and quietly, which is how an enterprise ends up with a pattern of silent Criticals that no one is officially learning from.

Seven domains, all mandatory: approved engines and use, MT-forbidden content, quality tiers and gates, terminology and TM rules, data and confidentiality, human accountability, and incident handling. A domain the policy leaves out is a question the operation will answer ad hoc, badly, under pressure.

How to Write a Policy People Actually Follow

Covering the seven domains gives you a complete policy. It does not give you a followed one. A policy can be complete, correct, and comprehensively ignored, and most enterprise policies are. The gap between a policy that is right and a policy that is followed is a craft problem, and it comes down to three properties that a followable policy has and an ignored one lacks: it is clear, it is enforceable, and it has an exception process. Miss any of the three and the completeness of your seven domains buys you nothing, because a policy nobody follows governs nothing.

Clear Enough to Follow Without Asking

The first property is clarity, and clarity has a precise operational test: a person in the operation should be able to read the relevant part of the policy and know what to do, without asking anyone and without interpreting. This sounds obvious and is routinely violated, because most policies are written to be defensible to a lawyer rather than actionable by a linguist. A policy that says "appropriate quality assurance measures shall be applied commensurate with content risk" is defensible and useless; the PM under a deadline cannot act on it, so they either guess or ignore it. A policy that says "pharmaceutical package inserts are MT-forbidden and must be assigned to full human translation by a linguist qualified in the relevant regulatory domain" is actionable, because the reader knows exactly what to do. The craft of clarity is to write every rule as an instruction to a specific reader in a specific situation, not as a principle a reader must then interpret. Name the content, name the tier, name the workflow, name the forbidden thing. Where a rule genuinely requires judgment, state the principle for the judgment and name who makes the call, so that even the judgment has an owner rather than a shrug. A policy is clear when a new PM on their first week can read it and route a job correctly, and it is unclear when routing a job correctly requires having been around long enough to absorb the unwritten rules, which is exactly the fragile, hero-dependent state the four-policy company was in.

Enforceable, Not Merely Stated

The second property is enforceability, and this is where good intentions go to die. A rule that depends on a tired person under deadline pressure remembering to do the right thing will be violated on exactly the day it matters most, because that is the day the pressure is highest and the memory least reliable. The strongest form of enforcement is a system control that makes the wrong thing impossible rather than merely discouraged: MT-forbidden content that the TMS structurally refuses to route to a machine workflow, unapproved engines that simply are not selectable in the tool for a given content class, a delivery gate wired into the pipeline so that a file with an unresolved Critical cannot be marked shippable. When the policy is built into the tools, following it becomes the path of least resistance and violating it requires actively circumventing a control, which most people will not do and which leaves a trace when they try. Where a system control is not possible, the enforcement falls back to process and audit: a required sign-off, a logged decision, a periodic check that the policy is actually being followed. The policy should state, for each major rule, how it is enforced, because a rule with no stated enforcement is a suggestion wearing a rule's clothes. The company that forbade MT in pharma by disabling it in the TMS had, without naming it, discovered the whole principle: enforcement in the system beats enforcement in the memo, every time.

The Exception Process That Saves the Policy

The third property is the one that counterintuitively determines whether a strict policy survives contact with reality: a real exception process. A policy with no way to grant an exception does not become more followed; it becomes routed around, because the moment a legitimate business need collides with an absolute rule and there is no sanctioned way to handle the collision, someone under pressure will simply violate the policy quietly, and now you have both a violation and no record of it. The paradox is that a well-designed exception process makes a policy more followed, not less, because it converts the inevitable edge case from a silent violation into a governed, recorded event. A working exception process states who can grant an exception (a named authority, usually the governance function or a senior executive, never the person requesting it), on what basis (a documented business justification and an explicit acceptance of the named risk), for how long (exceptions are time-bounded and expire, so they do not silently become permanent policy), and with what record (every exception is logged with who, what, why, and when, so the exception is visible and reviewable). The key design principle is that the exception is harder to get than compliance is to follow, so that the exception path is a real valve for genuine need and not a convenient bypass. An exception that a PM can grant themselves is not an exception process; it is the absence of a policy. An exception that requires a documented justification, a named senior sign-off, an accepted risk, and an expiry date is a governed release valve that keeps the policy whole by giving reality a legitimate place to go.

A followed policy is clear (actionable without interpretation), enforceable (built into the tools where possible, not left to memory), and exception-capable (a governed, recorded, time-bounded release valve). Miss clarity and people guess; miss enforcement and people forget; miss the exception process and people route around the whole thing.

The Length and Shape of a Followable Policy

A word on form, because form affects following. The twelve-page document nobody in the Japanese subsidiary had opened was not ignored because it was wrong; it was ignored because it was unusable. A followable enterprise localization-AI policy is short at its core and layered underneath. The core policy is a handful of pages that any person can read in one sitting: the seven domains stated as rules, the tiers defined, the accountability assigned, the exception process described. Underneath it sit the living operational artifacts the core policy points to, the approved-engine list, the MT-forbidden content list, the tier-to-content-class mapping, the termbase, and these change frequently and are maintained by governance without rewriting the policy every time. This layering is what lets the policy be both current and stable: the principles in the core change rarely, the lists underneath change often, and separating them means the policy stays true without constant re-signing and stays readable without drowning the reader in operational detail. A policy that tries to be both the enduring principle and the up-to-the-minute engine list in one document will be either perpetually out of date or so long no one reads it, and usually both.

Who Owns the Policy: Governance

A policy without an owner is an orphan, and orphaned policies go stale, contradict themselves, and eventually become the four-document mess we started with. The owner of a localization-AI policy is the governance function. Governance, in this sense, is the standing cross-functional authority that sets the policy, maintains the living lists beneath it, enforces its rules, and revises it as engines, clients, and risks change. The policy is the artifact; governance is the body that keeps the artifact true. This lesson is about the policy, and a companion concern is about standing up the governance body itself, so here we focus on the specific relationship between the two: what a policy needs from its owner to stay a governing policy rather than decaying into an existing one.

Governance gives the policy four things it cannot give itself. It gives the policy a single authoritative owner, so there is exactly one policy and one body empowered to change it, which is the structural cure for the four-policy disease. It gives the policy currency, by maintaining the living lists (approved engines, MT-forbidden content, tier mappings) so the policy reflects this quarter's reality rather than the reality of the day it was signed. It gives the policy enforcement teeth, by owning the system controls and the audit that make the rules real rather than aspirational. And it gives the policy a learning loop, by running incident review and feeding what it learns back into the policy, so a shipped Critical becomes a policy change rather than a quiet cleanup. A policy owned by a real governance function is alive; a policy owned by "the localization team" in the abstract, or by a director who wrote it once and moved on, is already dying, because no one is accountable for keeping it true.

The Seats That Make the Policy Correct

The reason governance must be cross-functional, and therefore the reason the policy it owns is correct, is that a localization-AI decision has multiple faces and no single discipline can see them all. Whether an engine is fit for a content class is simultaneously a quality question (its critical-error rate on real regulated content), a terminology question (whether it honors the approved termbase), an engineering question (whether it can be grounded and integrated safely), a data question (whether its contract protects confidential content), a commercial question (concentration risk from standardizing on one vendor), and a legal question (liability on regulated content). A policy written by any one of those seats alone will be expertly correct on one axis and blind on the others, which is how you get the enthusiastic consumer-electronics memo that treated any LLM as fair game because its author could see the throughput face of the decision and none of the risk faces. The policy is correct only when the body that owns it has a seat for each face: quality, terminology, engineering, data and security, project and account management, and, wherever regulated content is in scope, legal and compliance. The seats are not ceremony. Each one is the reason a particular domain of the policy is written well instead of written blind.

A Worked Policy Outline

Let us make all of this concrete by drafting the policy for the medical-device company from our opening, the one with four contradictory policies and an unimpressed auditor. The CLO decides she will replace the four with one, and she structures it so that it covers the seven domains, reads in a single sitting, is enforceable in the tools, and has a genuine exception valve. Here is the shape of the document she produces, section by section, so you can see how the principles above become an actual outline you could adapt.

Section 1: Purpose and Scope

The policy opens by stating, in two sentences, that it is the single authoritative rule for the use of MT and LLMs across all of the company's multilingual content in every division, language, and engine, and that it supersedes all prior division-level or subsidiary policies, which are hereby retired. That supersession clause is not a formality; it is the sentence that kills the four-policy problem outright, because without it the old documents keep half-living in shared drives and habits. Scope then names what the policy governs (all content translated or localized by or for the company, whether by internal teams or external vendors) and, just as importantly, what it does not govern, so that it neither overreaches into unrelated content nor leaves a gap a division can exploit. The scope explicitly binds vendors and language-service providers, because an enterprise policy that governs only internal work leaves the majority of many operations' content ungoverned.

Section 2: Approved Engines and Use

This section states the rule (only engines on the current approved-engine list may be used, and only within their approved content scope) and points to the living approved-engine list maintained by governance. It states the confidentiality-driven rules on engine use plainly: no source content may be entered into any public consumer LLM or unsanctioned tool; content may be sent only to engines whose data terms have been approved by governance; and confidential or personal-data-bearing content may be sent only to engines inside the company's trust boundary. It names the enforcement: the TMS presents only approved engines for each content class, and the approved-engine list is a governed artifact, not a per-team choice. In one page, the Monday-morning engine swap that started so much trouble in operations like this becomes impossible without going through governance.

Section 3: Content Classification and MT-Forbidden Content

This section defines the content classes the company works with and the risk principle that sorts them: content is classified by the consequence of a plausible fluent error in it. It states the MT-forbidden principle (content is MT-forbidden when a fluent error could cause physical harm, legal liability, or regulatory violation the company will not risk against any efficiency gain) and points to the living MT-forbidden list, which for this company includes pharmaceutical labeling and package inserts, medical-device instructions for use, safety warnings, indemnity and liability clauses, and financial disclosures. It names the enforcement that the four-policy company most conspicuously lacked: the TMS structurally refuses to route MT-forbidden content to any machine workflow, so a PM under deadline cannot make the Wednesday-afternoon routing mistake because the tool will not let them, warning is not enough, the action is blocked.

Section 4: Quality Tiers and the Delivery Gate

This section defines the four tiers (raw MT, light post-editing, full post-editing, full human translation), states what each guarantees and what workflow produces it, and maps each content class to a minimum tier so content cannot be quietly under-served. It defines the delivery gate in absolute terms: output is scored against the ISO 5060 Critical, Major, Minor typology, and a single Critical error fails the file and blocks delivery regardless of the average score. It states that the gate is identical across every division, language, and client, because a gate that means different things in different places is not a gate, and it names the enforcement: the gate is wired into the pipeline so a file with an unresolved Critical cannot be marked shippable. This is the section that makes the company's quality promise a specification rather than a hope.

Section 5: Terminology, Translation Memory, and Data

This section states the terminology rule (approved terms win over engine preference; engines are grounded on the current termbase; the termbase is a governed, versioned, owned asset) and the TM rule (only verified, human-owned output writes back to the translation memory; raw MT never does, so the memory does not become a propagation vector for unverified errors). It consolidates the data and confidentiality rules that Section 2 introduced, tying them to the company's enterprise privacy and security obligations and translating those obligations into concrete, followable engine-use rules. It names the enforcement where it exists: grounding is a configured requirement in the pipeline, and TM write-back permissions are set by content class rather than left to individual choice.

Section 6: Human Accountability and Incident Handling

This section states the cardinal rule as policy: a named human owns the quality of every shipped deliverable, and the engine is never the answer when an error ships. It assigns the accountable role for each tier and content class, and it requires that the accountable human for regulated and high-liability content hold professional-translator competence, in keeping with the revised ISO 18587. It then states the incident process: how a shipped Critical or near-miss is reported and contained, how the client is notified and the deliverable corrected, and how a blameless review examines the systemic cause and feeds a policy change back in. It states plainly that incident review is not about punishing the individual but about closing the gap in the system, because a policy that lets incidents become blame exercises teaches people to hide them, and hidden incidents are how an enterprise accumulates silent Criticals it never learns from.

Section 7: The Exception Process

The final section is the release valve that keeps the whole policy whole. It states who may grant an exception (the governance function, or a named senior executive for urgent cases, never the requester), on what basis (a written business justification and an explicit acceptance of the named risk, signed by an authority senior enough to own that risk), for how long (every exception is time-bounded and expires, so it cannot silently become permanent policy), and with what record (every exception is logged with who requested it, what was granted, why, the risk accepted, and the expiry date). It states the design principle out loud: an exception is deliberately harder to obtain than compliance is to follow, so the valve serves genuine need without becoming a convenient bypass. This section is what turns the inevitable hard case from a silent violation into a governed event, and it is the difference between a strict policy that gets followed and a strict policy that gets routed around until it is a dead letter.

What the One Policy Lets the CLO Say

When the auditor returns, the CLO produces one document. It is true across every division, language, and engine. It supersedes the four old policies, which are formally retired. Its rules are clear enough that a first-week PM can follow them, enforced in the TMS so that MT-forbidden content structurally cannot reach a machine and unapproved engines cannot be selected, and equipped with an exception process so that the genuine edge case is a recorded, governed event rather than a silent breach. The auditor asks who decided that pharmaceutical inserts are MT-forbidden, and the answer is a dated, attributed decision by a named governance body, not a linguist's recollection. The auditor asks how the company prevents confidential content reaching a public chatbot, and the answer is a stated rule enforced by an engine allow-list in the tool. The auditor asks what happens when a Critical ships, and the answer is a written incident process with a learning loop. None of these answers existed a year earlier, when the company had four policies and therefore none. The finding is closed, but the deeper win is quieter: the operation now has one true thing to point to, and the people in it are no longer each privately carrying a rule that was never written down and never theirs to carry alone.

Key Takeaways

• One policy, or none. A policy that governs is singular, authoritative, current, and followed; the moment an enterprise has several policies (one per division, per client, per subsidiary) it has contradiction, gaps, and no straight answer to "what is your policy." The four-policy company had four documents and zero governance, and the auditor recognized the difference on sight.
• The policy must cover seven domains, all mandatory. Approved engines and use, MT-forbidden content, quality tiers and gates, terminology and TM rules, data and confidentiality, human accountability, and incident handling. A domain left out is a question the operation answers ad hoc, badly, under pressure, which is exactly the ungoverned state the policy exists to end.
• MT-forbidden is a named category drawn on consequence. Content is MT-forbidden (no engine touches it, not even as a draft to post-edit) when a plausible fluent error could cause physical harm, legal liability, or regulatory violation the operation will not risk against any efficiency. The policy states the principle; governance maintains the list, so the list is never arbitrary.
• A quality tier is a specification, not a feeling. Name the tiers (raw MT, light PE, full PE, full human), state what each guarantees and produces, map each content class to a minimum tier, and define the gate absolutely: scored against the ISO 5060 Critical, Major, Minor typology, one Critical fails the file regardless of the average, identical across every division and client.
• A followed policy is clear, enforceable, and exception-capable. Clear means actionable without interpretation (name the content, the tier, the workflow, the forbidden thing). Enforceable means built into the tools where possible (the TMS blocks MT-forbidden content, unapproved engines are unselectable, the gate blocks a Critical), not left to a tired person's memory under deadline.
• The exception process is what keeps a strict policy alive. A policy with no sanctioned exception gets routed around silently; a governed exception valve (named senior grantor, written justification, accepted risk, time-bounded, logged) converts the inevitable edge case from a silent violation into a recorded event, and is deliberately harder to obtain than compliance is to follow.
• Accountability is human, named, and competent. A named human owns the quality of every shipped deliverable and "the engine wrote it" is never an answer; for regulated content that human holds professional-translator competence, in keeping with the revised ISO 18587. Assigning accountability clearly is fairer to people, not just stricter, because ambiguity about who owns a shipped error is its own injustice.
• Governance owns the policy, and its cross-functional seats make it correct. A localization-AI decision has quality, terminology, engineering, data, commercial, and legal faces; a policy written by one seat is expert on one axis and blind on the rest. Governance gives the policy a single owner, currency (living lists beneath a stable core), enforcement teeth, and a learning loop from incident review, keeping it a governing policy rather than an existing one.