Most discussion of generative AI in commerce concentrates on the visible surfaces: the assistant, the chatbot, the search box. Those matter. But the highest-leverage AI work we have done is invisible to customers, and it exists because of a constraint that had nothing to do with AI.
The bottleneck was never the code
Expanding a B2B commerce platform into a new market involves the obvious engineering: multi-currency, market-specific catalogue, local payment and fulfilment integration, regulatory variation. We had built for that. New markets could be configured on a shared multi-locale platform rather than forked into a separate codebase.
What we had not solved was language — and language turned out to be the thing that actually set launch dates.
A high-SKU B2B catalogue is not a marketing site. It is tens of thousands of product titles, descriptions, category structures, specification attributes and units, plus transactional communications and support content. All of it needs to exist in the local language before launch. All of it changes continuously as the catalogue does.
Localization was not a launch task that completed. It was an ongoing obligation that started at launch and never stopped growing.
Handled manually, that produces two costs. The visible one is the delay before opening a market. The invisible and larger one is permanent drift: every catalogue change creates a window where some locales are stale, and the number of those windows scales with markets multiplied by change rate.
Building it as infrastructure, not a feature
The decision that shaped everything was to treat this as a platform capability with an owner, an interface and a quality bar, rather than a translation feature bolted onto the catalogue service.
Practically, that meant a few things:
- One capability, many consumers. Catalogue, content and customer communications all call the same engine. Three separate integrations would have produced three separate quality standards and three separate sets of terminology drift.
- Domain grounding is not optional. Generic translation gets B2B wholesale terminology wrong in ways that are subtly damaging — pack sizes, trade units, category conventions and product naming carry meaning that a general model does not reliably preserve. Grounding output in our own catalogue and glossary was the difference between usable and actively harmful.
- Locale parity is a system property. The engine is driven by catalogue change events, not by a person deciding it is time to retranslate. If a product changes and a locale falls behind, that is a measurable state the platform can report on.
- Humans review by exception. The goal was never full automation. It was to move human effort from translating everything to reviewing what the system flags as low-confidence or high-consequence.
Where LLM translation genuinely differs
Machine translation is not new. What changed with current models is not raw quality on isolated strings — it is the ability to hold context.
A model given the product, its category, its attributes and a glossary of house terminology produces meaningfully better output than one given a string. It can preserve register across a catalogue, respect terminology decisions consistently, and handle the structured-but-messy reality of specification text. That contextual capability is what makes the difference between a system that reduces human work and one that redistributes it into correcting output.
The evaluation problem
The hardest engineering in this system is not generation, it is knowing whether the output is good. Translation quality is subjective, domain-specific and expensive for humans to assess at catalogue scale. We invested more in evaluation and confidence signalling than in the generation path itself — and that ratio is, I think, correct for most production LLM systems.
Governance came before scale, deliberately
Running an LLM capability against catalogue and customer communications raises questions that have to be settled before volume, not after:
What data leaves our boundary, and under what terms. Vendor selection was as much a data-governance decision as a quality one.
What happens when it is wrong. Incorrect pack size or unit information in a B2B context is a commercial problem, not a cosmetic one. High-consequence fields carry stricter thresholds and mandatory review.
What it costs at steady state. Token cost scales with catalogue change rate. Modelling that early prevented an unpleasant discovery later.
Who owns the output. Clear accountability for translated content, rather than a diffuse assumption that "the AI did it."
The broader pattern
The lesson I would generalise is about where to look for AI value.
The instinct is to reach for the customer-facing surface, because that is where AI is legible as innovation. But the durable wins are often in the places where a human process quietly gates the business — where something scales linearly with markets, or catalogue size, or transaction volume, and therefore sets a ceiling nobody has named out loud.
Those bottlenecks are unglamorous. They also tend to be exactly the shape of problem current models are genuinely good at: high-volume, context-dependent, tolerant of review-by-exception, and expensive to solve with headcount.
Finding them requires knowing your operation well enough to see which constraint actually binds. That is an engineering leadership question, not a machine learning one — which is why AI strategy sits closer to platform architecture than most organizations initially assume.