Since 17 June 2026, when Z.ai published GLM-5.2's weights under an MIT licence, UK compliance teams have been fielding a question that sounds new: can we use a frontier Chinese AI model without a data-protection problem? Nothing in UK law changed in June, and that is the point — UK GDPR's international transfer regime predates GLM-5.2 and applies to it without amendment. What changed is that a model worth the analysis now exists: one that beats GPT-5.5 on serious coding benchmarks at a sixth of the price, as we set out in our decision guide to open-weight frontier models.
The coverage so far has compressed the issue into a slogan — "China data risk" — that is true but unhelpful. It does not tell a data protection officer what to assess, a CISO what to block, or an engineering lead what to say to a team that wants the tool. This brief is the practical version.
The short version: for personal data, Z.ai's direct API is close to unusable for UK organisations — not because the paperwork is missing, but because no transfer mechanism to China survives an honest risk assessment. For data with no personal element, the API is a commercial judgement, not a legal one. And the open weights, run on infrastructure you control, take the transfer question off the table entirely — which is why the API and the weights should be governed separately.
What Is Actually on the Table
Three facts frame the analysis, and two cut against the headlines.
- The service. Z.ai sells API access to GLM-5.2 at $1.40 per million input tokens and $4.40 per million output, with coding plans from around $3 per month. Requests go to infrastructure operated by a Chinese company under Chinese jurisdiction.
- The paperwork. Z.ai publishes a privacy policy and Data Processing Addendum under which it acts as processor and the customer as controller, and its documentation states that GLM-5.2 API traffic is not retained and not used for training. On paper, this is comparable to what Western AI vendors offer. Anyone claiming Z.ai simply has no enterprise data terms has not read them.
- The weights. The same model is downloadable under an MIT licence. Files, not a service: no telemetry, no connection to Z.ai, no data flow to assess.
That is the real tension: the problem with the API route is not missing contractual protections, but what those protections are worth against the legal environment the provider operates in. UK transfer law forces you to answer exactly that question, in writing.
Who This Affects, and Through Which Door
Every employer with developers is affected first and least deliberately. A $3-per-month coding plan is an expense-claim decision, not a procurement one, and source code may already be leaving through it. For this group the question is not "should we?" but "are we already?".
Product and platform teams considering the API for customer-facing or internal workloads carry the full transfer analysis below, because prompts in production systems almost always end up containing personal data, whatever the design intention was.
Organisations weighing self-hosting or Western-hosted deployments are affected most favourably: the analysis below largely dissolves for them, replaced by ordinary processor due diligence or by the supply-chain governance we cover in the decision guide.
What Compliance Actually Looks Like
The analysis runs in a fixed order, and the first step decides most of it.
First: is personal data actually in the payload? Not in the policy — in the payload. Source code itself is usually not personal data, but repositories are rarely just source code. Git history carries author names and email addresses. Comments name colleagues. Test fixtures and configuration files have a long record of containing real customer data that was never sanitised. A production chat or support workload fails this test by construction. Treat "there is no personal data in our prompts" as a claim to verify, not an assumption to grant.
If personal data is present, the transfer regime applies in full. The UK has made no adequacy regulations for China, so this is a restricted transfer: it needs an appropriate safeguard — in practice the International Data Transfer Agreement or the EU standard contractual clauses with the UK addendum — plus a transfer risk assessment, as set out in the ICO's international transfers guidance.
The risk assessment is where the route fails. It must weigh whether contractual safeguards hold up against the destination country's legal system, and China's National Intelligence Law 2017 obliges Chinese organisations to support state intelligence work, with no independent redress a UK assessment can point to. A no-retention clause is a genuine mitigation; it is not an answer to a law that sits above the contract. The compliant path for personal-data workloads through Z.ai's direct API is therefore so narrow that most organisations should treat it as closed — a conclusion your DPO will reach in writing, slowly and expensively, if you ask them to run the assessment anyway. The direction of UK enforcement, which we examined in our analysis of the ICO's 2026 guidance and Parliament's AI inquiry, gives no reason to expect it to soften.
If no personal data is present, UK GDPR has nothing to say. This surprises people on both sides of the argument. There is no general UK law against sending your own commercial data, including source code, to a Chinese processor. The restraints here are commercial and security judgement: code reveals architecture, frequently embeds credentials, and constitutes the asset itself. Sending it to any external endpoint deserves a decision; the jurisdiction raises the stakes of that decision without changing its legal character.
Now the part the slogan gets wrong in the other direction. US endpoints are not residency-clean either. US authorities can compel access to data held by US providers, wherever it is stored — so if the test is "no foreign state can reach our data", the incumbent American APIs fail it too. The legal difference is real but narrower than procurement checklists assume: the UK-US Data Bridge gives transfers to certified US organisations a paved lawful road, and US law offers redress mechanisms an assessment can cite. For China there is no bridge and no equivalent redress. The honest statement is not "US safe, China dangerous" — it is that UK law has built a road for one and not the other. An organisation whose threat model excludes foreign government access altogether has only one option, and it is not an API.
That option is the weights. Run GLM-5.2 on infrastructure you control and there is no transfer to assess. What replaces the residency question — provenance verification, behavioural evaluation, workload isolation — belongs to supply-chain governance rather than data protection, and connects to the argument for UK-controlled AI capability we made about the government's sovereign AI programme. A Western-hosted deployment of the open weights sits between the two: ordinary processor due diligence, no Chinese endpoint, and most of the price advantage intact.
What to Do Before This Becomes an Incident
- Find your existing exposure this week. Search expense claims for Z.ai subscriptions and network egress for its API endpoints. The most likely GLM-5.2 data flow in your organisation predates any decision you have made about it.
- State a position in the acceptable-use policy. Name the category — Chinese-jurisdiction AI endpoints — not the product, and say what is permitted with what data. Silence is currently being interpreted as permission, one developer at a time.
- Classify the workload before anyone runs a transfer assessment. The personal-data question decides which analysis applies. Ten minutes with the actual payload saves your DPO a six-week assessment that was never needed — or triggers the one that was.
- Route legitimate demand somewhere sanctioned. If the capability case is real, a Western-hosted deployment of the weights answers it without the transfer question. Developers stop using side doors when the front door is good enough.
- Write the policy for the category. GLM-5.2 is the occasion, not the subject. The same analysis will apply, unchanged, to the next open-weight release — the framework in our decision guide is built to be reused.
We publish pieces like this regularly — no gate, no sales sequence. Get new posts by email.
Frequently asked questions
Is it legal for a UK company to send data to GLM-5.2's API?
It depends on the data. The UK has no adequacy regulations covering China, so sending personal data to Z.ai's API is a restricted transfer under UK GDPR: it requires an appropriate safeguard such as the International Data Transfer Agreement plus a transfer risk assessment, and China's National Intelligence Law 2017 makes that assessment difficult to pass. Data with no personal element — such as sanitised source code — faces no UK GDPR barrier at all; sending it is a commercial and security judgement rather than a legal one.
Does Z.ai offer a data processing agreement for enterprise API use?
Yes. Z.ai publishes a Data Processing Addendum under which it acts as processor and the customer as controller, and its documentation states that GLM-5.2 API traffic is not retained and not used for training. The paperwork is genuinely comparable to what Western AI vendors offer. The transfer risk assessment question is not whether the terms exist but whether they are enforceable against a company operating under Chinese jurisdiction, including the National Intelligence Law 2017 — and that is where UK organisations processing personal data tend to get stuck.
Does self-hosting GLM-5.2 solve the data-residency problem?
For data residency specifically, yes — completely. The MIT-licensed weights are inert files with no telemetry; run them on infrastructure you control and no data crosses any border, so there is no transfer to assess. Self-hosting replaces the data-flow question with different governance obligations — verifying the provenance of the weights, evaluating model behaviour against your policies, and isolating agentic workloads — but the UK GDPR international transfer regime simply does not apply.
Is source code personal data under UK GDPR?
Source code itself usually is not, but what surrounds it often is. Git history contains author names and email addresses; code comments name colleagues; test fixtures and configuration files frequently contain real customer records that were never properly sanitised. A repository sent wholesale to any external API is therefore rarely free of personal data in practice. Before treating a coding workload as outside UK GDPR's transfer rules, verify what is actually in the payload rather than what is supposed to be.
Are US AI APIs any different from Chinese ones for UK data transfers?
Legally, yes — and it is worth being precise about why. US authorities can also compel access to data held by US providers, so neither route keeps data purely within UK jurisdiction. The difference is that the UK-US Data Bridge gives transfers to certified US organisations a lawful basis without case-by-case risk assessments, and US law offers redress mechanisms that a UK transfer risk assessment can point to. No equivalent bridge exists for China. The honest framing is not that US APIs are risk-free but that UK law provides a paved road for them and none for Chinese endpoints.
← All posts