The email arrived at 06:14 on a Tuesday, and by 06:20 Rosa knew her quarter was going to be about one supplier she had never once worried about. The message was a routine product notice from the machine-translation vendor her enterprise localization operation had run on for six years: the specific engine model her pipeline called, the one every one of her forty-three markets had been validated against, would reach end of life in ninety days. A successor model was available. It was, the notice said cheerfully, "significantly improved." What the notice did not say, and what Rosa spent the next ninety days discovering, was that "improved" meant different: different terminology tendencies, different handling of her code placeholders, a different critical-error profile on exactly the regulated medical content her company could least afford to get wrong, and a per-character price that had quietly risen forty percent under a new tier structure. Her entire quality validation, every ISO 5060 baseline she had established, every terminology-adherence number she had reported to leadership, was pinned to a model that a vendor she did not control had just deprecated with a form letter. She had built a magnificent quality operation on top of a single point of failure she had never named, and the failure had just named itself. This lesson is about treating that dependence as the operational risk it always was, before the form letter arrives, not after.

What Concentration Risk Actually Is, Named Precisely

Every enterprise localization leader carries a mental map of what could go wrong, and on that map the machine-translation engine usually sits in the "solved" region, a piece of infrastructure that either works or is being improved. That placement is the error. The engine is not solved infrastructure; it is a supplier relationship, and a supplier relationship carries every risk any single-supplier relationship in any part of the business carries, made worse by the fact that this particular supplier sits underneath your quality, your terminology, your data, and your deadline all at once. Before you can manage the risk you have to name it in the language a risk committee already speaks, so let us define the terms with care.

Concentration risk is the exposure created when a disproportionate share of an operation's capability depends on a single supplier, a single technology, or a single asset, so that one failure at that single point degrades or halts a large fraction of what the operation produces. It is the same idea a treasurer applies when too much cash sits in one bank, or a supply-chain lead applies when one factory makes a critical part: the danger is not that the single point is bad, it is that it is single. In localization, concentration risk is the share of your multilingual output that flows through one machine-translation engine, one language-service provider, one translation-management system, or one small pool of linguists, such that the loss of that one thing takes a large part of your capability with it.

Vendor lock-in is the specific, engineered form of concentration risk in which the cost of leaving a supplier has been made deliberately or accidentally high, so that switching is expensive, slow, or technically obstructed even when the supplier's price rises, quality drifts, or terms turn hostile. A machine-translation engine (MT engine) is the system, whether a dedicated neural machine-translation (NMT) model trained specifically to translate or a large language model (LLM) prompted to translate, that produces your first-pass output before a human opens the file. A multi-engine strategy is the deliberate architectural choice to be able to route content across two or more engines, so that no single engine's deprecation, price change, quality drift, or outage can halt your operation, because an alternative is already integrated and validated.

Concentration risk is not a statement about how good your engine or vendor is. It is a statement about how much of your operation stops working if that one engine or vendor stops working the way you assumed. A perfect supplier you cannot survive losing is still an unmanaged operational risk.

The reframing that unlocks everything downstream is this: the quality of your primary engine is a separate question from your exposure to it. Rosa's engine was excellent. Her terminology adherence was in the high nineties, her critical-error rate was low, her linguists trusted its first pass. None of that protected her, because none of it was the risk. The risk was that a single external decision, made by people who did not attend her quality meetings, could invalidate all of it in ninety days, and she had no second engine validated, no exit plan written, and no contractual protection against exactly the deprecation that arrived. Excellence and exposure are orthogonal. You can be excellent and fatally exposed at the same time, and most mature localization operations in 2026 are.

The Five Failure Modes of Single-Engine, Single-Vendor Dependence

Concentration risk is abstract until you enumerate the concrete ways it detonates, because a risk you cannot picture is a risk you cannot fund a defense against. There are five failure modes that recur across enterprise localization operations, and a leader should be able to name all five and point to where each lives in their own pipeline. They are not hypothetical; each has ended a quarter or a relationship somewhere, and Rosa's ninety-day scramble touched four of the five at once.

