China AI Export Controls: What DeepSeek’s Clearance Means

1. Data used to train models

The first control area is data. The account says the proposed rules would bar exports of large models trained on China's core data and restrict models trained on important data, regardless of model size. The source doesn't give a full definition of either category, which leaves a real open question for companies: how will "core" and "important" data be classified in practice?

That's more than a count of parameters. Businesses may need to track where training data came from, whether it falls into a regulated category, and how it connects to the specific model they plan to export. If a model went through multiple training stages or incorporated work from several teams, tracing that history could become an operational issue. The source also doesn't say what documentation would satisfy registration requirements, so companies shouldn't assume there's a simple checklist that's ready to follow.

2. Sensitive applications and AI agents

The second area is use. According to the account, agents that perform above a stated threshold could face restrictions. It says agents built mainly for critical information infrastructure, defense, or core government affairs may be banned from export.

This isn't just about what an agent can do on a benchmark. In a real product, an agent's role depends on its tools, permissions, deployment setup, and the types of decisions it's allowed to make. A general-purpose agent could look "low risk" in one deployment (say, office tasks) and become "sensitive" in another (for example, if it's granted access to operational systems). The account doesn't explain how regulators would draw those lines or how the performance threshold would be defined.

For product teams, this is a reminder to document intended use and system boundaries clearly. A label on a product page usually isn't enough to explain how an agent actually operates. A better approach is to spell out what data the system can access, which actions it can take, when human approval is required, and what customers are expected to use it for.

3. Computing technology and capability thresholds

The third area is computing power. The account says AI chip design and high-speed connections used in large computing clusters appear on the proposed list. These are enabling technologies - not just finished AI models - so the controls could matter for the infrastructure and engineering ecosystem around model development.

The post also includes numeric thresholds for large models: training compute above 10²⁶ floating-point operations, more than two trillion parameters, or capabilities ranked in the global top ten. The account presents these as alternative ways to define "large." But the source doesn't provide the full catalogue text, definitions, or measurement procedures, so those numbers shouldn't be treated as a complete compliance test by themselves.

A threshold can look exact while still leaving practical questions unanswered. Which training runs count toward the compute figure? How is "capability" assessed? What happens when a model is updated, distilled, or combined with other components? Businesses will need the final text and the implementing guidance to answer those questions.

Open source, overseas infrastructure and collaboration

The post says open-source technology gets automatic licensing, described as immediate reporting and export. It also says the same treatment applies to Chinese companies' own computing centers abroad, overseas chip tape-outs, joint research, and work on international standards. It claims that technology already made public through open-source releases or academic papers would fall outside the controls.

This suggests the proposal isn't meant as a blanket restriction on international research or every transfer of technical knowledge. But "automatic licensing" shouldn't be read as "no obligations." The account's wording emphasizes reporting and export - so even when a license is handled automatically, there may still be paperwork and process requirements. Companies should confirm what must be reported, when, by whom, and in what form once authoritative guidance is available.

The post also says exports tied to cooperation among members of the World AI Cooperation Organization would receive more support. That's a stated preference, not a guarantee that every project involving a member organization would automatically qualify for an exemption or approval.

A service can still involve controlled components

The service-versus-technology distinction is useful, but it doesn't eliminate every edge case. A SaaS product could be built on top of a model, training method, chip design, or other technology that has separate export implications. A product can also change over time: a lighter, customer-facing service today could later include downloadable weights, on-premises deployment, custom model transfers, or access to technical materials.

So the reasonable takeaway isn't that "all overseas business is cleared." It's that the account describes several common commercialization paths as outside the definition of a technology export, while some underlying technologies could still require registration or licensing. Product teams need to understand both layers: what the customer receives and what technology the company transfers to deliver that service.

The business model changes the exposure

Selling a hosted model through an API is a different setup from distributing weights so customers can run the model themselves. In the first case, the company is mainly providing service access; in the second, the company is transferring model files. Licensing an agent to operate inside a customer's environment may raise yet another set of questions, particularly if the agent is designed for a sensitive use or performs above a specified threshold.

None of this means one business model is automatically "safe" and another is automatically "restricted." It means the analysis should follow the actual product and transaction, not just a company's label or marketing description. A sensible first pass is an inventory like this:

• What exactly crosses the border: service access, model weights, source code, design files, technical support, or research materials?
• What data was used to train or adapt the model, and can the company document how it came to be?
• What does the system do in the customer's deployment, including what tools and permissions an agent gets?
• Which infrastructure or chip technologies are part of what's being transferred?
• Is it a one-time export, an ongoing service, a research partnership, or an overseas operation run by the company itself?

These questions don't replace legal review. They just help make that review more targeted, so product, engineering, sales, and compliance teams are working from the same description of what the business is actually doing.

Licensing is a route, not a guarantee of no friction

The account quotes lawyer Liu Hongmei of Beijing Dacheng Law Offices saying restricted technologies can go abroad with a license and that this wouldn't derail companies' overseas plans. It also says lawyers involved in consultations reported that some control points shifted after the first draft and that many concerns raised by companies were reflected in the published version.

That's useful context, but it shouldn't be treated like a promise that licensing will be quick, routine, or commercially irrelevant. A license can still require preparation, review time, documentation, and changes to a product or delivery plan. The source doesn't provide processing timelines, approval criteria, or the final catalogue language.

For businesses planning international launches, the practical implication is straightforward: treat licensing as a possible workstream and build enough flexibility to deal with it. That could mean keeping service access separate from weight distribution, maintaining records about data and model versions, and identifying which features depend on technologies that might be listed. Those are sensible preparation steps - not claims about what the final law will require in a specific scenario.

Use a staged review, not a blanket reaction

A workable approach is to break the review into four stages:

1. Identify the activity. Distinguish hosted access, distribution of models or code, overseas research, infrastructure transfers, and what happens when the customer deploys the system. These may not be treated the same way.
2. Map the technology. Record model versions, training and adaptation processes, compute dependencies, chips, agent capabilities, and the actual items being transferred. Don't rely on a vague label like "AI product."
3. Check the relevant categories. Compare the activity against the final catalogue and official guidance when available. The account's summary is a starting point, not the full legal text.
4. Set a decision point. Decide which launches can proceed based on your current understanding, which need specialist review, and which require a license or an alternative delivery plan if the final rules make it necessary.

The goal isn't to build a massive compliance program before the rules are final. It's to avoid finding out at launch that nobody can answer basic questions about where the model came from, what you're transferring, or how the system will be used.

Keep the policy signal separate from the legal position

There are three layers to keep separate. First, there's the proposed catalogue and its status. Second, there's the account's interpretation of how officials expect the controls to work. Third, there's how your specific product and transaction would be assessed. Mixing those layers leads to overconfidence in either direction.

Companies should monitor the published catalogue, the consultation outcome, and any implementing instructions. They should also keep a record of what assumptions drove launch decisions - especially when those assumptions depend on interpretations of "core data," "important data," performance thresholds, or automatic licensing. If the rules change or a regulator clarifies a term, the company can then re-check which products and plans need another look.

The broader lesson will sound familiar to anyone working in regulated technology: compliance is easier when your product architecture and business model are clear. If you can't explain whether you're providing access, exporting technology, enabling a sensitive use, or transferring infrastructure know-how, it's hard to make a reliable call about what the rules require.