MIIT Put Token Procurement on the Agenda, but Orders Are Not Guaranteed

China’s Ministry of Industry and Information Technology put token procurement into national policy on August 31, 2026, despite leaving budgets and purchasing rules undefined. The move covers large models, AI agents, and metered token services used to run generative AI systems.

The policy matters because it shifts attention from building models toward buying repeatable AI services. MIIT wants local authorities and industrial organizations to open real operating scenarios, support first-time purchases, and share early deployment risks.

Yet the announcement is not a blank check for model developers. It creates a framework for cultivating application providers, while actual demand still depends on local programs, procurement notices, technical evaluations, and customer adoption.

The central contest is therefore not one model company against another. It is deployment capacity against cheap model access. China already has many competitively priced models, but low inference costs alone do not produce reliable industrial systems.

What MIIT Actually Changed

MIIT created a national development program for AI application providers, not a funded token purchasing mandate.

The ministry published its service provider notice at 10:50 a.m. Beijing time on August 31. The document was dated August 27 and carries the reference number MIIT Office Letter 2026 No. 414.

That date resolves the uncertainty surrounding the initial news alert. The underlying event was an official ministry notice published on August 31, rather than an undated speech or reported proposal.

The notice defines an AI application service provider as an organization serving a customer’s intelligent transformation needs. Its work can include consulting, implementation, operations, and security governance.

That definition is important. MIIT is targeting companies that can deliver functioning systems, rather than limiting support to foundation model developers or cloud infrastructure owners.

The ministry wants more than 2,000 providers in a national resource pool by the end of 2026. It raises the target to at least 3,000 providers by the end of 2027.

Provinces containing national AI industrial innovation application pilot zones receive another target. Each relevant province should have at least 100 companies in its local pool by the end of 2027.

These are enrollment targets, not purchasing totals. The notice does not state how much money authorities will spend on models, agents, or token consumption.

It also does not identify specific model vendors. No company receives a guaranteed place in the pool, and the document provides no market-share allocation.

The program instead establishes four connected tasks. Local authorities must map providers, improve their delivery capabilities, promote scaled adoption, and strengthen supporting infrastructure.

The resource-pool task creates a discovery and classification mechanism. Provincial authorities must examine providers in their jurisdictions, including locally registered central state-owned enterprises, and build company records.

MIIT will combine regional submissions into a national pool based on relevant standards. The ministry says it will publish that resource pool at an appropriate time.

The second task focuses on supply quality. Providers are encouraged to form AI application service groups that combine models, data, computing power, and other capabilities.

The notice identifies software and hardware adaptation, multi-model coordination, security, and operational compliance as practical challenges. It also encourages integration with trusted operating systems, databases, and AI inference chips.

The third task covers scaled adoption. Providers should package high-frequency and reusable functions into modular, standardized products that customers can deploy without rebuilding every component.

Within that task, MIIT asks regions to explore first-purchase, first-use, and risk-compensation mechanisms. It then calls for increased procurement of large models, agents, and token services.

The wording leaves room for different local approaches. A province could support a pilot buyer, compensate part of an early failure risk, or organize demand-matching programs.

However, the notice does not say every region must establish the same mechanism. It also does not establish a uniform reimbursement rate, purchasing quota, or application deadline.

The fourth task addresses resources required after a provider wins a customer. MIIT encourages connections with national computing hubs and the China Computing Power Platform.

It also recommends computing vouchers, shared interfaces, trial channels, training bases, and front-line deployment engineers. These measures recognize that model access is only one part of an enterprise deployment.

This structure makes the policy more substantial than its token headline suggests. The government is trying to organize an application delivery market, with procurement serving as one demand-side tool.

At the same time, the cautious verbs matter. MIIT tells regions to “explore” procurement and compensation models. It does not report an approved national purchasing budget.

That distinction should guide how companies interpret the news. The immediate change is policy recognition and institutional organization, not a measurable surge in completed orders.

Why Token Procurement Is the Policy Signal

Naming token services treats AI inference as a purchasable operating input, rather than an informal experiment attached to software projects.

A token is a unit used by AI systems to process text, code, images, audio, or other machine-readable content. Providers commonly meter model usage through input and output token counts.

Token purchasing differs from buying a conventional software license. Consumption can rise with user activity, prompt length, agent complexity, document volume, and repeated tool calls.