Engine Deprecation, Price Change, and Quality Drift

The first failure mode is the one that arrived in Rosa's inbox, and it has three faces that a leader should treat as one family. Deprecation is the vendor retiring the specific model your pipeline and your validation depend on, forcing a migration to a successor you did not choose and did not validate, on the vendor's timeline rather than yours. Because your ISO 5060 baselines, your terminology-adherence numbers, and your critical-error profile were all measured against the retired model, deprecation does not merely change a version number; it silently invalidates your entire quality evidence base, and you inherit the burden of re-establishing it under a deadline the vendor set.

Price change is the vendor raising the per-character, per-token, or per-seat cost, restructuring tiers, or moving a feature you depend on behind a higher plan, at a moment when your architecture gives you no credible ability to walk away. The price is not set by the market when you are locked in; it is set by your switching cost, and a vendor who knows you cannot leave in under six months prices accordingly. Quality drift is the subtler cousin: the engine changing under you, because the vendor retrains and improves the model on their schedule, so that behavior you validated, a specific rendering of a regulated term, a specific handling of a negation in a safety instruction, shifts without a version bump or a notice, and your validation quietly stops being true. For high-volume, low-liability content, silent improvement is pure upside. For regulated content whose behavior you certified to an auditor, an engine changing under you without warning is a governance failure waiting for an evaluation to catch it, and sometimes the evaluation catches it after the content has shipped.

Vendor Lock-In and the Portability of Your Assets

The second failure mode is lock-in, and it is worth dwelling on because it is the one most under a leader's own control and most often neglected until leaving becomes necessary and impossible at once. Lock-in accumulates quietly, one convenience at a time. You let the translation-management system store your translation memory (TM), the database of your previously approved source-and-target segment pairs, in a proprietary format that exports awkwardly or incompletely. You let the vendor's platform hold your termbase, the controlled glossary of your mandated terminology, with metadata and approval states that do not survive an export. You build your quality workflow, your automatic quality-estimation (QE) scoring, your severity gates, around one vendor's specific API and one vendor's specific error taxonomy. Each choice is reasonable in isolation. Together they mean that the day you want to leave, your linguistic assets, the accumulated intellectual property of years of human translation work, are hostage to the platform, and the cost of extracting them clean is high enough that you stay.

The antidote is portability: the deliberate discipline of keeping your linguistic assets in open, standard, vendor-neutral formats that you can move out clean at any time. Your TM should live, or be continuously exportable, in TMX (Translation Memory eXchange), the open XML standard for TM interchange. Your termbase should be exportable in TBX (TermBase eXchange), the open standard for terminology. Your segment-level data should ride on XLIFF (XML Localization Interchange File Format), the open standard for bilingual content in transit. When your assets are portable, lock-in cannot form, because leaving is a data export and a re-integration, not a hostage negotiation. When they are not, every year of accumulated TM and termbase deepens the moat that keeps you with a vendor you may need to leave.

Your translation memory and termbase are the most valuable, least replaceable assets your operation owns, and they are the ones lock-in captures. Portability is not a technical nicety; it is the difference between assets you own and assets a vendor is merely storing for you until you try to take them back.

Data Exposure Through a Single Concentrated Pipe

The third failure mode is data exposure, and concentration makes it worse in a way leaders often miss. Every segment you send to a hosted engine is your source content, sometimes unreleased product information, sometimes regulated medical or financial text, sometimes personally identifying data, leaving your control and entering a vendor's systems. When one engine handles the overwhelming majority of your volume, that one vendor's data-handling posture, retention policy, sub-processor list, jurisdiction, and breach history becomes the data-exposure posture of your entire multilingual operation. A single vendor's security incident becomes your incident across every market at once. A single vendor's decision to retain submitted content for model training, buried in a terms-of-service update, becomes your confidentiality breach at enterprise scale. Concentration does not create the data-exposure risk, but it removes the diversification that would have contained it, and it hands one external party leverage over content whose exposure could be a regulatory or competitive catastrophe.

