Mankun Legal Insights | AI Token Global Expansion: Appears to Be a Technology Business, Operates as a Compliance Supply Chain

Three Compliance Essentials: The Source of the Model, the Flow of Data, and the Final Destination of Services

This year, the business of exporting AI tokens has noticeably heated up. On the surface, it appears straightforward: domestic models offer certain advantages in engineering implementation and cost control, while overseas developers and small and medium-sized enterprises seek affordable, stable, and easily accessible AI services. By interposing an API gateway layer to integrate models such as DeepSeek, Zhipu, and Tongyi, and charging based on usage volume, it seems like an asset-light business model. Precisely because it appears simple, many projects initially focus on only three matters: whether prices can be lowered, whether concurrency capacity can be sustained, and whether payment collection can proceed smoothly. However, what truly determines the long-term viability of this business is often not these three factors, but rather three other dimensions: the source of model capabilities and whether you have the right to resell them to overseas clients;

the flow of downstream client data, and whether you can demonstrate that domestic data has not been commingled or misused;

the countries to which services are sold, and whether local regulators will hold you accountable under AI, data, and consumer protection rules.

Tokens are merely units of billing, not a shield for compliance. Although the business is labeled “AI Token Export,” the risks do not lie in the term “token,” but in the underlying supply chain, data flows, and target markets.

The Source of the Model: Possessing an API Key Does Not Entitle You to Resale

Many teams’ initial reaction is: “If the API connection works and downstream clients are willing to pay, why can’t we sell it?”

This is precisely where the problem lies. A standard API key typically indicates only that you are authorized to make calls; it does not equate to permission to repackage, aggregate, white-label, distribute, and resell such capabilities to overseas clients. This is not merely a matter of fine print in contracts, but a fundamental question of whether the business operates with legitimate sourcing.

Sourcing generally falls into three categories.

First, signing directly with model providers. This pathway is the most transparent, but the contract must address critical points: whether API resale is permitted, whether white-labeling or secondary encapsulation is allowed, whether the licensed territory covers the target overseas countries, whether there are restrictions on the industries of downstream clients, whether downstream client data will be used for training, and whether the model name and capability representations may be used in external publicity.

Second, sourcing through official distributors, authorized agents, cloud providers’ Model-as-a-Service (MaaS) offerings, or token factories. MaaS can be simply understood as Model as a Service, whereby cloud providers package model capabilities into a purchasable and callable cloud service. This pathway is not necessarily problematic, but one cannot rely solely on counterparts’ assertions that they are “legitimate.” You must examine upstream authorization documents, rights to further distribution, licensed territories, settlement vouchers, and plans for migrating downstream clients in the event of upstream supply interruption.

Third, wholesale purchase of low-priced quotas. Low pricing itself is not an issue; scale procurement, inference optimization, and cloud resource discounts may all lead to lower prices. However, if the low prices stem from account pools, arbitrage of educational discount quotas, shared accounts, non-public interfaces, reverse-engineered calls, or even fraudulent use of quotas, this does not constitute a cost advantage, but rather introduces others’ liabilities into your own business.

To assess the reliability of a supply source, you may start by asking a simple question:

For each API call I sell, can I trace it back to its specific upstream provider, the underlying authorization, and the corresponding invoice?

If the answer is no, proceed with caution. For instance, if you sell 5 million Token-based API calls externally per month, but your upstream procurement records only support 1 million; or if downstream clients ask whether you have official authorization and your sales team can only provide vague assurances that "the channel is fine." In such scenarios, the risk is not merely theoretical; it involves potential future disruptions in supply, account suspensions, claims for damages, and inquiries regarding the origin of the API interfaces.

In terms of implementation, at least four measures must be taken:

Ensure a closed loop in the authorization chain: There must be written documentation at every layer, from the model provider, cloud service provider, and distributor to your entity, and finally to the overseas client;

Ensure a closed loop in the scope of business: API calls, aggregation, resale, white-labeling, overseas sales, and the industries of downstream clients must all fall within the scope of the authorization;

Ensure a closed loop in data liability: It must be specified in the Data Processing Agreement (DPA) and the list of sub-processors who receives the downstream clients' data, how long it is retained, whether it is used for training, and whether it is transferred to third parties;

Ensure a closed loop in billing evidence: Upstream procurement contracts, invoices, and payment records must correspond to downstream orders, usage volumes, and receipts.

