Launch of AI Technology Overseas Registration, Business Verification and Preparation for Enterprises

On October 16, 2026, the Ministry of Commerce and the Ministry of Science and Technology issued Announcement No. 48, proposing to add 40 technologies in the fields of artificial intelligence, biomedicine, and photovoltaics to the "Catalog of Technologies Prohibited from Export or Restricted from Export in China," including 23 items in the field of artificial intelligence. The revision of the catalog is currently soliciting opinions, and the temporary registration for the export of the technologies listed in the attachment has already begun.

AI enterprises involved in the technologies listed in the announcement attachment now need to check their overseas business. The registration covers situations such as the transfer of technology ownership to overseas parties, authorization for overseas use, and the change of domestic technology owners or actual controllers to overseas entities. Exports that have already started but are not yet completed are also within the scope of registration specified in the announcement.

For teams negotiating overseas deployment, technology licensing, or equity transactions, the most practical work is to compare contracts with technology deliveries: what exactly is being prepared for delivery, what the other party can do after receiving it, what has already been delivered, and what is still in progress. Legal judgments should start from this list of business facts.

▌ 1. Clarify the Two Time Points

This arrangement includes two components: catalog revision and transitional registration. The opinion solicitation period for catalog revision is from October 16, 2026, to November 15, 2026, and the specific scope, indicators, and management arrangements may still be adjusted. The announcement also stipulates that from the date of publication until the formal implementation of the revised catalog, pre-export registration for the listed technologies will be enforced.

Therefore, enterprises should first complete the verification of applicable scope and registration preparation, and later determine subsequent licensing and facilitation measures based on the formal catalog. Project plans can retain two records simultaneously: one documenting the registration process, and another tracking matters that need to be supplemented or adjusted after the formal rules are implemented.

On October 20, the Ministry of Commerce further explained in response to reporters that among the 40 technologies proposed for addition, 14 are intended to be prohibited from export, and 26 are intended to be restricted from export. These are the total numbers across the three fields, and the artificial intelligence technologies need to be judged against the specific items in the attachment. The AI directions listed in the announcement include large models, intelligent agents, computing power clusters, and information processing.

Legally, Article 2 of the "Regulations on the Administration of Technology Import and Export" includes cross-border transfer of technology through trade, investment, or economic and technological cooperation, including forms such as patent transfer, licensing, technology secret transfer, and technology services. Therefore, technology exports can occur in software licensing, R&D cooperation, and investment transactions, and business teams need to identify based on the actual transfer content.

This temporary registration and the current free technology contract registration and restricted technology export licensing should also be recorded separately. They correspond to different management requirements, and enterprises can use a project list to indicate their respective bases, handling entities, and completion nodes, avoiding the misunderstanding that the completion of one procedure means the entire project is ready for delivery.

As of October 24, 2026, the status of the rules.

▌ 2. Determine Business Scope Based on Actual Delivery Content

The first step in verification is for the technical person in charge to list the delivery items. Model weights, training or inference codes, algorithm documents, deployment scripts, technical support permissions, and update services should be specified separately. Legal teams should then compare these contents with the technical scope and indicators in the catalog attachment item by item.

For example, delivering models and deployment tools to overseas clients for them to run on their own devices is different from providing output results to clients through online services, which involves different technical and control arrangements. The Ministry of Commerce clarified in response to reporters that large model technologies included in the restricted export range should be handled according to regulations when it involves local deployment overseas; providing services through API, applications, web interactions, and SaaS, as well as lightweight local deployment, does not fall under the management scope of large model technology exports as described.

When enterprises use this explanation, they need to confirm the factual product and specific technical items simultaneously. A contract may include online services, custom model deliveries, and technical support, and cannot be treated solely based on the "service agreement" title on the front page of the contract. Only after listing each delivery clearly can it be easier to determine the corresponding requirements.

For instance, if a group plans to deploy models on overseas computing resources to provide services externally, it needs to specify the overseas receiving entity, server operation arrangements, model control permissions, subsequent maintenance, and external authorization methods. The Ministry of Commerce has already proposed directions for applying facilitation measures for situations such as self-built computing centers overseas, but specific projects should still be confirmed in conjunction with formal texts and actual handling requirements.

Open-source projects should also record their public status. The announcement has specified the scope for technologies that have entered the public domain through open-source, academic papers, etc.; for subsequent open-source technology exports, the response to reporters proposed automatic licensing and other facilitation arrangements. Enterprises should keep records of public time, version, scope, and licensing terms to facilitate explanations of what has been made public and what still belongs to proprietary technology that has not yet been delivered.

R&D cooperation especially needs to pay attention to the ownership of results. A joint R&D agreement may stipulate sharing background technology, exchanging phase results, and allowing overseas partners to continue development. The technical team should clarify these rights and the scope of materials to be opened, so that legal teams can determine when the transfer occurs, who the registration entity is, and how future results will be handled.

AI Generation Illustration

▌ 3. Changes in Control Rights Must Also Be Included in the Verification List