Single-Supplier Dependency in the Linguist Pool

The fourth failure mode is the one that hides best, because it wears the face of a healthy relationship. Many enterprise operations route the human half of their pipeline, the post-editing, the evaluation, the terminology work, the transcreation, through a single language-service provider (LSP), and that LSP in turn often relies, for a given specialized language pair or domain, on a small pool of linguists, sometimes a handful of people, sometimes one irreplaceable specialist. Your machine-translation post-editing (MTPE) capacity in a critical market can, when you trace it honestly, rest on two or three humans you have never met, employed by a vendor whose stability you have not audited. If that LSP loses the client, raises rates, suffers a founder's departure, or simply cannot staff a surge, your human quality layer, the layer that catches the silent critical error the engine produces, thins or vanishes in exactly the markets where you most need it. Single-supplier dependency in the linguist pool is concentration risk on the human side, and it is more fragile than the engine side because humans give notice, get sick, and leave the industry in a way models do not.

The Platform Itself as the Fifth Point

The fifth failure mode is the translation-management system (TMS) that orchestrates everything, the platform through which content enters, gets routed, gets machine-translated, gets post-edited, gets scored, and gets delivered. When the TMS, the engine, and the asset storage are all one vendor's stack, the concentration is total: a single supplier owns your workflow, your first-pass output, your assets, and your quality records simultaneously. That integration is genuinely convenient, and the convenience is exactly what makes the concentration invisible, because everything works so smoothly that the question of what happens if this one vendor fails never gets asked until the vendor fails. A strategist separates these layers in their mind even when one vendor supplies them all, because you cannot assess a concentration you have mentally merged into "the platform."

How to Assess Concentration Risk Before It Assesses You

You cannot manage what you have not measured, and concentration risk is measurable. The assessment is not exotic; it is a disciplined inventory that any localization leader can run in a week and should run every year, and it produces a picture specific enough to fund decisions against. The goal is to move from "we mostly use one engine" to a quantified, tier-aware exposure map that a risk committee will recognize as rigorous.

Step One: The Dependency Inventory

Begin by listing, for each layer of the pipeline, exactly which supplier provides it and what share of your volume flows through it. For the engine layer, what fraction of your total translated volume, by content tier and by language pair, passes through your primary engine, and what fraction through any alternative? For the human layer, which LSP or LSPs supply post-editing and evaluation, and for each critical language pair, how many individual linguists actually do that work? For the asset layer, where do your TM and termbase physically live, in what format, and can you export them clean today? For the platform layer, which TMS orchestrates the flow, and how much of the above is the same single vendor? Write the shares as numbers. "Most" is not an assessment; "94% of regulated-tier volume through one engine, whose assets we cannot export in under six weeks, post-edited by one LSP that staffs it with three linguists" is an assessment. The discomfort of writing the real numbers is the point; comfort was the thing hiding the risk.

Step Two: Weight the Exposure by Consequence, Not Just Volume

Raw volume share understates the risk on your most dangerous content and overstates it on your safest, so weight the inventory by consequence tier. A single engine handling ninety percent of your marketing and release-note volume is a productivity risk if it fails: annoying, expensive, survivable. A single engine handling ninety percent of your regulated medical or legal volume is a liability and compliance risk if it drifts or deprecates, because the quality behavior you certified is the thing at stake, and re-certifying under a deadline you did not choose is where silent critical errors slip through. Assess each concentration against the consequence of the content flowing through it. The question is never simply "how concentrated are we," it is "how concentrated are we on the content where a failure hurts most," and the answer usually reveals that the highest concentration sits on the highest-consequence content, because that is where a single validated engine felt safest.

