The short answer: this document is not a new licensing regime that requires every agent to file, and it is not a compliance certificate. It sets product rules, a security baseline, a tiered governance framework, and 19 typical scenarios for AI agents. The immediate work for companies is to inventory agents, clarify decision authority, add human handover and audit logging, then determine filing and testing duties by industry.
This is a policy analysis based on public sources. It is written for CIOs and IT leaders, AI platform owners, procurement teams, and legal teams. Research cut-off: 24 October 2026. It draws on the Implementation Opinions on the Regulated Application and Innovative Development of AI Agents, issued on 8 May 2026 by the Cyberspace Administration of China (CAC), the National Development and Reform Commission (NDRC), and the Ministry of Industry and Information Technology (MIIT), together with the accompanying press Q&A. It is not legal advice and does not replace an interpretation by the competent authority. Specific obligations depend on current laws, supporting standards, and industry requirements.
Not every agent needs to file. Buying a “compliance certification” does not make you compliant. The real risk sits in permissions, tools, data, and human handover.
What does the implementation opinion actually cover?
It is a joint implementation opinion from three departments. It defines what an agent is, sets out product rules and security risks, establishes tiered governance, and lists 19 typical scenarios. Legal liability still comes from existing laws.
| Dimension | What the document says | How companies should read it |
|---|---|---|
| Issuer | CAC, NDRC, MIIT | Three departments, spanning internet governance, industry, and digital policy |
| Date | 8 May 2026 | Published and being implemented; the public text sets no separate transition period |
| Nature | An implementation opinion, not a law, administrative regulation, or certification standard | Provides a governance framework and product rules; binding duties come from current law and supporting rules |
| Scope | Agent developers, development platforms, distribution platforms, service providers, and enterprises that deploy agents | Neither vendors nor users are bystanders |
| Focus | Technical foundations, standard protocols, product rules, security risks, tiered governance, 19 scenarios, innovation ecosystem | Not a single filing document; covers the full lifecycle from development to use |
Note: the characterization of the document is editorial. If a later supporting document from the competent authority conflicts with this article, the later document prevails.
Which companies are affected?
Developers, development platforms, distribution platforms, service providers, and the enterprises that deploy agents are all in scope. Governance is heavier in sensitive industries than in everyday office work, and users cannot push all responsibility onto the vendor.
| Role | Main responsibility | What to check in procurement or partnership |
|---|---|---|
| Agent developer | Product rules, permission management, behavior control, security testing | Does it explain capability boundaries, failure modes, and security design? |
| Development platform | Toolchain, model access, API calls, extension tool management | Is the model and tool supply chain transparent, and can it be audited? |
| Distribution platform | Platform rules, user agreement, privacy policy, listing management | Responsibility boundaries, delisting mechanism, complaint and handling process |
| Service provider | Service agreement, privacy policy, user rights, risk handling | Data use, human handover, incident response, and liability clauses |
| Deploying enterprise (user) | Scenario selection, data authorization, permission configuration, human review, staff training | Cannot just buy a tool; must establish internal governance and acceptance |
Note: the role split is editorial and does not map one-to-one onto the text of the document. One company may hold several roles at the same time.
How is an agent different from ordinary AI or a chatbot?
The document defines an agent as an intelligent system with autonomous perception, memory, decision-making, interaction, and execution. A system that can call tools, run multi-step tasks, and change external state carries more risk than a chatbot that only answers questions.
| Form | Capability | Main risk | Governance advice |
|---|---|---|---|
| Single-turn Q&A / retrieval | Answers, summaries, translation; no external action | Wrong information, private data in prompts | Content review, data minimization, prompt boundaries |
| Read-only agent | Reads documents, queries databases, calls search | Unauthorized reads, sensitive data leakage | Least privilege, row- and field-level controls, logging |
| Writable agent | Changes records, sends messages, creates tickets | Misoperation, unauthorized write-back, unclear accountability | Approval, idempotency, rollback, human confirmation |
| High-risk / embodied agent | Payments, production control, physical devices, public settings | Personal, property, or systemic risk | Tiered governance, strong audit, final human decision, industry rules |
Note: this layering is editorial advice, not a regulatory classification. Companies should judge by actual tool permissions, data sensitivity, and the consequences of failure, not by the product name.
What key requirements does the policy set for products?
The requirements center on decision authority, user awareness and the final decision right, behavior control, data and personal information protection, supply-chain security, full-lifecycle security management, and tiered governance. This goes beyond the slogan of “safe and controllable”.
| Requirement | Key points in the document | What to ask during procurement |
|---|---|---|
| Decision authority | Separate the user’s own decision, a user-authorized decision, and an agent’s autonomous decision; users have the right to know and the final say; execution must not exceed authorization | Which actions run automatically? Which need confirmation? How is authorization revoked? |
| Behavior control | Rules embedded in the product, behavioral guardrails; behavior in important scenarios must be verifiable and traceable | Can tools and scope be limited? Can logs reconstruct every step? |
| Data and personal information | Guard against data poisoning, privacy leaks, algorithm tampering, system vulnerabilities, and loss of control | Where is data stored, who can see it, is it used for training, how is it deleted? |
| Supply-chain security | Covers development, deployment, application, and maintenance; manages model access, API calls, and extension tools | Who supplies the model, tools, and APIs? Who is liable when something fails? |
| Application-derived risk | Continuous risk identification, warning, and intervention; human-machine review and blocking | How is human handover triggered? How fast is incident response? |
| Tiered classification | Govern by scenario and potential impact; sensitive areas and key industries may require filing, testing, and recall | Which tier are we in? What do industry regulators require? |
| Standards and certification | Build standards for quality evaluation, security assurance, and trusted certification; encourage third-party evaluation | Which standard was the evaluation based on? Who is the certifying body? |
Note: “What to ask during procurement” is editorial, not a regulatory questionnaire. Where specific legal obligations are involved, consult a qualified legal advisor.
Which scenarios may involve filing, testing, or recall?
For sensitive areas and key industries, the CAC works with industry regulators to determine which scenarios may be opened, and existing laws apply for filing, testing, and recall of problematic products. Lower-risk work such as everyday office use relies more on compliance self-assessment, information reporting, distribution platform management, and industry self-discipline.
| Scenario type | Policy framework | Company action |
|---|---|---|
| Everyday office / low risk | Compliance self-assessment, information reporting, distribution platform management, industry self-discipline | Permissions, logs, human review, staff training |
| Customer service / marketing | Existing rules on information services, consumer rights, and personal information protection | Content review, unsubscribe and complaint handling, data minimization |
| Smart manufacturing / production write-back | May involve industrial safety, industrial internet, and data security requirements | Human confirmation, rollback, audit, downtime plan |
| Finance, healthcare, public safety, and other sensitive areas | CAC with industry regulators determines which scenarios may be opened; filing, testing, recall | Ask the industry regulator first, then run a compliance assessment |
| Minors / older users | Addiction prevention, emotional dependence, privacy and rights protection | Age and scenario limits, content review, human intervention |
Note: the document does not provide a unified catalog of which specific scenarios require filing, who files, or what materials to submit. Do not rely on this article alone; check the requirements of industry regulators and local authorities.
What is the minimum a company should do when buying agents?
Start with an inventory of agents and scenarios, then cover five areas: permissions, data, human handover, log auditing, and the supply chain. In sensitive industries, assess filing, testing, or certification against industry requirements before launch.
| Step | What to do | Deliverable |
|---|---|---|
| 1. Inventory | List every agent, scenario, user, tool, and data source | Agent register and scenario notes |
| 2. Tiering | Classify by data sensitivity, tool permissions, and consequences of failure | Risk tiers and approval matrix |
| 3. Permissions | Least privilege, tool allowlists, approval for write actions | Permission matrix and authorization revocation process |
| 4. Human handover | Define failure thresholds, high-risk actions, and escalation paths | Handover rules and on-call roster |
| 5. Log audit | Record input, model, tools, output, and human actions | Traceable logs and retention period |
| 6. Supply chain and contract | Model, API, and tool suppliers; data use; incident liability; exit | Supplier list and contract clauses |
| 7. Evaluation and review | Pre-launch evaluation, post-launch sampling, quarterly review | Evaluation set and review report |
Note: the seven steps are editorial advice, not a mandatory regulatory process. Companies can run them alongside existing cybersecurity, data compliance, and procurement policies.
What are the common misreadings?
Not every agent must file. A certificate does not make a company compliant. The registration platform is still exploratory. Low-risk office use still needs permissions, logs, and human review.
- “Every agent must file.” The document sets tiered governance; only sensitive areas and key industries may involve filing, testing, and recall. Check industry and local requirements.
- “Buy a certificate and you are compliant.” Standards and certification are still being built. A commercial certificate cannot replace legal duties or regulatory requirements.
- “The registration platform is mandatory registration.” The document says “explore establishing an agent registration platform.” It is not a current registration requirement for every company.
- “Low-risk office use is unregulated.” Low risk is not no risk. Permissions, data, logs, human review, and platform rules still apply.
- “Security is the model’s job.” Permissions, tools, data, supply chain, human handover, and incident response are all in scope.
- “Only vendors are bound.” Deploying companies are responsible for their own scenarios, data authorization, and employee use.
Which judgments are still uncertain?
The classification catalog, filing and testing rules, standards and certification, the registration platform, and local enforcement are all still being built. Companies should track official supporting documents and not treat this checklist as a regulatory conclusion.
- The document proposes a standards system, quality evaluation, and trusted certification, but specific standard numbers, evaluation methods, and certifying bodies are not specified in the text reviewed here.
- The specific catalog for sensitive areas and key industries, the filing materials, and the testing procedure still need clarification from industry regulators and local CAC offices.
- The “agent registration platform” is an exploratory direction. When it launches, whether it is mandatory, and how it connects to existing enterprise registration remain uncertain.
- Different regions and industries may draw the boundary of “agent” differently. Companies should judge by actual capability and risk.
- This article is not legal advice. Before launching a specific business use case, legal, security, and industry advisors should assess it together.
What should different companies do next?
Companies already using agents should start with an inventory and a permission audit. Those preparing to buy should write scenario, data, and human-handover requirements first. Platform vendors should close supply-chain and logging gaps. Do not wait for a certification to begin.
- User companies: inventory agents, tools, data, and accounts; convert high-risk write actions to human confirmation; add logging and employee usage rules.
- Procurement and legal: put decision authority, data use, human handover, incident response, audit export, and exit into the contract.
- Platforms and vendors: prepare capability descriptions, permission models, supply-chain lists, evaluation reports, and incident response processes. Do not overstate “compliance certification”.
- Sensitive industries: confirm open scenarios and filing or testing requirements with the industry regulator before planning launch.
If private execution, permissions, and end-to-end tracing are the priority, see LingHarness AI foundation. For office scenarios, see LingWork office agent. Tools can provide permissions, logs, and audit capability, but they do not replace a company’s compliance assessment or human accountability. For implementation and acceptance before launch, see AI agents from POC to production; for operating metrics, see AI agent operations metrics.
FAQ
Is this implementation opinion a law?
No. It is not a law and not a certification standard. It is an implementation opinion jointly issued by the CAC, NDRC, and MIIT, which makes it a policy document. Specific legal liability still depends on current laws and industry requirements, including the Cybersecurity Law, the Data Security Law, the Personal Information Protection Law, and the Algorithm Recommendation Management Provisions.
Do all agents need to file or be tested?
No. The document proposes tiered governance. For sensitive areas and key industries, the CAC and industry regulators determine which scenarios may be opened, and existing laws apply for filing, testing, and recall of problematic products. Lower-risk areas such as everyday office work are governed more through compliance self-assessment, information reporting, distribution platform management, and industry self-discipline. The specific catalog and detailed rules depend on supporting policies.
Is there an official “agent compliance certification”?
The document proposes standards for quality evaluation, security assurance, and trusted certification, and encourages third-party evaluation and mutual recognition of certification results. The standards and certification system are still being built. Companies should not treat a “certification” invented by a commercial body as regulatory endorsement; rely on official standards, testing bodies, and competent authority requirements.
Does a chatbot count as an agent?
The document defines an agent as an intelligent system with autonomous perception, memory, decision-making, interaction, and execution. A chatbot that only handles single-turn Q&A, does not call tools, and does not change external state usually carries less risk than an agent that executes multi-step tasks and writes back to business systems. Companies should still assess risk by actual capability, data, and scenario.
What is the minimum a company should do when buying an agent?
At least five things: list the agents and scenarios; define decision authority and tool permissions; classify data and apply least privilege; design human handover and log auditing; require the vendor to explain the model, API, and tool supply chain and its incident response. In sensitive industries, also assess filing, testing, or certification against industry requirements.
When does the policy take effect?
The document was published on 8 May 2026, and the public text does not set a separate transition period. Implementation depends on supporting standards, the classification catalog, industry regulators, and local requirements. Companies should treat it as published and moving into practice, and should not wait for every detail before inventorying agents and permissions.
This document is not an agent license. It is a governance framework that moves agents from “able to answer” to “able to be accountable”: decision authority, tool boundaries, data security, human handover, and traceability are the work companies most need to do before procurement and launch.
Research method and limitations
This article is a policy analysis and public-source study, not legal advice and not an official interpretation by a regulator. It is based on the Implementation Opinions on the Regulated Application and Innovative Development of AI Agents, issued on 8 May 2026 by the CAC, NDRC, and MIIT, and the accompanying press Q&A. Phrases such as “explore establishing”, “study establishing”, and “encourage” have not yet become binding detailed rules. Companies should rely on current laws, supporting standards, and industry regulatory requirements. The role map, risk tiers, procurement checklist, and action recommendations are editorial and do not constitute a compliance certification or legal conclusion.
Sources and caveats
Research cut-off: 24 October 2026. All sources are official public pages; the original text governs. This article does not promise that any filing, testing, or certification outcome will be granted.
- Cyberspace Administration of China, National Development and Reform Commission, and Ministry of Industry and Information Technology, “智能体规范应用与创新发展实施意见” (Implementation Opinions on the Regulated Application and Innovative Development of AI Agents), 8 May 2026. cac.gov.cn. Key points: agent definition, product rules, decision authority, behavior control, data, personal information and supply-chain security, tiered governance, and 19 typical scenarios.
- Cyberspace Administration of China, “《智能体规范应用与创新发展实施意见》答记者问” (Press Q&A on the Implementation Opinions on the Regulated Application and Innovative Development of AI Agents), 8 May 2026. cac.gov.cn. Key points: background, balancing development and security, tiered governance, the 19 scenarios, and follow-up arrangements.
- gov.cn / Xinhua, “三部门部署智能体规范应用与创新发展” (Three departments deploy the regulated application and innovative development of AI agents), 8 May 2026. gov.cn. Key points: joint issuance by three departments, four sets of measures, and the privacy leakage, unauthorized action, and loss-of-control risks created by high autonomy and high permissions.