Announcement No. 48 clearly lists the registration situation of "the owner or actual controller of domestic technology changing to an overseas entity." Therefore, financing, mergers and acquisitions, and group restructuring teams also need to participate in this round of verification, and technology delivery and equity transactions should be reviewed together.

Project verification can start from existing ownership. Which company holds the relevant technology, how R&D personnel agree on job results with the company, whether there are external licenses, co-ownership rights, or restrictions on collaborative development, all affect whether the enterprise has the right to transfer or authorize externally. When the rights chain has not been clarified, subsequent registration content may also easily conflict.

Then, compare the structure before and after the transaction. Who holds the equity, who can decide on the use and disposal of technology, who appoints and removes key personnel, and what governance rights the overseas entity obtains should all be specifically described in the transaction materials. The announcement does not use a universal shareholding ratio to resolve all actual control judgments; enterprises need to raise questions around agreements and actual arrangements.

For ongoing transactions, a technology and control rights delivery checklist can be added. The checklist specifies the rights to be changed, completion time, internal approvals, registration handling, and the relationship between delivery documents. In this way, lawyers responsible for equity transactions and teams responsible for technology licensing can use consistent facts for the same matter.

If the technology is obtained by the company from a third party, it is also necessary to check whether the original license allows for transfer authorization, geographical expansion, or changes in control rights. Alongside regulatory registration, there are also obligations of consent and notification in contracts. For overseas recipients, these documents also relate to whether the technology they obtain can be used as planned.

The same contract may contain different delivery contents and should be verified separately.

▌ 4. How to Prepare for Pre-export Registration

The designated processing entry for the announcement is the unified platform of the Ministry of Commerce's business system for technology trade management information applications. Registration information mainly involves technology exporters and recipients, exporting countries or regions, intended export technologies and purposes, and expected export amounts, specifically according to the platform and the registration form in the announcement attachment.

Enterprises can first prepare an internal material package: entity licenses and contacts, recipient information, contracts or proposed transaction arrangements, technical scope descriptions, corresponding item analyses, delivery plans, and amount calculations. The purpose of the internal material package is to support reporting and review, and to handle according to the actual requirements for submission on the platform and guidance from the competent department.

Technical descriptions should use verifiable facts. Model or technology names, versions, functions, key indicators, intellectual property ownership, and intended uses should remain consistent. The R&D department is responsible for confirming technical content, the business department is responsible for confirming recipients and delivery methods, the finance department is responsible for amount standards, and the legal or compliance team is responsible for compiling and checking all materials.

When exporting multiple technologies to the same recipient at the same time, they can be combined for submission according to the announcement requirements; other situations should generally be filled out separately. If there are multiple overseas entities within the group, or if the same client obtains different technologies in phases, the recipient and delivery arrangements for each transaction should be clarified first, and then determine how to report.

Existing contracts need to be sorted separately. The announcement clearly covers exports that have already started but are not yet completed, and enterprises can list the status as "delivered content, pending delivery content, ongoing updates and support." Long-term licenses or phased R&D contracts especially require participation from the technical team to avoid judging whether the project has ended based solely on the signing date.

After submission, records of the submitted version, system receipt, submission time, and supplementary communication records should be kept, and linked to contracts and delivery checklists. When there are changes in technical scope, recipient entities, or implementation methods, recheck whether supplementary explanations or reprocessing of corresponding procedures are needed. Keeping records complete means that when inquiries arise later, there is no need to reconstruct the entire business.

For unclear boundary issues, specific facts and technical comparison results can be organized and consulted with the competent department. The more specific the question, the easier it is to obtain useful responses. For example, explaining the intended delivery content, deployment location, who controls the model, and the recipient's usage permissions is more helpful for advancement than vaguely inquiring whether "AI exports are restricted."

▌ 5. Contracts Need to Leave Room for Compliance Processing

Technology export contracts directly determine delivery pace, payment terms, and liability for breach. Enterprises should incorporate procedural handling into the timeline during the negotiation phase and clearly specify what materials each party will provide, who is responsible for communication, and how records will be kept.

Article 30 of the "Regulations on the Administration of Technology Import and Export" stipulates that restricted export technologies are subject to license management. Articles 31 to 35 arrange the steps for application, technology export license intention letters, substantive negotiations and signing, and applying for licenses, while Article 35 states that relevant technology export contracts take effect from the date of license issuance. Projects within this scope need to align contract structure and negotiation pace with statutory procedures.

Free export technologies are subject to the contract registration management stipulated in Articles 36 to 38, taking effect when the contract is legally established, with independent handling requirements for registration. Enterprises should first complete classification judgments, and then design contract effectiveness, delivery, and payment terms. For projects involved in the current temporary registration, corresponding handling nodes required by this announcement should also be added.

In the contract text, specific agreements can be made regarding material assistance, changes in regulatory requirements, delivery pauses, deadline extensions, and fee handling after termination. For example, if the final use or recipient information provided by an overseas client changes, timely notification should be made; if supplementary procedures need to be handled, both parties should cooperate as agreed and adjust the corresponding delivery time.