Step Three: Measure Your Switching Cost and Switching Time

The sharpest single number in a concentration-risk assessment is the honest answer to one question: if your primary engine or vendor became unacceptable tomorrow, for price, quality, deprecation, security, or terms, how long would it take you to move a critical language pair to an alternative, and what would it cost? If the answer is measured in weeks, your lock-in is mild and your options are real. If it is measured in many months, or if you genuinely do not know because you have never integrated an alternative, your switching cost is a moat around a vendor's pricing power and a cliff under your operation. Estimate the time to integrate a second engine, re-validate your quality baselines against it, export and re-import your assets, and retrain your linguists on any workflow difference. That estimate is your true exposure. Rosa's was ninety days of forced, unplanned work because her real switching time was longer than the deprecation notice, which is the precise definition of being trapped.

The single most revealing metric in a concentration-risk assessment is your switching time: how long it would take to move critical content to an alternative supplier you have already integrated and validated. If you have never integrated an alternative, your switching time is unknown and therefore unbounded, which is the worst possible answer.

Step Four: The Portability Audit

Finally, audit whether your assets can actually leave. Do not trust the vendor's marketing claim that export is supported; test it. Export your TM to TMX and re-import it into a neutral tool, and check whether the segments, the metadata, the context, and the approval states survived. Export your termbase to TBX and verify the mandated terms, the forbidden terms, the definitions, and the approval states came through intact. Run a real bilingual file out as XLIFF and back and confirm nothing broke. The gap between "export is supported" and "export is clean and complete" is where lock-in hides, and the only way to know which you have is to perform the export and inspect the result before you need it in an emergency. An export you have never tested is an assumption, not an asset.

Mitigation, and the Honest Cost of Resilience

An assessment that ends in fear is malpractice; an assessment ends in a mitigation plan with costs attached, because resilience is not free and pretending it is loses the argument with the CFO. The strategist's job is to make the cost of resilience visible and to weigh it, explicitly and defensibly, against the cost of the failure it prevents. Walk the mitigations in order of leverage, cheapest and highest-return first.

Portability First, Because It Is Cheap and It Prevents the Trap

The highest-leverage, lowest-cost mitigation is to make your assets portable and keep them portable, continuously, as a standing discipline rather than a project. Insist that your TM is exportable to TMX and your termbase to TBX at any time, in your contract and in your architecture, and periodically export and verify, so the export is proven, not promised. Prefer, where you can, to hold the master copy of your linguistic assets in a vendor-neutral store you control, syncing to the platform rather than surrendering the master to it. Portability costs engineering discipline and a little friction; it does not cost capital. And it is the mitigation that prevents lock-in from ever forming, which means it is the one that keeps every other mitigation affordable, because you cannot cheaply pursue a multi-engine strategy if your assets are trapped in one vendor's format. Portability is the foundation the rest of the plan stands on.

The Multi-Engine Strategy, and Its Real Price

The core structural mitigation for engine concentration is a multi-engine strategy: integrate, validate, and keep warm at least one alternative engine, so that a second option is production-ready before you need it, not theoretical. The critical word is warm. A second engine you have named but never integrated is not a mitigation; it is a hope. A warm alternative is one your pipeline can route to today, whose quality you have baselined against your test sets under ISO 5060, whose terminology adherence you have measured with your termbase grounded, and whose critical-error profile on your regulated content you know. When your primary deprecates, drifts, or reprices, you route affected content to the warm alternative while you respond on your own timeline, and the vendor's leverage over you collapses, because your ability to leave is real and demonstrated.

