Does Microsoft Translator Work in China? PIPL Cross-Border Data Transfer & Content Residency

Microsoft Translator (now Azure AI Translator) is reachable from China — and even runs in-country on the separate 21Vianet cloud — but the default public-cloud call ships your source text offshore to be translated: a PIPL cross-border transfer of the personal and sensitive information inside it. A compliance-first look at content residency, Azure's no-trace policy, and the lawful in-country path.

By the 21YunBox Compliance Team · Reviewed 2026-10-10 · Verified against Microsoft Translator's own documentation

Does Microsoft Translator work in China?

Microsoft Translator (now Azure AI Translator) is reachable from China — but the question that decides compliance is what happens to the content you send it: by default every string and document is shipped to an offshore Microsoft datacenter to be translated.

In the public Azure cloud there is no mainland-China processing region — the nearest "Asia Pacific" endpoint processes in Japan or Southeast Asia — so translating China-origin content is a PIPL cross-border transfer of the personal and sensitive information inside it (Articles 38–40; Article 28 for sensitive content), with an in-country storage duty under Cybersecurity Law Article 39 (formerly Article 37) for a CII or high-volume handler. Azure's no-trace policy means the submitted text is not retained or used to train models — real, but a retention promise, not a residency one: the content still crosses the border, and a Custom Translator corpus persists offshore.

The lawful lever is to keep China content's translation in-country — Azure Translator does run on the separate 21Vianet China cloud, or use a licensed domestic MT service — and to minimize personal information before any offshore call, not to make an offshore API "reachable." This is a risk map, not a verdict — settle the specifics with counsel. Our China team can map your exposure →

What Microsoft Translator's own documentation says about China

Fact	Primary source
Azure AI Translator is no-trace for standard translation — but Custom Translator keeps your training corpus. Microsoft's FAQ states Azure Translator "doesn't store customer data submitted for translation permanently or at rest" and that there's "no record of the submitted text or document in any Microsoft data center," and the data-privacy page says document translation is "removed permanently with a hard delete." The exception: a Custom Translator model is trained from the bilingual documents you upload, which are retained in a workspace region — none in mainland China.	Microsoft Learn — Azure Translator FAQ and Data, privacy, and security for Azure Translator (learn.microsoft.com), retrieved 2026-10-10
The public Azure cloud has no mainland-China Translator region. Microsoft's "Region support for Azure Translator" page routes the "Global" endpoint to the "Closest available datacenter" and the "Asia Pacific" endpoint to "Japan East or Southeast Asia" — the nearest public-cloud processing to China is still offshore. The page states "Translator doesn't persist customer data submitted for text translation," but processing location, not retention, is what makes a China-origin call a cross-border transfer.	Microsoft Learn — Region support for Azure Translator (learn.microsoft.com), retrieved 2026-10-10
Azure Translator does run inside the mainland — on the separate 21Vianet sovereign cloud. Microsoft's sovereign-clouds reference states "Translator is currently deployed in the China cloud," through the api.translator.azure.cn endpoint, on an instance it describes as "a physical and logical network-isolated instance of cloud services located in China." It is a separate account: using it requires "a Chinese legal entity, Internet Content provider (ICP) license, and physical presence within China." A different partition is a lawful in-country option, not automatic compliance.	Microsoft Learn — Azure Translator in sovereign (national) clouds (learn.microsoft.com), retrieved 2026-10-10
Sending source content offshore to be translated is a cross-border transfer under PIPL. Shipping a China user's text, documents, or support tickets to a Translator endpoint outside the mainland triggers PIPL Articles 38–40 — notice, a separate consent, and one transfer mechanism (a CAC security assessment, the standard contract, or certification) — with Article 28 adding separate consent and an impact assessment for sensitive content, and in-country storage for a CII or high-volume handler under Cybersecurity Law Article 39 (formerly Article 37) and PIPL Article 40.	Personal Information Protection Law of the PRC, Articles 28 and 38–40 (cac.gov.cn), retrieved 2026-10-10

