In cross-border compliance discussions among AI companies, “technology export” and “data export” are often treated as one topic. In practice the confusion produces two kinds of error: having completed a data export security assessment, a company assumes technology export is covered; or having filed a technology export registration, it assumes data flows are settled too. They are two separate compliance tracks, with different objects and different triggers, and neither substitutes for the other.
The objects are not the same
Technology export control governs the technology itself. Its basis is the Foreign Trade Law and the technology import and export regulations, and it covers transfers of technology ownership, technology licensing, and changes in the ownership or actual controller of domestic technology to an offshore entity. The unit of analysis is the technology; the focus is ownership and authorisation to use.
Data export control governs data. Its basis is the Data Security Law, the Personal Information Protection Law and implementing rules, and it covers the provision of personal information and important data outside China. The unit of analysis is the dataset; the focus is the rights of data subjects and national security.
In a single project the two often happen together, but the analysis starts from different points. Model weights as technology, licensed across the border, are a technology export question. Personal information generated during inference and transferred abroad is a data export question. One transaction, two sets of filings, two regulators.
A comparison
| Dimension | Technology export | Data export |
|---|---|---|
| Object | The technology (ownership, licensing, scope of use) | Personal information and important data |
| Main basis | Foreign Trade Law; technology import and export regulation; the catalogue | Data Security Law; PIPL and implementing rules |
| Triggers | Transfer of ownership; licensing for use abroad; change of owner or controller to an offshore entity | Providing personal information or important data abroad in prescribed circumstances |
| Authority | Commerce authorities | Cyberspace administration |
| Nature | Prohibited items cannot be exported; restricted items need a licence; others require contract registration; interim registration during the consultation period | Security assessment, standard contract filing, or certification |
| Timeline | Licence measured in months; registration faster | Security assessment usually longest; contract and certification shorter |
| Consequence of gaps | Delivery cannot proceed lawfully; transaction validity may be affected | Regulatory penalties and remediation |
The value of the table is not the enumeration but the prompt: for any cross-border arrangement, ask “does this trigger” separately on each track.
Four common scenarios
Deploying a model on an overseas server. On the technology side, delivering the model or inference system to an offshore entity may fall within registration or licensing; on the data side, if personal information of users in China is transferred abroad during deployment, the route — assessment, standard contract or certification — must be determined. Both run at once, but they are not filed together.
Sharing training data with an overseas subsidiary. The data side is a classic personal information export scenario. On the technology side, if the domestic entity licenses training methods or toolchains to the offshore subsidiary, that may itself be a technology export. Many companies handle only the first.
Providing APIs or SaaS to overseas customers. On the technology side, cross-border licensing of algorithm or model capability is common; on the data side, the question is whether data is returned from China or whether information about Chinese users is stored abroad. Neither trigger appears in the contract title; both depend on the actual data flow and delivery model.
Offshore restructuring and acquisitions. A change in the owner or actual controller of domestic technology to an offshore entity triggers technology export registration by itself; if the deal also moves personal information or important data across the border, a data export route must be assessed separately. Deal documents are usually detailed on equity and consideration, and thinnest exactly on these two points.
Three misjudgements
First, treating the security assessment as a catch-all. Its conclusion addresses whether data may leave and on what terms; it says nothing about whether the technology is on the prohibited or restricted list or needs a licence. Conversely, a technology export registration does not review data compliance.
Second, assuming open source exempts both. On the technology side, the public-domain carve-out covers technology already in the public domain through open-sourcing or publication. On the data side there is no equivalent exemption: if personal information crosses the border, the data export rules still apply. The tests are not interchangeable.
Third, sequencing them wrongly. A data export security assessment usually takes longer than a technology export registration, while a technology licence may take longer than the delivery plan allows. The sensible approach is to assess both tracks at the same time rather than waiting for one to finish. For route selection on the data side, see our Q&A on data export compliance; for the technology side, see export controls.
Keep the two sets of obligations separate in contracts
Cross-border technology contracts and data processing agreements are often merged into one document, and the clauses merged too — a general undertaking that “the parties shall comply with applicable export control and data protection laws”. In performance, such a clause has almost no operational value.
A workable approach is to allocate the obligations separately. On the technology side: who applies for registration or a licence, by when, and how delivery and liability adjust if approval is refused. On the data side: which route is chosen, who signs and files the assessment or standard contract, and what re-transfer restrictions bind the recipient. The two timetables should be listed separately, each with its own checkpoints in the project plan. For clause design, see commercial contracts; for cross-border data arrangements, see data compliance and GDPR cross-border transfers.
Companies delivering to both the Chinese and EU markets should also compare the GDPR transfer mechanisms with the Chinese data export routes in one table, so that the same dataset is not moved on contradictory legal bases under the two regimes.
This article is based on the technology import and export and cross-border data rules currently in force. It is provided for general information only and does not constitute legal advice. Application depends on the latest rules, guidance and case-specific review by the competent authorities.