Where Can a Chinese Case Law Corpus Actually Sit? Deployment Geography Under PIPL and the DSL

There is a question that tends to surface around week six of a Chinese legal data evaluation, usually from someone who has not been in the meetings: can this live in our own cluster?

It arrives late because both sides treat it as a compliance formality to be cleared after the commercial shape is agreed. It is not a formality. Where the corpus sits, and where the inference over it runs, determines your latency budget, whether you can fine-tune at all, whether your evaluation runs are reproducible, how many stacks you pay for, and what you are able to promise your own enterprise customers about their queries. Answer it after signature and you will find that some of those decisions were made for you.

This page treats deployment geography as an architecture problem: the statutes in the order they actually bite, the one legal distinction that decides which topologies are open to you, the four topologies themselves with their engineering consequences, and the clauses that pin the answer down in the agreement.

Why this is an architecture decision, not a checkbox

Consider the two ways of getting it wrong, because they fail differently and both are expensive.

If you assume bulk export will be available and it turns out not to be, you rebuild. Retrieval that assumed local disk becomes a network call; an evaluation harness that assumed a frozen local snapshot now runs against a moving remote service; a fine-tuning plan that assumed full text becomes a prompting plan over retrieved passages. None of that is impossible, but all of it is work you scheduled elsewhere.

If you assume in-China residency is mandatory when your actual data and volumes did not require it, you carry a second deployment, a second on-call rotation and a second set of egress costs for the life of the product, plus the organisational friction of running a region your platform team cannot debug in their usual way.

The decision also propagates into the commercial documents. Delivery mode, permitted hosting locations, subprocessor lists and termination behaviour all follow from the topology, and — as covered in the pricing and term-sheet piece — delivery mode is one of the variables that moves the number. Deciding topology after the term sheet means renegotiating the term sheet.

Three statutes, in the order they bite

Most vendor conversations invoke "PIPL" as shorthand for the whole regime. There are three instruments in play and they constrain different things.

Two features of this frame matter more than the citations.

Published judgments are public documents, and publicity does not delete the personal information inside them. The publication rules under which decisions reach the source portal already require certain identifiers to be removed and certain categories of party to be referred to by substitute designations. What survives that process is still, routinely, a document naming a corporate party, a court, a judge, a date, a place and a case number, alongside a recitation of facts. PIPL contemplates the handling of personal information that has already been lawfully disclosed, within a reasonable scope, which is the provision most of this industry is in fact operating under — but that is a permission with conditions attached, not a finding that the data is not personal information.

DSL Article 36 is not an abstraction for a legal AI vendor. Your product is precisely the kind of system a foreign court, regulator or opposing party might one day direct a disclosure request at. If part of your corpus is held in the PRC, that request runs into a rule requiring PRC approval before the data is provided. This is worth naming during design rather than discovering during discovery, and it belongs in the agreement — see the clause list below.

The distinction that decides your topology

Before comparing architectures, settle one thing, because a great deal of engineering rests on it and buyers routinely collapse it into a single word.

De-identified information cannot be attributed to a particular individual without additional information — but that additional information exists somewhere, so the data remains personal information and remains inside the law's scope. Anonymised information cannot be used to identify anyone and cannot be restored, which places it outside the definition entirely.

The gap between those two is where most "our corpus is anonymised" claims live. Redaction at the source portal is applied to individual documents at publication time by rules aimed at protecting specific categories of person. It is not a guarantee about your derived corpus, for three reasons:

• Non-natural persons are largely untouched. Company names, law firm names, courts and judges usually remain, and for commercial litigation that is most of the identifying content.
• Quasi-identifiers survive. Dates, districts, amounts, industry descriptions and case numbers are individually innocuous and jointly distinctive.
• Joining raises the risk. A single redacted document may be non-identifying while the instance chain around it — first instance, appeal, enforcement — is not, and building those chains is exactly what a good corpus does.

The practical instruction: ask for the redaction specification field by field, with the rule applied to each, and test a sample against it. This is a measurable property of a delivery, which means it belongs in the same acceptance pass as coverage and completeness — the protocol in the vendor verification piece extends naturally to cover it. A supplier who answers with the adjective rather than the specification has not done the work.

Four topologies

A — full residency is the simplest legally and the most awkward operationally for a foreign team. You get no cross-border transfer question for the corpus itself, and you inherit a region your platform team may not be able to observe with existing tooling, plus a model-availability question: the models you have standardised on may not be servable there in the form you use elsewhere. It is the right answer when your buyers are PRC entities, and an expensive answer when they are not.

B — query-only is where most first releases land, and it is worth being precise about what it does. It does not make the border disappear: whatever a response contains has crossed it, and is assessed on its contents. What it changes is volume and shape. There is no bulk copy in a foreign cluster, each transfer is incremental and logged, and the scope is far easier to describe precisely in a filing. The costs are per-query latency on every request, a hard dependency on the link, and the loss of local full-text training and analytics. If your product cites judgments rather than learning from them, that trade is usually correct — the interface shape is covered in the API structure walkthrough and the MCP server piece.