Sources verified by the 21YunBox compliance team on 2026-10-10.

For a mainland-China audience, the question to settle about Microsoft Translator — the machine-translation service now delivered as Azure AI Translator (part of Azure AI services, formerly Cognitive Services; Microsoft’s current docs file it under “Foundry Tools”) — is not whether the API can be reached from China. It can, and Microsoft even runs a version of it inside the mainland. The question is what happens to the content you send it. This is a raw machine-translation API: every UI string, document, and support ticket you submit is shipped to a Microsoft datacenter to be translated, carrying whatever names, emails, addresses, contract terms, source code, or medical and financial detail sit inside it — and the content you most need translated is exactly the content most likely to contain personal or confidential information. In the public Azure cloud there is no mainland-China processing region; the nearest “Asia Pacific” endpoint processes in “Japan East or Southeast Asia.” Azure’s no-trace policy means that text is not retained or used to train models — real, and it matters — but no-trace is a retention promise, not a residency one. The content still crosses the border: a cross-border transfer of personal information (PIPL Articles 38–40), a higher bar for sensitive content (Article 28), an in-country storage duty for a CII or high-volume handler (Cybersecurity Law Article 39, formerly Article 37), and — if you train a custom model — a bilingual corpus that persists offshore.

Microsoft Learn 'Region support for Azure Translator' page: the standard NMT endpoint table listing request processing locations — Global at the closest available datacenter, Americas in East US 2 or West US 2, Asia Pacific in Japan East or Southeast Asia, Europe in France Central or West Europe — with no mainland-China region, plus the data-residency note that Translator doesn't persist customer data submitted for text translation. — "Japan East or Southeast Asia" — Microsoft's own region table shows the closest public-cloud processing location for Azure Translator is still offshore from the mainland, and the public Azure cloud has no mainland-China Translator region; the same page notes Translator "doesn't persist customer data submitted for text translation," a retention promise that does not change where the content is processed. Source: Microsoft Learn — Region support for Azure Translator

Microsoft Translator in China at a glance

What decides it	In Microsoft's own terms — and China's law
What you send	A raw machine-translation API: every UI string, document, support ticket, or knowledge-base article you submit is sent to Azure AI Translator to be translated — carrying whatever names, emails, addresses, contract terms, source code, or medical and financial text sit inside it. The content you most need translated is the content most likely to contain personal or confidential information.
Where it is processed	In the public Azure cloud there is no mainland-China region. Microsoft's region table routes the "Global" endpoint to the "Closest available datacenter" and the "Asia Pacific" endpoint to "Japan East or Southeast Asia" — offshore from the mainland. Sending China-origin content there is a cross-border transfer of personal information under PIPL Articles 38–40 (数据出境): notice, a separate consent, and a transfer mechanism.
Sensitive content	Documents you translate in full often include sensitive categories — medical, financial, legal, or ID data. PIPL Article 28 requires separate consent plus a personal-information protection impact assessment, and you cannot "anonymize" a document you need translated in full. Azure's no-trace policy does not change this — it limits retention, not the fact of the transfer.
Retention, training, and the custom corpus	Favorable but partial: Microsoft states Azure Translator "doesn't store customer data submitted for translation permanently or at rest" and doesn't use it to train models; document translation is temporary, then "removed permanently with a hard delete." But Custom Translator retains the bilingual corpus you upload to train a model in a workspace region — none in mainland China — and a CII or high-volume handler owes in-country storage under Cybersecurity Law Article 39 (formerly Article 37).
Reachability isn't the axis	The API is reachable — and Microsoft even runs Azure Translator inside the mainland on the separate 21Vianet cloud. The lawful lever is to keep China content's translation in-country (the 21Vianet-operated service, or a licensed domestic machine-translation alternative) and to minimize or pseudonymize personal information before any offshore call — not to make an offshore endpoint reachable. The China-facing app that consumes the translations carries an ICP filing duty and needs in-country delivery.