This is not done merely to make the documentation look presentable, but to ensure clarity in the event of future issues: demonstrating that the AI capabilities sold are sourced, authorized, and traceable, rather than being aggregated API call quotas cobbled together from various gray-market interfaces.

Data Flow: Overseas data may be transmitted into mainland China for processing, but it must not be commingled with domestic data.

A common issue in the cross-border provision of AI Tokens is as follows: Overseas clients send prompts, files, voice recordings, and logs to mainland China, where servers or models perform inference, and the results are returned to the overseas clients. Is this permissible?

According to the Provisions on Promoting and Regulating Cross-Border Data Flows (Order No. 16) issued by the Cyberspace Administration of China, if personal information is collected and generated outside mainland China, transmitted into mainland China for processing, and then provided back outside mainland China, and if such processing does not involve the introduction of personal information or important data from within mainland China, the relevant security assessment, standard contract, and certification procedures for cross-border data transfer may be exempted.

Image source: Official website of the Office of the Central Cyberspace Affairs Commission, Provisions on Promoting and Regulating Cross-Border Data Flows

In business terms, this means:

Data from overseas clients may be brought into China for processing and then transferred out. However, to qualify for this exemption, the processing pipeline must not commingle personal information from within China or introduce important data.

While this pathway is indeed open, it should not be interpreted as meaning that “as long as the client is overseas, any handling method is permissible.” Enterprises remain responsible for data security, cybersecurity, and the protection of personal information. What must be demonstrated is that the data flow follows a clear pattern of collection overseas, processing within China, and return overseas, with transparent processes and clean boundaries.

The five most common types of “commingling” that pose risks are:

Commingling of domestic users: Although intended for overseas business, domestic users are permitted to register, access services, or upload data;

Commingling of domestic business data: Domestic operational data, user profiling tags, or customer lists are combined for joint analysis;

Commingling of storage resources: Domestic and overseas data share the same databases, log systems, or training sample pools without adequate segregation;

Commingling in operations and maintenance: For debugging purposes, engineers import domestic data into overseas data flows or arbitrarily copy overseas data to local environments;

Commingling of important data: Once important data is introduced, the ordinary exemption logic no longer applies, and stricter compliance pathways, such as security assessments, must be followed.

The greatest risk arises when technical teams assume “legal will draft appropriate clauses,” while legal teams assume “technical teams know how to handle data,” resulting in no one clearly mapping the data flows.

It is advisable to prepare at least one internal data flow diagram that clarifies the following issues:

Where prompts, files, voice recordings, and images submitted by overseas customers are routed;

Whether they pass through servers located within the territory, models deployed within the territory, or operations and maintenance personnel located within the territory;

Whether inputs and outputs are retained, for how long, and who has access to them;

Whether logs are de-identified and whether they can be deleted;

Whether data is used for training, fine-tuning, or quality evaluation;

Which underlying model providers, cloud service providers, and log service providers have access to the data.

If this data flow cannot be clearly mapped, even the most elegantly drafted privacy policy and Data Processing Agreement (DPA) will struggle to reassure overseas enterprise clients. What they truly care about is: Has my data been used for training? Has it been transmitted to third parties unknown to me? If regulators or major clients ask, can you produce evidence, rather than merely stating that “we take privacy very seriously”?

Where the service is sold: not where the company is registered, but where it is ultimately used

Many teams expanding overseas prefer to incorporate in Hong Kong, Singapore, the British Virgin Islands (BVI), or other offshore jurisdictions, assuming that this allows them to avoid regulation in major markets.

This assumption is dangerous. Compliance in the target market depends not on the paper registration of the company, but on where downstream customers are located, where end users are located, into which scenarios the service is introduced, and where data flows.

Why is the target market important? Because penalties imposed by overseas regulators are not symbolic.

In the European Union, as long as personal information of EU users is processed, privacy compliance cannot be treated as a mere formality. The General Data Protection Regulation (GDPR) imposes different tiers of fines for different violations. For serious violations involving fundamental processing principles, individual rights, and transfers to third countries, the maximum penalty may reach EUR 20 million or 4% of the total global annual turnover of the preceding financial year, whichever is higher.

