One product, many models: what Apple's Qwen deal teaches about building AI for different markets

What happened

Apple and Alibaba said on 31 October that Alibaba's Qwen will power the China edition of Apple Intelligence, covering features such as Writing Tools and Visual Intelligence, with a developer beta from 4 November and a public release planned for December¹². The rebuilt Siri is not part of this release, and eligibility depends on the device being bought in China or the device and account region being set to China¹. Alibaba says it will not use user requests or responses to train its models².

The regulatory backdrop explains the shape of the deal. China's Interim Measures for generative AI services require qualifying public-facing services to go through a filing process with the Cyberspace Administration of China³, which publishes lists of filed services in batches⁴, and a 2026 list of on-device generative AI filings reportedly named Apple Intelligence⁵.

Why this matters beyond Apple

Most AI products are built as if there will be one model provider, one region and one set of rules. That assumption is breaking. China is the clearest case, but data residency rules in the GCC, India and elsewhere, sector rules in financial services and health, and customers' own procurement policies all push towards different models or deployments per market. Apple has the resources to build a separate edition. Most companies need an architecture that makes it routine.

Five design rules

1. Call tasks, not vendors. Application code should ask for "summarise", "rewrite" or "describe image", not for a specific provider's API. That single change is what makes a per-market model a configuration choice rather than a rewrite. See model routing.

2. Route on market, task and data class. The router decides which model may serve a request based on where the user is, what the task needs and how sensitive the data is. Some markets get the global model, some a local one, some a self-hosted one; see running a large open model yourself.

3. Evaluate per market and language. A model that tests well in English may behave differently in Simplified Chinese, Arabic or Bahasa, and local safety expectations differ. Keep an evaluation set per market and run it on every model change; see evaluation sets that predict production.

4. Keep data paths and evidence in the market. Prompts, outputs and logs often carry personal data. If the model runs in-country but your logs ship elsewhere, you have moved the problem, not solved it. Separate telemetry pipelines per market or tenant give strong isolation, at the cost of running more of them⁶.

5. Ship features by market, not all at once. Apple is launching some features in China and holding others back¹. Feature flags per market let you launch what the local model and rules support, and add the rest when they do.

A plan for adding a market

CTO take

Apple's deal is a large-scale proof that "one global model" is not a viable plan for products sold everywhere. The good news is that the architecture to handle it is not exotic: a task-level AI interface, a router, per-market evaluations and data boundaries. Teams that build those now can enter a new market by configuring a model and running an evaluation; teams that hard-code a single provider will face a rewrite each time. For examples by region, see a sovereign LLM platform in Europe, privacy-first AI triage in Kenya and where I work.

How I can help

I help teams design AI platforms that can run different models per market without forking the product. I am based in India, the United States and the UAE, working globally. See AI architecture or analyse your challenge and bring the result to a call.