An agent can consume many model calls while completing one business task. It might retrieve records, analyze documents, call software tools, check its work, and prepare an answer.

That pattern makes budgeting difficult. A successful deployment may increase consumption sharply, while an unreliable agent can waste tokens without producing useful work.

By naming tokens alongside large models and agents, MIIT acknowledges this operational layer. The policy recognizes that adoption requires ongoing inference, not only access to a model checkpoint.

That signal fits China’s broader “AI Plus” strategy. The State Council’s AI Plus policy called for wider AI integration across six priority areas by 2027.

The earlier policy set an adoption target above 70 percent for next-generation intelligent terminals and agents. It also emphasized science, industry, consumption, public services, governance, and international cooperation.

MIIT’s new program translates that broad direction into an implementation structure. It identifies the service organizations expected to connect models with industry workflows.

First-purchase support addresses a familiar barrier in technology adoption. Buyers often hesitate when a product lacks operating history, comparable deployments, or established responsibility rules.

A customer may understand an agent’s potential while rejecting the first production deployment. The downside includes integration failures, data exposure, workflow interruption, and unpredictable inference costs.

Government-supported first use can provide a reference customer. That reference can help a provider demonstrate delivery performance to later buyers.

China already has a formal mechanism for collaborative innovation procurement. The Ministry of Finance’s procurement rules took effect in June 2024.

Those rules divide eligible projects into an ordering stage and a first-purchase stage. Buyers can work with suppliers on development, share research risk, and purchase a successful resulting product.

The mechanism does not automatically apply to every AI project. Eligible projects require substantive technological innovation and must follow budgeting, review, negotiation, disclosure, and contracting procedures.

MIIT’s notice does not explicitly merge its AI program with every detail of those rules. Still, the existing framework shows how first-purchase language can become an actual procurement process.

Risk compensation targets a related problem. A customer may avoid a technically promising system because the first implementation carries higher costs and uncertain results.

Sharing part of that risk can make a controlled deployment easier to approve. It can also encourage buyers to test providers without shifting the entire failure cost onto one department.

Yet compensation can create weak incentives when performance requirements remain vague. Buyers might approve projects because losses are shared, while suppliers might prioritize qualification over measurable value.

A sound program therefore needs outcome measures. These could include task completion, error rates, human review time, uptime, security incidents, and total cost per completed workflow.

Raw consumption is not enough. Purchasing more token capacity does not prove that an organization has become more productive or more intelligent.

The strongest interpretation of the policy is therefore not “China will buy tokens.” It is that metered AI consumption has entered the vocabulary of industrial procurement.

That change can affect how vendors package their services. Providers may need to connect token volume with defined tasks, service levels, deployment support, and compliance controls.

A manufacturer will care less about a low unit rate than a reliable inspection, maintenance, scheduling, or engineering workflow. A public organization will also require clear responsibility and audit trails.

Model developers face a similar adjustment. Their strongest channel may be a service partner that understands a specific factory, hospital, utility, or government process.

This creates room for intermediaries, but it also raises accountability questions. Customers must know whether the model vendor, application provider, integrator, or buyer owns each operational risk.

MIIT’s service-provider definition attempts to place delivery responsibility somewhere visible. The national pool could make these organizations easier to identify and evaluate.

However, the notice does not yet define a universal scorecard. It promises a pool based on relevant standards, with publication planned at an unspecified future time.

Until those standards appear, inclusion has uncertain commercial value. Companies cannot assume that entering a registry will produce qualified leads or purchase commitments.

The policy signal is real, but its economic force depends on implementation. Tender documents, local budgets, and consumption reporting will reveal whether token procurement becomes recurring demand.

The Real Contest Is Deployment Capacity Versus Cheap Model Access

China’s AI bottleneck is moving from access to execution, where integration and operating discipline matter more than a low token rate.

Competition among Chinese model providers has made capable systems increasingly accessible. Enterprises can test multiple general and specialized models without training a foundation model themselves.

That abundance changes the application market. A provider can route different tasks to different models, choosing among cost, latency, language, security, and domain performance.

MIIT specifically identifies multi-model coordination as a technical challenge. That inclusion suggests policymakers do not expect one model supplier to serve every industrial requirement.

