Every Head of Content has sat through the same vendor pitch by now: AI has made translation instant, near-free, and good enough that human review is a legacy cost center. Then the same person sits through a different meeting, legal asking why a contract clause shipped with a mistranslated liability term, brand asking why the German homepage reads like a machine wrote it because a machine did, and the instant-and-free story stops holding up.
Both things are true at once. Machine translation quality has genuinely jumped. A translated string is not automatically a governed, on-brand, publishable asset. Those are different claims. The real question a content leader has to answer is where, in an otherwise automated pipeline, human judgment needs to enter, how often, and how you would know if that calibration was wrong. That is a governance design problem, not a vendor selection problem, and it is the one this piece is about.
Three paths, and the risk question that picks among them
Enterprise content is not one thing, and it should not get one localization path. In practice there are three.
AI-only: No human touches the output before it ships. Appropriate for high-volume, low-liability content where a translation error costs a re-render, not a lawsuit, internal documentation, product catalog descriptions, UI microcopy in mature markets, help-center articles that get revised constantly.
AI-plus-human-post-editing: AI produces the first pass, and a linguist edits before publish. This is the workhorse tier for most brand-facing content, marketing pages, onboarding flows, in-app messaging in new or high-value markets, where fluency and tone matter but full, from-scratch human translation is not justified by the risk or the volume.
Full human review: Every segment gets expert linguistic judgment, often against a formal quality framework. Reserved for content with legal, regulatory, or reputational exposure: contracts, regulatory filings, safety-critical instructions, financial disclosures, anything a lawyer or compliance officer will ask about later.
The mistake most content orgs make is not picking the wrong tier, it is picking one tier and applying it everywhere, either over-spending on human review for content that does not warrant it or under-governing content that does. The fix is a workflow primitive that lets you set risk-appropriate review per content type and change it without re-platforming.
Review gates: the control point, not a separate procurement step
This is where Ollang's execution-layer model diverges from a traditional vendor or TMS setup. In a conventional workflow, adding human review means a project manager emailing a vendor, negotiating turnaround, and manually re-routing files, a process change every time. In Ollang, review is a parameter on the order itself.
Add a Level 1 review gate to any order to route output to Ollang-managed linguists or your own LSPs and editors. That single sentence carries more operational weight than it looks like. It means your content team does not have to choose between Ollang's linguist network and your existing in-market reviewers or agency relationships, you can plug your own LSPs and editors into the same gate. The workflow structure does not change based on who is doing the reviewing, only the routing does.
Programmatically, this is exposed as a request you attach to an order, it requests or cancels a professional linguist review for an order, upgrading AI-generated output with expert review, and it can be reversed. Cancel human review reverts to the AI-only state and refunds the review credits if priority changes. For a Head of Content, that reversibility matters as much as the gate itself, you can escalate a specific order to human review when something looks off, or de-escalate a content type that has been running clean, without a change order or a new contract line.
This is also where threshold-based automation operates. Review gates respect qcThreshold routing rules, so orders may be re-routed automatically, meaning the gate is not purely manual. You can define the score below which content automatically escalates to a linguist, rather than relying on someone noticing a bad translation after it is live. Full detail on how gates, Levels, and LSP routing fit together lives in Ollang's API documentation, under the concepts covering Folders, Projects, Orders, Levels, Workflows, and Review Gates.
The QC scoring model: what gets measured, and by whom
Review gates decide whether a human looks at an order. QC scoring tells you whether they need to, and gives you a record either way.
Ollang's QC layer runs an automated evaluation against four criteria, it returns scores for accuracy, fluency, tone, and cultural fit, plus segment-level analysis. That is a different axis set than a single "quality score." Accuracy and fluency are the dimensions most MT evaluation historically focused on, whether it means the same thing and whether it reads naturally. Tone and cultural fit are the dimensions that determine whether content feels like it was written for that market rather than translated into it, and they are the ones a content leader is usually the only person in the building qualified to weigh in on.
The evaluation is callable directly, not bundled invisibly into every order. Run a standalone AI-powered QC evaluation on an order to assess translation quality across multiple criteria including accuracy, fluency, tone, and cultural fit. You can scope which criteria matter for a given content type, a UI string order might not need a cultural-fit check the way a marketing landing page does, and you can steer the evaluation itself, the request supports a customPrompt to focus the evaluator, such as "Please focus on technical terminology accuracy". For a product documentation set, that means telling QC to weight terminology precision over stylistic flourish; for a brand campaign, the opposite.
Results come back at the segment level, so a QC failure is not a vague "this order scored low", it is segment-by-segment evaluation results, each containing the segment identifier tied to specific text. That makes the score actionable rather than just a dashboard number, a reviewer or an automated rule can act on the specific string that failed, not re-review the whole order. The full request and response schema, including how scores and segment data are structured, is documented at the Run QC Evaluation reference.
Automated scoring is layered with human QC annotation on reviewed orders, the linguist's edits and notes become part of the record alongside the AI's scores, not a replacement for them. That combination is the governance artifact, an AI opinion on quality, a human correction where one occurred, and a trail connecting both to the specific order and segment.