Be honest about the cost, because the CFO will be. A multi-engine strategy costs the engineering to abstract your pipeline so it can route to more than one engine, the ongoing effort to keep the alternative validated as both engines evolve, and some duplicated evaluation work, because you now baseline two engines instead of one. It does not usually cost double your engine fees, because the alternative carries little traffic until it is needed, but it costs real, recurring operational attention. That recurring cost is the premium you pay for the option to walk away, and like any insurance premium it feels wasteful right up until the day it is the only thing standing between you and a ninety-day forced migration on a vendor's deadline. The strategist's move is to size the premium honestly and set it against the sized cost of the failure.

Exit Plans and Contractual Protections

Two mitigations cost mostly foresight rather than money. The first is a written exit plan for each critical supplier: a documented, rehearsed procedure for moving off that supplier, naming the steps, the asset exports, the re-validation, the alternative, and the realistic timeline, written while the relationship is healthy and reviewed annually. An exit plan converts an emergency into a procedure. The difference between Rosa's ninety-day scramble and a controlled ninety-day migration is entirely whether the plan existed before the notice arrived. The plan does not commit you to leaving; it guarantees you can, calmly, which is itself a source of leverage in every renewal conversation.

The second is contractual protection, negotiated up front, when you have the most leverage, which is before you sign and depend. The contract is where you turn concentration risk into supplier obligations: advance-notice clauses for model deprecation and material changes, long enough to migrate on your timeline rather than theirs; price-protection and cap clauses that limit the vendor's pricing power over a locked-in customer; data-handling, retention, non-training-on-your-content, and sub-processor terms that bound your data-exposure risk; guaranteed asset-portability and clean-export rights in standard formats; and service-level commitments with teeth. A strategist reads the deprecation and change-of-terms clauses before the pricing, because those clauses are where the concentration risk either bites or is bounded, and they are nearly free to negotiate at signing and nearly impossible to obtain once you are dependent.

Diversifying the Human Layer

The mitigations for engine concentration have human-side analogues that leaders skip because the LSP relationship feels personal in a way an API does not. Diversify the linguist pool the way you diversify engines: qualify a second LSP for your critical language pairs before you need one, understand how many individual linguists actually stand behind each critical pair and refuse to let it silently fall to one, and ensure that terminology and process knowledge lives in your portable assets and documented workflows rather than only in one vendor's institutional memory. The goal is not to churn suppliers or to treat loyal partners as disposable; it is to ensure that no single LSP's loss, and no single specialist's departure, can take a critical market's human quality layer with it. A healthy vendor relationship and a documented fallback are not in tension; the fallback is what lets you invest in the relationship without being hostage to it.

The Cost of Resilience Versus the Cost of a Failure

Every mitigation above costs something, and a leader who cannot articulate why that cost is justified will lose the budget for it in the first hard quarter. So make the comparison explicit and defensible, because it is the comparison that wins the argument, and it is a comparison the discipline of enterprise risk management already knows how to hold. On one side, the cost of resilience: the engineering and recurring attention of a multi-engine strategy, the discipline of portability, the foresight of exit plans, the negotiation of protective contracts, the qualification of a second LSP. Sum it honestly. It is real, it is mostly recurring operational cost rather than capital, and it feels like insurance because it is.

On the other side, the cost of a concentration failure, which you size by tier and by scenario. A regulated-tier engine deprecation that forces an unplanned re-validation under a vendor's deadline costs the emergency engineering, the emergency evaluation, the risk of a silent critical error slipping through the rushed migration into content that can injure or trigger a regulatory action, and the leadership cost of explaining why the operation was surprised. A price change against a locked-in operation costs the delta on your entire annual spend, compounded for as long as the lock-in lasts, with no negotiating leverage to blunt it. A data-exposure incident at a concentrated vendor costs the breach response across every market at once, the regulatory exposure, and the client trust. A single-LSP collapse in a critical pair costs the market's human quality layer at exactly the moment you cannot replace it. Size each scenario in money and in consequence, weight it by how likely it is over your planning horizon, and set the total against the cost of resilience.

