AI Tech Exports Now Need Registration First: 23 of 40 Items on China's Draft Control List Are AI
On October 16, 2026, China's MOFCOM and MOST issued Announcement No. 48, proposing to add 40 technologies to the export control catalogue — 14 banned, 26 restricted, AI taking 23 — while launching pre-export registration covering in-progress deals too. What does it mean for vibe developers and outbound teams?

On October 16, China's Ministry of Commerce (MOFCOM) and Ministry of Science and Technology (MOST) jointly issued Announcement No. 48 of 2026, opening a public consultation on revising the Catalogue of Technologies Prohibited and Restricted from Export — and, in parallel, imposing interim pre-export registration on the technologies concerned. Of the 40 technologies proposed for addition, artificial intelligence alone accounts for 23: "AI-driven malicious code generation and mutation" is proposed for the export ban list, while "AI-assisted vulnerability mining" is proposed for the restricted list. It is the most explicit list-based move yet targeting AI technology exports.
A quick framing first, so this doesn't get confused with two other stories on this site. Our piece on China's "AI+" guidelines is industrial policy — how the state plans to boost AI development; it's about growth. Our piece on the first enforcement of the EU AI Act is extraterritorial regulation — OpenAI and Anthropic getting fined in Europe; it's about complying on someone else's turf. This story is an export-control catalogue revision by MOFCOM plus MOST, and it governs the "exit gate" for technology: whether your model, your agent, or your training methods can be sold abroad, licensed abroad, or "go out" together with a change of company control. Three documents, three authorities, three different logics.
1. What Announcement No. 48 actually says
Issued by MOFCOM's Bureau of Security and Control, the announcement cites the Foreign Trade Law and the Regulations on Technology Import and Export as its legal basis. Its substance compresses into three points. First, 40 technologies are proposed for addition: 23 in AI (large models, agents, compute clusters, information processing), 5 in biopharma (cell and gene therapy, small nucleic acid drugs, pathogenic microorganisms), and 12 in photovoltaics (polysilicon, wafer, and cell manufacturing) — with the PV scope also covering key and core equipment embodying those technologies.
Second, the 40 items follow a three-tier scheme: 14 proposed for the export ban, 26 for export restriction, plus facilitation measures for specified scenarios. The spokesperson's Q&A named examples — the proposed ban covers AI-driven malicious code generation and mutation, indigenous cell and gene therapy process platforms, and perovskite/tandem cell module production technology; the proposed restrictions cover AI-assisted vulnerability mining, indigenous novel target discovery and validation for general-purpose cell and gene therapies, and polysilicon engineering technology with single-line capacity of 30,000 tonnes per year or more. Note the word "proposed": the final list will follow the formal revision.
Third, interim pre-export registration starts immediately: from the announcement date until the revised catalogue formally takes effect, operators exporting listed technologies must first register on MOFCOM's unified business-system platform for technology trade administration (ecomp.mofcom.gov.cn). Exports already underway but not yet completed are also covered.
2. The spokesperson's Q&A: five lines worth underlining
Beyond the announcement itself, MOFCOM's spokesperson answered press questions the same day, and that transcript carries even more signal. Five lines deserve a close read from anyone building with AI.
First, on why AI is being controlled: technologies like "AI-autonomously-driven malicious code generation and mutation" could be used to attack critical information infrastructure, defense industry, and core government systems, or to bypass national security defenses — and "if acquired by non-state actors or malicious entities, could endanger national security and the common security of humanity." The crosshairs are clear: not large models per se, but the combination of "AI plus offensive cyber capability." That also explains the tiering — AI-driven malware generation and mutation goes to the proposed ban, while AI-assisted vulnerability mining lands on the restricted list. One is weaponization; the other is dual-use.
Second, on open source: for "open-sourcing of AI technologies, Chinese companies building and operating their own compute centers abroad, taping out chips overseas, conducting joint R&D using overseas resources, and participating in international standard-setting," automatic licensing and other facilitation measures apply, essentially achieving "file-and-go." Technologies that have already entered the public domain through open source or published academic papers are proposed to be excluded from export administration altogether. This is the friendliest passage in the whole document for developers: the open-source ecosystem is not the target of control — it is explicitly encouraged.
Third, on how to judge large-model "going global": "the core test is whether restricted technology is transferred from within China to abroad." Then came a three-tier answer: overseas localized deployment of restricted technology falls within administration; deployment on a company's own overseas cloud, being relatively controllable, may use automatic licensing; but providing API calls, app/web interactions, SaaS applications, or lightweight on-device deployment built on restricted large models does not fall within large-model technology export administration. In plain terms: selling services via API is fine; moving model weights to a foreign data center triggers the process.
Fourth, on framing: "Since 2001, MOFCOM together with MOST has revised the catalogue multiple times — adding and removing, controlling and liberalizing — it is an established practice. This revision is likewise routine technology-trade administration, conducted in accordance with laws and regulations, and does not target any specific country, region, or entity." Plus: "major economies all implement export controls to varying degrees." The subtext: this is not a bolt from the blue; it is 20-plus years of list maintenance.
Fifth, on dynamic adjustment: "MOFCOM and MOST will dynamically adjust the catalogue's scope in accordance with the law, promptly removing technologies that are no longer advanced." The list is not add-only — a necessary reassurance for practitioners fearing "once controlled, forever controlled," though removals have historically moved far slower than additions.
3. For vibe developers and global-going teams: understand "registration" first
Many people tense up at "ban/restriction," but for most vibe developers and outbound teams, the binding part of this announcement right now is not the ban — it is the registration. It is an interim measure, but it has been in effect since October 16, the announcement date, and runs until the revised catalogue formally takes effect.
Which situations require registration? The announcement lists four: (1) transferring technology ownership abroad, such as IP assignment; (2) licensing domestic technology for use abroad, such as IP licensing; (3) a change of the domestic technology's owner or actual controller to an overseas entity — outbound founders should note this one especially, since an overseas acquisition or a VIE restructuring that changes actual control could trigger it; and (4) other situations MOFCOM specifies by notice — a catch-all.
What gets filed? Basic information on the exporter and the recipient, destination country or region, the technology and its intended use, the expected export value, and so on, per the system's requirements. Multiple technologies exported to the same recipient in one go may be filed together. The spokesperson added that exports of listed PV key and core equipment must all be registered, and that companies with questions can consult MOFCOM and MOST directly.
The timetable is equally clear: public consultation runs October 16 to November 15, 2026, via email (jinxianmulu@mofcom.gov.cn), fax (010-65197565), or letter to the Bureau of Security and Control, MOFCOM, No. 2 East Chang'an Avenue, Beijing (postal code 100731). After November 15, the authorities will consolidate feedback, finalize the revision, and the interim registration will give way to routine catalogue administration.
4. "Open-source first and you're in the safe zone"? The key word is "already"
The most-quoted line in the announcement is probably this: technologies that have "already entered the public domain through open source, published academic papers, and the like" will not be brought under administration. Many people's first reaction: if I open-source my model first, am I in the safe zone? The instinct points the right way, but the devil is in the word "already."
The announcement's wording covers technologies already in the public domain — i.e., already public before the controls land. Here open source acts as a timestamp: proof that the technology was humanity's shared knowledge before it became a control target. For teams with a long open-source track record, that is genuinely good news: years of public work automatically earn a kind of regulatory "grandfather clause."
But three boundaries need stating honestly. First, "already open" is not "open whenever you like": if what you hold is a core technology with specific control thresholds (the kind the annex spells out with parameter cutoffs), a rush to open-source after the draft's publication may or may not be recognized as "having entered the public domain" — don't play judge yourself. Second, what you open-sourced is the technology itself; the undisclosed weights, data recipes, and engineering know-how inside your commercial version may still fall under the list — the open repo and the commercial product are two different things. Third, "not brought under administration" does not mean "no process at all": the spokesperson said open source and similar scenarios get "automatic licensing and other facilitation measures, essentially file-and-go" — "file" is still filing; the procedure exists, it is just near-instant.
So the more precise formulation: open source is not a backdoor for after-the-fact rescue; it is a compliance asset to be planned ahead. The real takeaway for vibe developers: if you are building in directions the list touches (large models, agents, compute orchestration), put "whether and when to open-source" into the product roadmap early, and decide it with counsel — not when you are already packing for abroad.
5. Our take: targeted controls, not decoupling — and registration is the real variable
Reading the announcement and the Q&A together, our judgment comes in three lines.
First, this is "control and liberalize" in calibrated measure, not decoupling. Three textual supports: the scope is "precise and limited" — most proposed items carry specific technical thresholds, and "products manufactured using the relevant technologies are not within the scope of administration" — what is controlled is technology transfer, not merchandise trade; the facilitation scenarios are enumerated one by one, tiered and categorized; and the catalogue adjusts dynamically, with laggard technologies to be removed. Add the "does not target any specific country, region, or entity" line, and the document positions itself as conventional export control "with reference to international practice." Believe it or not — but textually, it leaves the "liberalize" door wide open.
Second, for outbound teams, the biggest practical variable is "registration," not the "ban." Of the 14 proposed bans, the one nearest an ordinary vibe developer is "AI-driven malicious code generation and mutation" — teams building apps, agents, or calling model APIs will basically never touch that line. Registration is different: it covers all four export scenarios for all 40 listed technologies, "exports already underway but not yet completed" must catch up, and it took effect on the announcement date. If you are negotiating a contract to license a model to an overseas customer, or scoping an overseas localized deployment, that deal has in principle been in registration's field of view since October 16. Outbound teams should do a "technology export profile" now: check each of your technologies against the annex list (per the officially published Annex 1), then self-check against the four scenarios.
Third, the bright-line test for large-model going-global is actually reassuring for most people. "API calls, app/web interactions, SaaS applications, and lightweight on-device deployment do not fall within large-model technology export administration" — meaning the vast majority of AI apps going abroad on API calls and SaaS subscriptions are outside this round of controls. What triggers the process is "moving restricted technology's weights and capabilities abroad" via localized deployment — and even then, deploying on your own overseas cloud can go through automatic licensing. The line the policy draws falls exactly between "selling services" and "moving technology."
One last reminder: what we see now is still a draft for comment, not the final text. Until November 15, anyone can submit comments through the email, fax, or letter channels in the announcement — include your contact person, organization, and contact details, with an official seal for organizational submissions. If you think a threshold is mis-set or a scenario deserves facilitation treatment, this is the window to speak. Once the formal revision takes effect, the window closes.
Sources and verification note
This article is based on the Beijing Daily's full reprint of the Xinhua wire text (October 16, 2026, containing the full "MOFCOM/MOST Announcement No. 48 of 2026") and the MOFCOM spokesperson's Q&A as reprinted by Sina Finance. One honest caveat: the announcement page on MOFCOM's official website (mofcom.gov.cn) could not be opened directly for verification at the time of writing, so readers should refer to MOFCOM's official channels for the authoritative text of Annex 1 and Annex 2. The 14/26 split and the specific technology examples cited here all come from the publicly released spokesperson Q&A.
Comments (0)
Sources
Related articles

LSCBench (arXiv, Oct 10) puts 6 frontier coding agents through 450 tasks built from 150 real vulnerabilities: functional pass rates hit 91.3%, but the "functional AND secure" rate tops out at 25.1%. The tasks never mention security — exactly how vibe coding prompts look.

On October 15, Brave's official blog announced end-to-end encryption plus verifiable confidential computing for Leo: select the open-weight GLM 5.3 Flash and your prompt is encrypted on-device with Oblivious HTTP, relayed through Brave's open-source AI Gateway (hiding your IP from NEAR AI), and decrypted only inside a hardware-attested Nvidia enclave. Brave, NEAR AI, and the cloud hoster all cannot see the plaintext.

Step-5's BF16 open weights staged a photo-finish on October 15: Forkast still saw a 404 at 01:55Z while HF logs show the weights landed at 01:31Z — with a custom license. A wire landing is not a kept promise: vendor-promise dates still can't anchor your schedule.