What you actually send — and where it goes

A machine-translation API is, by design, a service you feed your own content to. With Azure AI Translator the flow is text in, text out: your application posts strings or whole documents to a Microsoft endpoint, and the translation comes back. The important thing is not the round-trip time — it is that the source is yours, and it leaves your control the moment it is sent. The content a business most often needs translated — support tickets, HR and legal documents, product copy, knowledge-base articles, user-generated text — is precisely the content most likely to hold names, contact details, account records, or sensitive medical, financial, and identity data. Translating it means transmitting all of it.

Where does it go? In the public Azure cloud, there is no mainland-China datacenter for Translator. Microsoft’s “Region support for Azure Translator” page is explicit about the request-processing locations: the “Global” endpoint resolves to the “Closest available datacenter” (and, on a datacenter failure, “the request might be processed outside the originating geography”), “Americas” to “East US 2 or West US 2,” “Europe” to “France Central or West Europe,” and the nearest Asia option, “Asia Pacific,” to “Japan East or Southeast Asia.” For a user in China, every one of those is offshore.

Azure’s retention posture, to Microsoft’s credit, is strong — and worth stating honestly. The Translator FAQ answers the retention question flatly: “Azure Translator doesn’t store customer data submitted for translation permanently or at rest. There’s no record of the submitted text or document in any Microsoft data center.” The data-privacy page adds that text translation “processes customer data at REST and doesn’t store customer data,” and that document translation only “temporarily stores customer data while processing” before it is “removed permanently with a hard delete.” Submitted text is not used to train models. That closes most of the retention and model-training exposure that dogs other MT APIs — but it does not close the one that China’s law turns on. No-trace describes what happens after a request; it does not change that the request itself carried your content across the border to be processed. And there is one standing exception to even the retention point: a Custom Translator model is built from the bilingual documents you upload, which are retained in a workspace region to train and host it — and none of Custom Translator’s supported regions is in mainland China.

It’s a cross-border data transfer — under PIPL

Send a Chinese user’s text, ticket, or document to a Translator endpoint outside the mainland and you have made a cross-border transfer of personal information (数据出境) under China’s Personal Information Protection Law. The duty sits on the handler — you, the one submitting the content — not on Microsoft. PIPL Articles 38–40 require notice to the individual, a separate consent distinct from any general agreement to use your product, and one lawful transfer mechanism: a CAC security assessment, the CAC standard contract, or certification.

Sensitive content raises the bar again. A document you translate in full frequently contains sensitive personal information — medical, financial, legal, biometric, religious, or government-ID data — and PIPL Article 28 requires a separate consent and a prior personal-information protection impact assessment for handling it. The uncomfortable part is that you cannot minimize your way out of a document you need rendered in full: redacting the sensitive text defeats the translation.

Underneath transfer sits residency. A critical information infrastructure operator or a large-volume handler must store personal information collected in China inside the mainland — PIPL Article 40 together with the Cybersecurity Law. (The 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39; the substance is unchanged.) For a raw text-translation call Azure’s no-trace policy means little content is stored — but a Custom Translator corpus is, offshore, and where volumes or sensitivity cross the thresholds the export itself may require a CAC data-export security assessment before it may proceed. These thresholds and classifications are fact-specific, which is why they belong with counsel rather than a default assumption.

Reaching the API isn’t the question — keeping the content in-country is

Because Azure Translator is reachable from China, the instinct is to treat this as solved. It is not — and the honest fix runs the opposite way from “make the offshore endpoint work.” It is to keep China-origin content’s translation in-country.