The EU AI Act does not regulate the abstract concept of “AI,” but rather how AI is ultimately used. For certain AI application scenarios that are explicitly prohibited, fines may reach up to €35 million or 7% of the global turnover in the preceding financial year, whichever is higher. In other words, expanding AI services overseas is not a matter of “launch first and address issues later.” Once such an API is integrated into high-risk or prohibited use cases, the platform must at least demonstrate that it has established boundaries, screening mechanisms, and suspension protocols.

Although the United States does not have a unified AI statute, there are distinct regulatory entry points for child privacy, finance, healthcare, employment, and consumer protection. For instance, downstream products directed at children may trigger obligations under the Children’s Online Privacy Protection Act (COPPA); integration into credit scoring, insurance, recruitment, or medical Q&A services may also attract scrutiny under industry-specific regulations or consumer protection rules.

While these rules appear to target downstream products, why should API intermediary platforms also be concerned? The reason is straightforward: what the platform provides is not a static piece of code, but an AI capability subject to continuous invocation. If downstream customers integrate this capability into obviously sensitive, illegal, or non-compliant scenarios, and the platform lacks mechanisms to prohibit such uses, handle anomalous calls, suspend services, and cooperate with investigations, it will be difficult to maintain the defense that “we are merely a technical conduit and have no responsibility for how others use our services.”

Of course, this does not mean that the platform must treat every caller as an audit subject, nor does it imply establishing a complex approval process at the front-end registration stage. A more practical approach is to first define red lines in the terms of service: explicitly prohibiting illegal or non-compliant activities, rights infringements, circumvention of upstream restrictions, and abuse of the interface, while reserving the right to throttle traffic, suspend or terminate services, and cooperate with investigations. When dealing with enterprise clients, sensitive industries, high-concurrency usage, or during due diligence for key accounts, the platform can then escalate to requiring use-case disclosures, special clauses, log retention, and audit cooperation.

Furthermore, the platform’s external marketing communications must remain restrained. Without proper authorization, do not claim “official direct connection”; since the underlying model may switch, avoid creating the external impression that a specific provider’s model is permanently used; given that model outputs may involve hallucinations, do not promise “absolute accuracy”; and where upstream interfaces impose usage and scenario limits, do not promise “unlimited use.”

In short, remember that going global does not mean escaping regulation, but rather entering into another jurisdiction’s regulatory framework.

Connecting the three threads: Do not focus on isolated points; instead, examine the entire business chain.

Data sources, data handling, and target markets are not three unrelated documents, but parts of the same business chain.

Consider this in the context of an API gateway project. If the model sourcing involves account pools, shared quotas, or reverse-engineered interfaces, and the upstream provenance is unclear, there is a problem with the source. If prompts and files from overseas customers are returned to mainland China for inference, but the platform cannot clarify whether data is retained, used for training, or transferred to third parties, there is a problem with data handling. If EU-based downstream customers integrate the service into products targeting EU users, and the platform has not prepared a Data Processing Agreement (DPA) and list of sub-processors under the GDPR, nor imposed restrictions on high-risk AI uses, there is a problem with the target market.

In such circumstances, the project party should not limit its inquiries to just three questions:

Can the price be lowered further;

Can the concurrency capacity be increased further;

Can payment collection be accelerated?

Three additional questions must be addressed:

What are the contractual permissions governing the sale of my model capabilities?

Through which systems does downstream customer data flow, and can evidence be produced in the event of an incident?

In which countries and industries do downstream customers operate, and have I established red lines and escalated review mechanisms?

If these three questions can be clearly answered, tokens serve merely as a unit of measurement for AI services; if they cannot, tokens become a label that obscures supply chain, data, and overseas regulatory risks.

Robust compliance ensures sustainable business operations.

The opportunity for exporting AI token-based services is real. Chinese teams possess certain advantages in model integration, engineering implementation, and cost control, while overseas customers genuinely require AI services that are more affordable, stable, and easier to integrate.

However, in promising sectors, one must not rely on gray-market channels to gain time-to-market advantages.

Unclear sourcing will inevitably lead to supply disruptions, account suspensions, and customer claims; unclear data practices will deter enterprise clients and fail to satisfy regulators; unclear target markets may result in complaints, delisting, investigations, and impediments to financing due diligence.

Compliance is not about embedding risks into disclaimer clauses, but rather structuring business workflows into a system that is explainable, auditable, and deliverable to clients.

What token exportation truly sells is not merely cheaper access quotas, but an AI capability supply chain that can withstand rigorous scrutiny.