A practical service provider may combine a general language model with retrieval, specialized classifiers, internal databases, and deterministic business software. Human approval can remain mandatory for sensitive actions.

This architecture reduces dependence on one model, but it increases integration work. The provider must test model changes, monitor failures, secure data, and maintain connectors.

Cheap inference does not remove those obligations. It can even encourage unnecessary usage when teams measure experimentation volume instead of completed business outcomes.

The competitive divide will therefore run between providers that can operate inside customer environments and those that mainly resell model access.

MIIT encourages front-line deployment engineer teams for this reason. These engineers work at customer sites, connecting AI systems to real data, tools, policies, and staff routines.

The concept resembles deployment-heavy enterprise AI strategies used in other markets. The provider earns trust by staying close to operations, rather than delivering a generic interface and leaving.

For industrial customers, this approach can be essential. Factory systems may involve old equipment, isolated networks, specialized databases, and strict downtime limits.

A model’s benchmark score says little about whether it can retrieve the correct maintenance record. It also does not show whether an agent can recover after a software tool fails.

Standardized product packages offer the opposite advantage. They reduce customization by targeting frequent, necessary, and reusable functions across many customers.

MIIT wants providers to create compact products fitting those characteristics. The goal is to avoid treating every deployment as a bespoke consulting project.

That creates an unavoidable tension. Complex customers need close integration, while scalable providers need repeatable products and predictable support.

Successful vendors must decide which layers to standardize. Model routing, evaluation, permissions, logging, and workflow controls can form a common platform.

Industry data structures and operating rules may still require local adaptation. Providers that customize everything will struggle to scale, while rigid products can fail inside actual organizations.

The national resource pool could intensify this selection process. Thousands of listed providers will compete for a limited number of credible reference deployments.

Large technology groups enter with cloud infrastructure, models, sales relationships, and extensive partner networks. Smaller specialists can counter with domain knowledge and faster on-site delivery.

Traditional software companies also have an opening. They already control systems where employees create orders, review records, manage equipment, or approve transactions.

These incumbents can add models and agents to established workflows. Their advantage is distribution and customer context, rather than frontier model research.

Systems integrators hold another useful position. They understand procurement, infrastructure, customization, and long implementation cycles, particularly among public and industrial buyers.

However, existing relationships do not guarantee AI competence. Integrators must demonstrate model evaluation, data governance, agent controls, and continuous monitoring.

Model startups face a different choice. They can sell direct consumption, build their own applications, or rely on service partners for delivery.

Direct sales preserve a closer customer relationship. Partner distribution can reach more industries but may weaken control over implementation quality and customer feedback.

The policy does not select one of these commercial structures. Its provider definition is broad enough to include consultants, implementers, operators, and security specialists.

That breadth supports experimentation, but it may also blur comparisons. A model vendor, a local integrator, and a compliance consultancy could enter the same pool with very different capabilities.

Customers will need categories that reflect actual responsibilities. Otherwise, a large registry could become a directory rather than a dependable qualification mechanism.

The program’s security language suggests MIIT recognizes this problem. Providers should embed network security, data security, ethics, and business compliance throughout development and operation.

China’s generative AI rules already impose duties on services offered to the public. These include data protection, content controls, reliability, and security assessment requirements in defined cases.

Enterprise and industrial deployments can fall under different regulatory circumstances. Nevertheless, customers will expect providers to identify which obligations apply before moving from a pilot into production.

Token procurement therefore carries more than a billing question. Each unit of consumption can involve customer data, generated content, model decisions, and automated software actions.

An enterprise buyer must know where prompts are processed and retained. It also needs rules for personal information, confidential records, and access to external tools.

Agents raise the stakes because they can act, rather than only answer. A poorly controlled system might send a message, change a record, or trigger an operational process.

Providers need permission boundaries, logging, human review, and recovery procedures. These requirements add cost that a simple per-token comparison will not capture.

The best service packages will connect consumption to business-level controls. Buyers should be able to see which workflow used the capacity, what result emerged, and who approved sensitive actions.

That model also makes risk compensation easier to evaluate. A local program can support a defined deployment with measurable milestones, rather than subsidizing an unspecified pool of inference.

The resulting competition will reward operational evidence. Providers must show that their systems work repeatedly under the customer’s data, security, and latency constraints.