Technical attachments should also be carefully prepared. Which documents are to be delivered, what permissions are to be opened, how many recipients are allowed, and what scope of update services should be directly traceable from the contract. The business team and technical team execute based on this, making it easier to avoid actual deliveries exceeding the originally verified scope.

For projects with multiple payment phases, payment conditions can be linked to verifiable milestones. Records should be kept for internal approvals, registration or licensing processing, technology delivery, and acceptance, so that when policy or factual changes occur, both parties can determine what work has been completed and which fees need to be renegotiated.

Article 40 of the regulations also stipulates that if the main content of a technology export contract that has been licensed or registered changes, corresponding procedures should be reprocessed; if the contract is terminated, it should be filed as required. Enterprises can incorporate change checks into their daily contract management processes to avoid business departments adding delivery content via email without updating existing compliance records.

Temporary registration, free contract registration, and restricted licensing should be processed according to applicable systems.

▌ 6. Verify Technology Exports Alongside Data Outflows

Model deployment or technical support may sometimes involve the flow of training materials, test data, logs, and user information. When the technology export verification reaches this point, it is necessary to draw the data flow simultaneously: which data is provided domestically, what overseas personnel can access, where it is actually stored, and whether it returns after processing.

When personal information is involved, Article 38 of the "Personal Information Protection Law" stipulates the corresponding conditions for providing personal information overseas, Article 39 involves informing individuals about overseas recipients, processing purposes and methods, and separate consent requirements, and Article 55 requires conducting impact assessments prior to activities involving the provision of personal information overseas. Specific judgments should also be made in conjunction with applicable data outflow supporting rules and exemption situations.

In practical projects, synthetic test data or materials without personal information can be prioritized. When real data needs to be used, it is necessary to distinguish between de-identification and anonymization: Article 73 of the "Personal Information Protection Law" distinguishes these two processing methods, and Article 4 excludes information processed anonymously from the scope of personal information. Data that can still identify individuals when combined with other information after deleting names and masking phone numbers continues to be managed as personal information.

The testing environment should also restrict actual access. Whether debugging personnel can download data, whether logs record user inputs, and whether third-party support personnel can enter the environment should all be clearly defined in permissions settings and contracts. After testing is completed, the usage scope and processing records should be preserved, and then the necessary data outflow arrangements should be determined based on formal business.

For datasets and codes, the source rights should also be checked. Who provides training or testing materials, whether licenses allow for proposed uses, and whether client data can be used for further R&D are questions that will affect the use after technology delivery. Enterprises should keep source proofs and licensing restrictions together with the technology version.

For important data, dual-use items, or other specific controlled matters, the project should also verify the corresponding systems. Enterprises can have the same delivery checklist support technology exports, data, intellectual property, and contract checks, with each professional team forming conclusions within their scope and concentrating on matters that need coordination.

▌ 7. A Round of Inspection Enterprises Can Immediately Initiate

The first round of inspection can cover overseas projects that are prepared for signing or delivery in the next three months, as well as contracts that have already been signed but still have technology deliveries. Project leaders should first collect business facts, then have R&D and legal teams compare them with the announcement attachment to form a handling checklist of "needs to be processed, needs to supplement facts, needs to consult for confirmation."

Each project should retain a person responsible for summarizing, avoiding different departments explaining policies to clients separately. External communication can focus on specific arrangements: what recipient information needs to be supplemented, when to complete registration preparation, which delivery nodes need to be adjusted, and how both parties can cooperate. Writing matters clearly is usually more useful than giving clients a vague risk warning.

The solicitation of opinions is still ongoing. If enterprises find that technology indicators are difficult to apply, that there are interpretative difficulties in delivering certain types of services, or that facilitation measures require clearer processing rules, they can submit specific opinions within the deadline. Opinion materials should ideally include business scenarios, technical facts, and suggested wording to help the competent department understand where the problems arise.

After the formal catalog is published, project leaders can continue to use this round of checklists, marking whether applicable items have changed, what procedures need to be supplemented, and whether the next delivery is affected. For contracts still in execution, results should be synchronized with technical and business leaders, and delivery plans updated. Registration receipts, technology versions, and contract attachments should be saved linked to project numbers, so that when the next model upgrade or recipient change occurs, the verification starting point can be directly found.

This article is intended for legal, policy, and industry research exchange, aiming to provide an objective analysis of digital finance, stablecoins, digital assets, and related regulatory dynamics. It does not constitute any form of investment advice, legal opinion, tax opinion, or other professional advice, nor does it constitute a recommendation, promotion, or solicitation of any financial product, digital asset, or commercial project. The regulatory rules, market data, and institutional information mentioned in the article are mainly sourced from public materials and may be adjusted due to changes in laws and regulations, regulatory policies, market environments, and project progress. Readers are advised to independently judge based on the latest public information and comply with applicable laws and regulations in their respective countries or regions. The author and publishing platform do not bear any responsibility for any investment, trading, or other business decisions made based on reliance on the content of this article.