Same assistant, different model: launching an AI shopping assistant in China for a foreign consumer brand

The situation

A European skincare and personal care brand sold online and through partners in Europe, the US and China. Its AI shopping assistant answered questions about ingredients and products, built routines from a short questionnaire and handed off to customer service when needed. It ran on a global model provider, with logs and customer profiles in the brand's European cloud. China had its own app, mini-programme and marketplace stores, but no assistant.

Why now. On 31 October 2026, Apple and Alibaba said Alibaba's Qwen will power the China edition of Apple Intelligence, a clear signal that even global platforms ship a different model in China to meet local rules¹. China's Interim Measures for generative AI services require qualifying public-facing services to go through filing with the Cyberspace Administration of China², which publishes lists of filed services in batches³. And the Personal Information Protection Law governs any transfer of Chinese customers' data abroad, with certification measures in effect from 1 January 2026 alongside the standard contract and security assessment routes⁴. The brand's leadership wanted a Chinese edition for the next sales season, built the right way.

What had to be true

• A locally permitted model for Chinese users, with the application registered where required.
• Personal data stays in China: prompts, answers, profiles and logs.
• One product, not two: shared code and features, with market-specific configuration.
• Chinese-language quality proven on a local evaluation set before launch.
• Documentation that follows the design: filing, impact assessment and transfer analysis drawn from the architecture.

Architecture

The data flow, end to end

The hard part: one product, two data worlds

The tempting path was a separate Chinese build: copy the code, swap the model, deploy in China. That would have doubled every future feature and fix. Instead the team moved the product to a task-level AI interface. The application asks for "answer a product question" or "build a routine", and a router decides which model serves it, based on the user's market. Prompts and safety rules became configuration per market, so Chinese prompts could reflect local language, product names and expectations without forking code. See designing AI products with a model per market.

Data was the second half. Product catalogue data is not personal, so it is synced into China. Customer profiles, conversations and logs are created and stored in China and never leave. Telemetry was the easiest thing to get wrong: the global observability stack would have pulled Chinese traces out of the country by default. The team ran a separate telemetry pipeline inside the China environment, using a shared collector with separate pipelines per channel to keep operations simple⁵, and only aggregated, non-personal metrics are reported to the global dashboard.

Keeping personal data in China also simplified the legal work. With nothing personal designed to leave the country, the assistant did not rely on any of PIPL's transfer mechanisms, a position counsel reviewed, and the impact assessment could describe a clean boundary rather than a set of exceptions⁴.

How it ran

Key decisions and trade-offs

What I'd do again, and differently

Again: refactor to a task-level interface before building the China region. It turned a risky fork into configuration. Differently: build the Chinese evaluation set with the China customer service team from day one; their real questions were the best test material. Related: model routing, evaluation sets that predict production, consent-aware data in India and where I work.

If you are taking an AI product into China or other markets with their own AI rules, see my AI architecture work, or analyse your challenge and bring the result to a call.