This is the deeper shift behind the headline. Model access has become widely available, while dependable application delivery remains scarce and labor intensive.

What MIIT Token Procurement Does Not Guarantee

The notice creates permission to experiment with demand support, but it does not guarantee budgets, contracts, utilization, or successful AI outcomes.

The largest uncertainty is financial. MIIT provides provider-count targets, yet it publishes no national spending allocation for model, agent, or token purchases.

The document also does not set a minimum local contribution. Regions with different industrial bases and fiscal conditions can implement the program at different speeds.

This means headline language should not be converted into revenue forecasts. A provider cannot calculate expected orders from the national pool target alone.

More than 2,000 companies may enter the pool before the end of 2026. Entry could create visibility, but it could also produce a crowded market with limited differentiated demand.

The timeline creates another pressure. The notice appeared four months before the first national provider-count deadline.

Local authorities must identify companies, build records, apply standards, and submit information within that period. Speed can conflict with detailed technical evaluation.

A rapid enrollment process may favor easily verified corporate credentials. It might not capture the operational differences between a prototype builder and an experienced production provider.

The ministry’s future national online platform could improve transparency. However, the notice gives no publication date or confirmed set of public data fields.

Buyers need more than company names. Useful records would describe industries served, model dependencies, security capabilities, deployments, evaluation results, and support coverage.

A second uncertainty concerns the meaning of increased procurement. The phrase could cover direct government purchases, state-owned enterprise programs, private buyer incentives, or regional pilot subsidies.

Those channels follow different rules. Their budgets, disclosure requirements, evaluation methods, and buying cycles are not interchangeable.

The existing collaborative procurement framework provides one possible route. It still requires a qualified project, an approved budget, a structured process, and contractual milestones.

Therefore, “first purchase” should not be read as automatic preference for an untested product. The mechanism is designed to support substantive innovation while managing procurement risk.

Risk compensation also requires precise design. A program must identify eligible failures, covered costs, compensation limits, and evidence requirements.

Poorly specified compensation can hide weak demand. A buyer might complete a subsidized pilot but decline recurring usage when the support ends.

Recurring token consumption is one useful signal, although it requires context. Higher volume can reflect successful adoption, inefficient prompts, repeated failures, or wasteful agent loops.

Outcome measures must accompany consumption. Cost per resolved case, reviewed contract, completed design task, or avoided outage offers a clearer view.

Independent evaluation will matter because providers have incentives to present pilot results favorably. Customers should test systems on representative data and difficult edge cases.

Procurement teams also need exit plans. A provider may change its model, pricing method, data practices, or support terms during a multi-year deployment.

Multi-model architectures can reduce lock-in, but switching remains costly. Prompts, evaluations, retrieval systems, and tool connectors often depend on model behavior.

Portability requirements could therefore influence future tenders. Buyers may request exportable logs, documented interfaces, model substitution tests, and clear data-return procedures.

Security risk remains central. MIIT asks providers to move from passive response toward proactive prevention across development, deployment, and operation.

That language recognizes that compliance cannot be added after an agent reaches production. Data boundaries and action permissions must be designed before broad use.

A provider’s national-pool status should not replace customer due diligence. Inclusion can indicate policy relevance without proving that every service meets every sector’s requirements.

Healthcare, finance, energy, manufacturing, and public administration each carry distinct operational risks. A successful office assistant does not establish readiness for safety-sensitive industrial control.

The policy also leaves model performance unresolved. It encourages integration with secure and reliable domestic software, databases, and inference chips, but does not define one mandatory stack.

That flexibility can support diverse solutions. It can also increase testing work because providers must validate behavior across hardware, models, and customer environments.

Economic conditions add another constraint. MIIT’s software industry data show revenue growing faster than profit during 2026’s first seven months.

Software revenue reached 8.9785 trillion yuan, an increase of 9.2 percent from the prior-year period. Total profit reached 1.0396 trillion yuan, up 1.3 percent.

Those figures cover the entire software and information technology services industry, not AI providers alone. Still, the gap illustrates why delivery economics deserve attention.

Providers can win projects while damaging margins through excessive customization and on-site support. Low model prices do not eliminate expensive engineering work.

A successful national program must therefore produce repeatable solutions, not only provider registrations and subsidized pilots. Recurring commercial use will be the harder test.