C — offshore corpus is what your ML team wants, because everything downstream becomes ordinary: local disk, reproducible snapshots, frozen evaluation splits, fine-tuning as normal. It is also the topology that raises the transfer question in its fullest form, at volume, and it is the one where the de-identification analysis above does the most work. It is available in practice for suitably prepared corpora; it is not available by assertion, and a supplier who offers it without discussing the mechanism has skipped a step.

D — hybrid keeps raw text in the PRC and moves only derived artefacts — embeddings, indices, aggregates, structured field subsets — offshore. This can be a genuinely good design. It is also the topology most often built on a bad assumption: that a vector is a neutral numeric object outside the scope of everything. Treat a derived artefact as inheriting the classification of its source unless you hold a specific written argument that it does not. Embeddings support re-identification and permit partial reconstruction, and "we only exported the vectors" is a position you would need to defend, not one you can assert. Build D on an explicit analysis of what each artefact encodes, agreed with the supplier.

The transfer routes, and whose problem they are

PIPL Article 38 provides three routes for moving personal information out of the PRC: a security assessment organised by the cyberspace administration, certification by a qualified body, and a standard contract concluded with the overseas recipient and filed. Provisions issued in March 2024 layered exemptions and volume thresholds over those routes, so that lower-volume, non-sensitive transfers may fall outside the mechanisms entirely while larger or more sensitive ones escalate toward assessment. Free trade zones may operate their own negative lists, with the effect that the applicable rule can depend on where in the PRC the exporter sits.

Two consequences for a buyer.

You are usually not the filer. The obligation sits with the exporting party inside the PRC. So the productive question is not "is this compliant?" — to which the answer will always be yes — but rather: which mechanism have you completed, for which categories of data, when, and can our counsel see the filing reference? That question has a verifiable answer or it does not, and either way you have learned something.

"It's public data, so none of this applies" is a red flag, not a shortcut. Lawful prior disclosure is a real basis with real conditions; it is not a finding that the material stopped being personal information. A supplier who reaches for it as a conversation-ender is showing you how they will handle the next hard question too.

Worth noting on our own side: we hold data-processing and cross-border arrangements appropriate to the delivery modes we actually offer, and we would rather walk your counsel through what those cover — and what they do not — than have this page assert a blanket answer. The categories in the licensing guide set out the general shape.

What to put in the agreement

Topology is only settled when it is written down. Eight clauses, roughly in the order they cost money when missing:

1  permitted hosting locations   named regions; whether they may change, and on what notice
2  delivery mode                 bulk / API / in-China only — tied explicitly to clause 1
3  exporter of record            which party, which Art. 38 mechanism, filing reference
4  de-identification spec        field-by-field rules; who bears re-identification risk
5  foreign disclosure orders      process when a foreign court or regulator demands data
                                 held in the PRC (DSL Art. 36 / PIPL Art. 41 collide here)
6  subprocessors                 your cloud regions and vendors, named and amendable
7  change-of-law                 what happens if a mechanism lapses or a catalogue changes:
                                 cure period, suspension, refund, migration right
8  termination                   deletion or return, per region, with evidence

Clause 5 is the one commercial teams skip and litigation teams later wish they had. Clause 7 is the one that decides whether a regulatory change is a joint problem with a defined process or a unilateral service suspension you find out about by monitoring alert.

A short decision path

Do your own customers contractually require in-country processing?
  yes -> A
Do you need raw full text locally for training or full-corpus analytics?
  yes -> C, or D if the export analysis does not support raw text
  no  -> B for the first release; revisit when the training case is concrete
Building vector search you must host yourself?
  -> D, with a written analysis of what the embeddings encode
Not sure yet?
  -> B, and negotiate a migration right into clause 1 now rather than later

The last line is the practical advice for most teams. B is reversible, ships soonest, and keeps the harder analysis for a point where your volumes and use case are facts rather than forecasts — provided you buy the right to move, in writing, while you still have negotiating leverage.

What this page does not settle

It does not tell you which topology your regulator, your customers' procurement teams or your own general counsel will accept. Important-data catalogues are sectoral and evolving; transfer thresholds have been revised before; free trade zone lists differ; and your sector may carry rules of its own that sit on top of everything described here. Nothing above substitutes for a PRC counsel memo and your own impact assessment.

What a supplier can honestly offer is narrower and more useful than a legal conclusion: which delivery modes they actually operate, what the records contain field by field, what the redaction rules are, which mechanism covers which categories, and what the agreement will say. For a 160M+ record corpus of publicly available PRC judgments, those are answerable questions with documents behind them. Ask for the documents. A supplier's willingness to put the geography question in writing, before a contract exists, is the most informative signal available at this stage.

Upstream and downstream of this decision: license versus scrape covers build-versus-buy, the source portal's robots.txt read line by line matters before anyone budgets a crawler, the corpus preparation piece covers what happens once the data is where it is allowed to be, the delivery-model comparison covers the commercial shape, and the 2026 market overview sets the landscape.