AI Export Controls: 7 Steps for Global Product Teams

AI export controls moved from a semiconductor issue to a model, agent, and deployment issue on October 16, 2026. The Associated Press reported that China proposed adding 40 technologies to its prohibited or restricted export catalog, including 23 artificial intelligence technologies spanning advanced models, agents, computing systems, and related capabilities.

For global product teams, the immediate question is not whether every API request becomes an export. It is whether a model, weight file, training method, deployment package, or technical capability crosses a boundary in a way the final rules may control. That requires a map of technology movement, ownership, and fallback options before a licensing question becomes a release blocker.

Key Takeaway: Treat AI export controls as a product architecture and supply-chain issue, not a form that legal reviews after the deployment is designed.

What China's draft AI export controls propose

China's Ministry of Commerce and Ministry of Science and Technology published a draft revision to the country's technology export catalog on October 16. The proposal would add 40 technologies: 23 related to AI, five to biomedicine, and 12 to solar technology.

The AI scope matters because it reaches beyond physical chips. The proposal covers areas such as large models, agents, computing clusters, information processing, and chip design. That can affect the transfer of technical know-how, model artifacts, deployment methods, and other capabilities even when no server crosses a border.

The draft is not the same as a final ban. The official Ministry of Commerce explanation says most AI technology would remain freely exportable and describes different treatment for several common delivery models. It states that overseas localization involving restricted technology can fall within export management, while ordinary foreign API calls, app or web interactions, SaaS access, and lightweight edge deployments would not automatically count as exporting large-model technology.

The same explanation describes facilitation measures, including automatic licensing in some cases, and exclusions for technology already placed in the public domain through open-source release or publication. Those distinctions are operationally important, but organizations should not turn a draft Q&A into a permanent architecture assumption.

Key Stat: AI accounts for 23 of the 40 proposed additions, making it the largest technology category in the draft.

Why AI export controls are an architecture problem

Traditional export reviews often start with a shipment, destination, customer, or end use. Modern AI products blur those boundaries because value can move through model weights, fine-tuning recipes, remote administration, evaluation data, deployment support, or access to a hosted service.

A single product may involve:

• a base model developed in one country
• fine-tuning data collected in several regions
• optimization code maintained by a distributed team
• inference hosted in a third-country cloud region
• customer-facing APIs available around the world
• local deployment packages delivered to regulated customers

The commercial interface may look identical while the underlying transfer path changes. A hosted API can keep model artifacts inside one controlled environment. A customer-managed deployment may require weights, containers, orchestration details, and performance techniques to move into another jurisdiction.

This is why procurement records alone are insufficient. Your organization needs a technical bill of materials that shows where important AI capabilities originate, where they run, who can retrieve them, and which release mechanisms copy them across organizational or national boundaries.

Hexon's AI supply chain security guide explains how to inventory models, agents, datasets, and dependencies for security. Extend that inventory with origin, residency, transfer method, recipient, and licensing status.

Common Mistake: Recording the cloud vendor's headquarters while ignoring the region where model artifacts are stored, the team that can export them, and the deployment package delivered to customers.

Seven steps to prepare for AI export controls

These steps help product, security, legal, procurement, and engineering teams build a shared operating picture. They are not a substitute for advice from qualified trade counsel on a specific transaction.

1. Inventory controlled-capability candidates

Start with the capabilities that would be difficult to replace or that create competitive advantage. Include foundation models, fine-tuned weights, agent frameworks, training and inference optimizations, chip designs, cluster orchestration, specialized datasets, and deployment tooling.

For each item, record its owner, origin, current location, repositories, deployment targets, access groups, and external recipients. Do not limit the exercise to assets labeled as AI. Performance libraries, evaluation systems, and technical documentation may enable the transfer of a controlled capability.

2. Map every transfer path

Draw the path from development to deployment. Mark when technology is copied, downloaded, synchronized, remotely accessed, embedded in an appliance, shared with a partner, or installed in a customer environment.

Separate access to a service from delivery of the underlying technology. The draft's distinction between ordinary API access and overseas localization shows why the mechanism matters. Product teams should be able to answer whether a customer receives outputs, executable components, weights, source code, methods, or operational control.

3. Add jurisdiction and ownership context

Record where the technology was developed, where it is hosted, where recipients are located, and which entities control the relevant intellectual property. Include contractors, subsidiaries, research partners, and managed service providers.

Entity structure can change the analysis. A transfer between two teams inside one corporate group may still cross a national boundary. A third-party cloud region may affect where artifacts reside even if employees never manually download them.

Hexon's enterprise AI threat model provides a useful way to connect assets, actors, actions, and owners. Add geographic and corporate boundaries to that model so release approvals follow the real data and technology flow.

4. Create a release gate for sensitive artifacts

Add a lightweight gate before weights, training code, deployment containers, or detailed technical packages can leave an approved environment. The gate should verify the artifact, recipient, destination, intended use, approval, license requirement, and delivery method.