There is a real, documented in-country option here, which many foreign MT services cannot offer. Microsoft’s sovereign-clouds reference states plainly that “Translator is currently deployed in the China cloud,” through the api.translator.azure.cn endpoint, on Microsoft Azure operated by 21Vianet (世纪互联) — “a physical and logical network-isolated instance of cloud services located in China.” That is a genuine data-resident path. But it is a separate cloud, not a region toggle: it is its own account at portal.azure.cn, and to use it you need, in Microsoft’s words, “a Chinese legal entity, Internet Content provider (ICP) license, and physical presence within China.” A different partition is a lawful in-country option, not automatic compliance — you still own the PIPL impact assessment, the consent handling, and confirming the specific Translator features and SLAs you depend on are carried there. Where that footing does not fit, the alternative is a licensed in-country machine-translation or localization service that keeps China content on a domestic path. On either route, minimize or pseudonymize personal information in strings before any offshore call, and keep Azure’s no-trace and model-training-off behavior in place for whatever you cannot keep in-country. None of this is a tunnel that ships the content offshore anyway — it is a change of where the translation happens. This is a risk map, not a verdict: settle the specifics with counsel.

The lawful path — map, localize, deliver

There is a lawful way to translate mainland-China content with Microsoft Translator, and it has a clear shape: the content is translated from inside China on a footing that keeps it resident, and the China-facing app that consumes the translations is itself filed and delivered in-country. The part 21YunBox owns is that footing, and it is more than advice. Our China team does three things. We map what content flows to the translation service, what personal, sensitive, or confidential information it carries, where Azure processes and (for Custom Translator) stores it, and where you lack a lawful basis for the cross-border leg. We localize onto a data-resident path — the 21Vianet-operated Azure Translator where it fits, or a licensed domestic machine-translation service where it does not — and help you minimize or pseudonymize personal information in strings before anything offshore is called, so China content’s translation stays in-country in place of a call that would otherwise run abroad. And we deliver the China-facing site or app that consumes the translations in-country on ICP-filed infrastructure — the 21YunBox Optimizer — in front of the stack you already run, with no rebuild and no re-platform.

The result is a translation workflow that runs legally and compliantly for your users in China. 21YunBox never uses or suggests circumvention of any kind — this is a lawful, data-resident in-country path, built on the China cloud Microsoft and 21Vianet already provide, or on a licensed domestic equivalent where that cloud does not fit. 21YunBox is a compliant overlay and partner, not a competitor to the translation vendor.

Get a compliance assessment →

Related reading:

Frequently Asked Questions

Can I use Microsoft Translator (Azure AI Translator) for users in China?

You can reach the API, and Microsoft even runs Azure Translator inside the mainland on the separate 21Vianet cloud — but that is the compliance question, not a speed one. In the public Azure cloud there is no mainland-China region; Microsoft's region table processes the nearest "Asia Pacific" endpoint in "Japan East or Southeast Asia." So translating a China user's content through the default service ships it offshore — a cross-border transfer under PIPL (Articles 38–40: notice, a separate consent, and a transfer mechanism). Azure's no-trace policy limits retention, not the transfer itself. Confirm your exact obligations with counsel.

Does Azure Translator store or train on the text I send?

For standard text translation, no. Microsoft states Azure Translator "doesn't store customer data submitted for translation permanently or at rest," leaves "no record of the submitted text or document in any Microsoft data center," and does not use it to train models; document translation is temporary, then "removed permanently with a hard delete." Two caveats remain: a Custom Translator model is built from the bilingual documents you upload, which are retained in a workspace region (none in mainland China); and no-trace is a retention promise — it does not change that the content crossed the border to be processed, which is the prong PIPL turns on.

What's the lawful, data-resident path for translating China content?

Keep the translation in-country. Microsoft documents Azure Translator as deployed in the 21Vianet-operated China cloud (its own account via portal.azure.cn, requiring a Chinese legal entity and ICP license), and where that footing doesn't fit, a licensed domestic machine-translation service keeps China content on a domestic path. Minimize or pseudonymize personal information in strings before any offshore call, and deliver the China-facing app that consumes the translations on ICP-filed, in-country infrastructure. 21YunBox maps your PIPL and residency exposure, localizes onto the data-resident option, and provides the in-country delivery — no rebuild. It is a lawful in-country deployment, never a way around anyone's terms.