The document’s overseas expansion language introduces another uncertainty. Qualified regions are encouraged to support Chinese AI application projects through international cooperation mechanisms.

Cross-border deployment adds data, localization, contracting, and regulatory complexity. A product approved for one domestic setting may require substantial changes abroad.

None of these gaps invalidates the policy. They show why the August 31 notice should be treated as a market-building framework rather than completed demand.

Three Signals Will Show Whether the Policy Creates Real Demand

The next evidence should come from provider-pool rules, funded local procurement, and recurring usage tied to measurable outcomes.

The first signal is the national resource pool’s selection standard. MIIT says it will form the pool using relevant standards and publish it at an appropriate time.

The standard will reveal what the government values. Revenue, patents, model ownership, delivery history, security controls, and industry specialization would favor different provider groups.

A standard centered on deployment evidence would strengthen the policy’s application focus. It would reward companies that can operate systems inside customer environments.

A standard centered mainly on corporate credentials would weaken that interpretation. It could produce a large registry without separating production capability from presentation quality.

The pool’s category structure also matters. Buyers need to distinguish model suppliers, platform vendors, integrators, domain specialists, operators, and security providers.

Published update procedures would provide another useful clue. An active pool should admit new providers, remove inactive entries, and reflect material capability changes.

The second signal is funded local procurement. Watch for tender notices, first-purchase agreements, risk-compensation rules, computing vouchers, and named pilot scenarios.

The strongest evidence would include budget sources, eligibility requirements, milestones, and public results. These details would convert national direction into purchasing activity.

Geographic distribution will matter as much as total announcements. Provinces with AI pilot zones face explicit provider targets, but their industrial needs differ considerably.

A manufacturing center might prioritize quality inspection, maintenance, design, and supply planning. Another region might focus on software services, public administration, or energy operations.

These differences can test whether standardized packages travel across customers. A solution that succeeds in several comparable environments offers stronger evidence than one showcase deployment.

Risk-compensation terms deserve close attention. Programs that require measurable outcomes and customer contributions are more likely to test genuine demand.

Programs covering most costs without post-pilot commitments can inflate activity temporarily. Providers might optimize for subsidy applications instead of durable products.

Tender language will also show whether buyers purchase raw capacity or completed services. A token quota alone creates little accountability for business results.

Contracts connecting capacity with workflows, service levels, evaluation sets, and security responsibilities would signal a more mature market.

The third signal is recurring, outcome-linked consumption. Providers and customers should show whether usage continues after trials and external support end.

Raw token totals cannot answer this question. Reporting should connect consumption with completed tasks, error rates, human review, and total operating cost.

Renewals are especially valuable. A customer that expands a deployment after measuring results provides stronger evidence than a provider announcing another pilot.

Model diversity can provide another adoption clue. A service provider using several models for defined tasks demonstrates that the application layer controls the customer relationship.

Conversely, applications that collapse when one model changes reveal fragile integration. Procurement rules may eventually require substitution testing or continuity planning.

Security records will influence demand as well. A serious incident involving confidential data or unauthorized agent actions could slow procurement across several sectors.

Transparent incident handling would support trust. Providers need monitoring, documented responsibility, and a clear process for limiting affected systems.

Front-line engineering capacity should grow with contracts. If listed providers recruit deployment specialists, that would suggest they expect operational work rather than registry status alone.

The next one to three months will provide early evidence, though not a complete verdict. MIIT must move quickly to approach its end-of-2026 provider target.

Local agencies also need time to turn national language into compliant programs. The absence of immediate spending would not prove failure, but vague announcements without procurement details would weaken the demand thesis.

For developers, this policy favors measurable reliability over demonstration quality. Products need evaluations, permission controls, usage reporting, and recovery paths before entering consequential workflows.

For enterprise buyers, it creates a reason to examine supported pilots without lowering technical standards. Compensation should reduce adoption risk, not replace due diligence.

For knowledge workers, the practical effect will appear when agents become embedded in approved workflows. More procurement can widen access, but usefulness depends on trustworthy information and accountable actions.

The durable question is not how many tokens public programs purchase. It is whether each unit helps a provider complete a repeatable task that customers choose to fund again.

Track the first published provider criteria, the first funded local contracts, and the first verified renewals. Together, those signals will show whether MIIT’s token language created an operating market or only a policy headline.