Enforce the decision technically where possible. Repository permissions, artifact registries, cloud policies, download logging, and data loss prevention rules can prevent an approved hosted service from quietly turning into an unreviewed technology transfer.

Pro Tip: Use artifact hashes and immutable release records. They make it easier to prove exactly what was delivered and whether a later update changed the controlled content.

5. Segment products by delivery model

Do not use one compliance answer for every edition of a product. Separate hosted API, multi-tenant SaaS, customer-managed cloud, on-premises, edge, open-source, research, and partner-delivered versions.

For each model, identify what leaves your control. A hosted product may expose only responses and usage metadata, while an on-premises package may disclose the model, runtime, optimization techniques, and administrative tooling. That difference can determine the operational burden and continuity options.

Segmentation also improves security. It prevents a low-risk customer interface from sharing the same release path as a high-value model package.

6. Build supplier and model continuity options

List the products, regions, and customers that depend on a model or capability with uncertain future availability. Estimate the time required to switch to another model, retrain, revalidate, update contracts, and reproduce security controls.

Avoid assuming that a technically compatible replacement is operationally equivalent. A substitute can change accuracy, latency, cost, data handling, safety behavior, and incident response. The rollout measurements in Hexon's enterprise AI rollout guide can be reused as acceptance criteria for a replacement.

For critical workflows, maintain at least one tested fallback: another approved model, a reduced-capability mode, or a manual process. Document which customers would be affected and how product behavior would change.

7. Monitor the rule and preserve decisions

Assign an owner to track the draft, final catalog, implementation guidance, license mechanisms, and effective dates. Preserve the source, interpretation, decision, approver, and technical evidence for each material release.

The October 16 proposal is still subject to a public consultation process. Product teams should model plausible outcomes now, then update controls when official text changes. A decision register prevents different teams from repeatedly interpreting the same delivery pattern in conflicting ways.

Set a review trigger for product changes. A hosted service that later offers weight downloads, overseas dedicated instances, remote fine-tuning, or local edge packages may cross a boundary that the original approval did not consider.

Key Takeaway: Compliance depends on the actual capability and transfer path. Product labels such as cloud, SaaS, open source, or enterprise do not answer the question by themselves.

A practical AI technology transfer matrix

Create a small matrix for every important AI offering. It should connect the commercial product to the technical movement behind it.

Add columns for origin, destination, recipient entity, end use, data residency, approval status, license reference, and fallback. Keep the matrix close to architecture and release records rather than in a disconnected annual spreadsheet.

The vendor access risk checklist can help identify external administrators and support channels that may create an overlooked access path. A partner does not need a formal model download if broad remote access lets it retrieve the same artifacts.

Common Mistake: Reviewing only the first customer launch. Updates, support bundles, incident diagnostics, backup exports, and disaster recovery copies can create new transfer paths later.

Security controls that also improve export governance

Strong security controls make export decisions easier to enforce and audit. Start with least privilege for model registries, training repositories, deployment pipelines, and cloud snapshots. Require named accounts, phishing-resistant authentication, and separate approval for bulk export or cross-region replication.

Log high-value actions such as weight downloads, repository cloning, artifact promotion, cross-account copies, region changes, and temporary support access. Alert on new destinations, unusual download volume, unmanaged devices, and service-account behavior outside a normal release window.

Protect the evidence as carefully as the asset. Release records should show:

• the exact artifact and cryptographic hash
• the source and destination environments
• the recipient entity and authorized users
• the business purpose and end use
• the reviewer and approval time
• any license, exception, or policy basis
• the rollback and continuity plan

These controls serve more than compliance. They reduce intellectual property leakage, insider risk, accidental public release, and supply-chain compromise. They also give incident responders a reliable timeline when a model or deployment package appears somewhere unexpected.

What product leaders should do this week

First, identify every product that depends on AI technology developed, hosted, or supplied from China. Do not assume the draft applies, but do not wait for final rules to discover that a customer-managed deployment includes weights or specialized methods.

Second, classify each delivery model by what actually crosses the boundary. Hosted access, dedicated overseas hosting, customer-managed cloud, on-premises delivery, and open-source publication need separate diagrams and decisions.

Third, appoint one cross-functional owner for the inventory and decision register. Product should describe what customers receive, engineering should map artifacts and access, security should enforce the path, procurement should identify dependencies, and qualified counsel should interpret the final legal requirements.

Finally, test one continuity scenario. Assume a critical model cannot be transferred into a new region on the planned date. Measure how long it takes to select a replacement, reproduce controls, validate quality, notify customers, and release safely.

The fresh proposal is a warning against treating AI capability as a locationless utility. Models, agents, training methods, and deployment packages have origins, owners, repositories, and transfer paths. Teams that can see those facts can adapt to new rules without improvising under a launch deadline.

AI export controls will continue to evolve across jurisdictions. The durable response is a product architecture that makes sensitive technology movement visible, reviewable, enforceable, and replaceable.