Resilience is insurance, and the honest test is the same as any insurance: does the premium, the recurring cost of portability, a warm second engine, exit plans, and protective contracts, cost less than the probability-weighted cost of the failures it prevents, concentrated on your highest-consequence content? For an enterprise's regulated tier, it almost always does. The premium is small and recurring; the failure is large and sudden.

The reframing that carries the argument with leadership is that concentration risk is not a localization problem asking for a favor; it is an operational risk that belongs on the same register as supply-chain single-sourcing and treasury counterparty exposure, assessed with the same rigor and funded with the same logic. Localization leaders who present it that way, in the language of enterprise risk rather than the language of linguistic preference, win the resilience budget, because they have translated a technical exposure into a risk a board already knows how to weigh. Localization leaders who present it as "we would feel safer with a second engine" lose it, because that is a preference, not a case.

A Worked Concentration-Risk Assessment and Mitigation Plan

Return to Rosa, but rewind past the form letter to the assessment she wished she had run a year earlier, and watch it produce a plan that a CFO funds and a risk committee accepts. Her operation ships enterprise medical-device software and its regulated documentation, plus marketing and support content, into forty-three markets. She ran the four-step assessment deliberately, tier by tier, and wrote the uncomfortable numbers down.

The Assessment: What the Numbers Revealed

The dependency inventory was stark. Ninety-four percent of her total volume, and effectively all of her regulated-tier volume, flowed through one hosted MT engine. Her TM and termbase lived inside the same vendor's TMS, in a proprietary store whose export she had never tested. Her regulated-tier post-editing ran through one LSP, which staffed her two most critical language pairs with three linguists between them. The platform, the engine, and the assets were one vendor's integrated stack. Weighting by consequence made it worse, not better: the concentration was highest exactly where consequence was highest, on the regulated medical content, because that was where a single validated engine and a single trusted LSP had felt safest. Her switching-time estimate was the number that ended the debate: she had never integrated an alternative engine, so her honest switching time was unknown and, on the regulated tier, realistically longer than any deprecation notice a vendor would give. The portability audit confirmed the fear: a test export of her termbase to TBX dropped the approval states and half the metadata, meaning her assets were not portable, they were stored.

The Mitigation Plan, Sequenced and Costed

Rosa did not propose ripping out a working vendor, because that would have been reflex, not strategy, and it would have lost the room. She proposed a sequenced, costed resilience plan, ordered by leverage. First, portability, immediately and cheaply: establish a vendor-neutral master store for TM and termbase in TMX and TBX, fix the broken export, and verify a clean round-trip, so lock-in stopped deepening while everything else proceeded. Second, a warm second engine for the regulated tier specifically, integrated behind an abstraction layer and validated against her ISO 5060 baselines and her termbase-grounded terminology tests, so that the highest-consequence content, and only that content to start, had a production-ready alternative. Third, a written exit plan for the primary vendor and a second qualified LSP for the two critical language pairs, both as foresight rather than capital. Fourth, at the next renewal, contractual protections she now knew to demand: advance-deprecation notice long enough to migrate on her timeline, price caps, non-training-on-content and clean-export guarantees, and portability rights in standard formats.

Then she costed the plan against the failure it prevented, in the language her CFO used. The resilience premium was mostly recurring engineering and evaluation attention, sized and named. The failure it prevented was, on the regulated tier, a probability-weighted cost of an unplanned re-validation under a vendor's deadline, with a silent critical error slipping into medical content as the tail risk that a regulator or a patient, not a rework ticket, would price. She showed that the premium was a fraction of the probability-weighted failure cost on the regulated tier alone, before even counting the marketing and support tiers, and that the largest single line, portability, cost almost nothing but discipline. The plan did not eliminate her primary vendor, whom she valued; it ended her helplessness in front of that vendor, which is a different and more defensible thing.

The output of a concentration-risk assessment is never "fire the vendor." It is a sequenced, costed resilience plan, portability first, a warm alternative for the highest-consequence tier, exit plans and second suppliers as foresight, and protective contracts at renewal, each justified by a measured exposure and a sized failure cost a risk committee can re-derive.

Why the Plan Survived Leadership

Rosa's plan survived because she presented concentration risk as what it is, an operational risk on the enterprise register, not a linguistic wish. When the CFO asked why spend on a second engine that would carry almost no traffic, she answered in insurance terms: the second engine is not capacity, it is the option to walk away, and the premium for that option is smaller than the deprecation cost it caps. When the head of engineering resisted the abstraction layer as complexity, she showed the ninety-day scramble the abstraction layer would have prevented, and named the switching time it would convert from unknown to bounded. When the quality lead worried a second engine meant validating twice, she agreed and folded that duplicated evaluation into the sized premium, openly, because a cost you name defends you and a cost you hide ambushes you. Every element of the plan traced to a number in the assessment, and every number an auditor could re-derive. That traceability is the difference between a leader who manages concentration risk and one who, like Rosa at 06:14 on a Tuesday, discovers it.

Key Takeaways

• Concentration risk is the exposure created when a disproportionate share of your operation depends on a single engine, vendor, TMS, or linguist pool, so that one failure at that single point degrades a large fraction of your output. It is orthogonal to quality: an excellent supplier you cannot survive losing is still an unmanaged operational risk, and most mature localization operations are excellent and fatally exposed at once.
• There are five failure modes to name in your own pipeline: engine deprecation, price change, and quality drift (which silently invalidate the quality baselines you validated against a specific model); vendor lock-in when assets are trapped in proprietary formats; data exposure concentrated in one vendor's handling posture; single-supplier dependency in the linguist pool where a critical language pair may rest on two or three humans; and the TMS platform that concentrates workflow, engine, assets, and records in one stack.
• Assess concentration risk in four steps: a dependency inventory with real volume-share numbers per layer; a weighting by consequence tier, because the highest concentration usually sits on the highest-consequence regulated content where a single validated engine felt safest; a switching-time estimate, the sharpest single metric, which is unbounded and worst-case if you have never integrated an alternative; and a portability audit that tests, not trusts, whether TM (TMX), termbase (TBX), and bilingual files (XLIFF) export clean and complete.
• Portability is the highest-leverage, lowest-cost mitigation: keep TM and termbase continuously exportable in open standard formats and, where possible, hold the master in a vendor-neutral store you control. Portability costs discipline, not capital, prevents lock-in from ever forming, and is the foundation that keeps every other mitigation affordable.
• A multi-engine strategy means keeping at least one alternative engine warm: integrated, routable today, and validated against your ISO 5060 baselines and terminology tests, not merely named. A warm alternative collapses a vendor's leverage over you because your ability to leave is real and demonstrated; the recurring cost is the premium you pay for the option to walk away.
• Exit plans and contractual protections cost foresight rather than money and must be secured while the relationship is healthy and before you sign: a rehearsed, documented exit procedure per critical supplier, plus advance-deprecation-notice clauses, price caps, non-training-on-content and clean-export guarantees, data-handling terms, and portability rights, all nearly free at signing and nearly impossible to obtain once you are dependent.
• Diversify the human layer the way you diversify engines: qualify a second LSP for critical language pairs, know how many individual linguists actually stand behind each pair and refuse to let it fall silently to one, and keep terminology and process knowledge in your portable assets rather than only in a vendor's institutional memory. A documented fallback lets you invest in a partner without being hostage to it.
• Win the resilience budget by presenting concentration risk as an operational risk on the enterprise register, weighed like supply-chain single-sourcing and treasury counterparty exposure: size the recurring cost of resilience against the probability-weighted cost of failure on your highest-consequence tier, where the premium is small and recurring and the failure is large and sudden. The output of the assessment is never "fire the vendor"; it is a sequenced, costed plan that ends your helplessness in front of the vendor while keeping the relationship you value.