China’s AI Safety Governance Framework 3.0: The Board Problem Begins When AI Starts Acting
China’s AI Safety Governance Framework 3.0 shifts enterprise AI governance from chatbot policy to control of agent identity, permissions, data, vendor risk, logging, and accountability
Lewis Ho
China’s latest AI safety framework is not primarily about better answers from chatbots. It is about who bears responsibility when an AI system has an identity, accesses enterprise data, invokes tools, and changes the world outside its prompt window.
On September 14, 2026, China’s National Technical Committee 260 on Cybersecurity (“TC260”), under the guidance of the Cyberspace Administration of China (“CAC”), released the AI Safety Governance Framework 3.0. The Framework marks a material shift in emphasis: from AI that produces content to AI that plans, calls tools, interacts with other systems, and executes tasks. Its premise is simple but far-reaching. Once an AI system can act, governance cannot stop at the quality of its output. It must extend to the chain of authority that allowed the action to occur.
For boards and General Counsels operating across Mainland China, Hong Kong, and Singapore, that distinction matters. A hallucinated answer in an internal research assistant may be a quality-control problem. An agent that exports a customer list, modifies a privileged system setting, initiates a payment workflow, or acts on poisoned instructions is a problem of delegated authority, data governance, cybersecurity, and accountability. It is also, increasingly, a problem that cannot be solved by pointing to a vendor’s AI certification or a generic responsible-AI policy.
Framework 3.0 is a guidance document issued through China’s cybersecurity standardization system, rather than a law or administrative regulation. But dismissing it on that basis would be shortsighted. It is a detailed articulation of regulatory expectations in an environment where the CAC, sector regulators, and enterprise customers will all ask a variation of the same question after an incident: what did the organization know, who approved the system’s powers, and what evidence shows that its controls were real rather than aspirational?
The Strategic Shift: From “Answering Questions” to “Performing Tasks”
The most revealing phrase in Framework 3.0 is its description of AI’s transition from “answering questions” to “performing tasks.” In board-level risk management, this represents a transformation from informational exposure to transactional exposure.
Framework 3.0 explicitly treats agentic AI as a distinct category of application risk. It identifies risks involving identity and permission abuse, planning errors and goal hijacking, unsafe tool invocation, and risks in short-term and long-term memory. It also separately addresses embodied AI, where errors can propagate into factories, warehouses, healthcare environments, transport systems, or other physical settings.
This is a useful reframing for directors. The key governance question is no longer, “Is the model accurate enough?” It is: “What is this system authorized to do when it is inaccurate, manipulated, unavailable, or misunderstood?”
That question exposes why many early enterprise AI controls are insufficient. An acceptable-use policy may prohibit employees from uploading confidential documents into public chatbots. A vendor risk questionnaire may ask whether a supplier encrypts data. Neither establishes whether an internal agent can access a finance drive, whether it can call an external software-as-a-service application, whether an approval request can be bypassed through an exception path, or whether its assigned credential remains active after the underlying use case has been retired.
The governance failure in such cases exposes that the management has allowed a technology capability to become a business authority without defining the decision rights around it.
Singapore’s January 2026 Model AI Governance Framework for Agentic AI reaches much the same operational conclusion. It emphasizes bounding agents’ autonomy and access to tools and data, defining meaningful human approval checkpoints, applying lifecycle controls, and maintaining human accountability. This convergence is important: the engineering controls are becoming broadly recognizable; what differs by jurisdiction is the regulatory context in which those controls must operate.
The Risk Architecture: Beyond Single-Model Vulnerabilities
Framework 3.0 organizes risk into three broad categories: inherent risks, application risks, and derivative risks.
Inherent Risks: Vulnerabilities embedded within foundational components: hallucinations, non-transparent reasoning paths, algorithmic bias, data poisoning, insecure components, runtime compute dependencies, and supply chain disruptions.
Application Risks: Vulnerabilities that manifest when AI is deployed: agent misuse, autonomous cyberattack capabilities, content-security failures, manipulation of AI-generated answers, and disruption of network or physical systems.
Derivative Risks: Macro-level externalities arising from pervasive deployment, including employment disruption, cognitive overreliance, environmental costs, social effects, and loss of human contro.
This risk categorization extends well beyond the scope of a standard Data Protection Impact Assessment (DPIA). A conventional privacy assessment focuses on whether personal data is collected, stored, and transferred under valid legal mechanisms. Framework 3.0 imposes broader governance tests:
Was an open-source model’s upstream dependency tree validated against malicious code insertions before deployment?
Can external threat actors manipulate enterprise retrieval-augmented generation (RAG) indices through poisoned content injections?
Can an autonomous agent be redirected to execute system commands outside its defined operational profile?
Are multi-agent swarms protected against cascading execution failures when an anomalous condition spreads across connected nodes?
These vulnerabilities cannot be addressed within corporate silos. Data privacy may sit with the DPO or General Counsel. Tool permissions may sit with the CIO or CISO. Workforce use may sit with HR. Product decisions may sit with business leadership. Procurement may own the vendor contract. Yet an agentic deployment joins these responsibilities into a single chain of operational exposure.
That is why AI governance committees lose effectiveness when they function merely as advisory working groups. An oversight committee that meets periodically to discuss theoretical AI ethics offers limited risk mitigation. Real risk management requires a formal governance body equipped with explicit corporate authority to approve, mandate controls for, restrict, or decommission high-risk algorithmic workflows.
The Framework’s Appendix 1 provides a useful practical model. It grades AI risk across three dimensions: the importance of the application scenario, the intelligence or autonomy of the system, and the scale of deployment. It then classifies risks into five operational tiers from low through extremely serious.
Enterprises should resist the temptation to translate this into a simplistic model-risk score. An agent may be highly capable but constrained to a low-impact internal task. Another may use a relatively modest model but have access to payroll records, customer communications, trading data, critical infrastructure, or privileged administrator functions. Autonomy without reach is one risk. Reach without reliable supervision is another. Scale converts both into enterprise exposure.
Effective enterprise risk assessments must address four operational criteria, not three:
Decision Authority: What business transactions or automated processes can the agent initiate or approve?
Access Footprint: Which internal databases, external SaaS tools, and functional endpoints can the agent query or modify?
Velocity of Impact: How rapidly can an agent's failure cascade into irreversible financial, legal, or physical damage?
Interruption Mechanics: Who retains the verified authority—and the immediate technical capability—to instantly terminate the agent's active execution?
The fourth question is particularly important. Many organizations describe human oversight in a policy but have never tested it under time pressure. An override that requires a ticket, a manager’s approval, and an unavailable vendor support desk is not meaningful control over a fast-moving system.
The Enterprise Control Architecture: Enforcing Operational Authority
The most operationally useful part of Framework 3.0 is its dedicated agentic AI risk-management appendix. It moves the debate from abstract ethics to the components of real deployment: identity, permissions, instruction handling, planning, tool calling, memory, output, and decommissioning.
For enterprise leaders, this should become an architecture of accountable authority.
Every agent needs a distinct identity
Autonomous agents must not run on shared service accounts or inherit administrative user roles out of convenience. Every deployed agent must possess a unique, verifiable machine identity linked directly to a designated business sponsor, a technical system owner, and a formally defined operational scope. Access credentials must be scoped to specific functions, set to expire dynamically, and engineered for immediate independent revocation without disrupting adjacent systems.
Shared credentials obscure the audit trail. Following a system breach or compliance failure, forensic investigators must clearly determine whether an action originated from a human employee, an integrated enterprise application, an autonomous agent, a compromised vendor package, or an external attacker. When multiple automated agents share execution tokens, root-cause attribution becomes impossible.
A compliant identity registry must record the following parameters for every enterprise agent:
Unique Agent Identifier and Business/Technical Owners
Verified Host Environment and Compute Location
Upstream Foundation Model and Checkpoint Version
Whitelisted Functional APIs and Tool Endpoints
Authorized Data Categories and Access Boundaries
Dynamic Credential Expiration Timelines
Any operational expansion of these capabilities requires a formal authorization update rather than an ad-hoc configuration patch.
Least privilege must be interpreted literally
In agentic workflows, the principle of least privilege functions as an internal business control rather than an isolated IT policy.
An agent that prepares a payment reconciliation should not be able to release a payment. An agent that summarizes HR cases should not be able to modify personnel records. An agent that searches a contract repository should not be able to send external correspondence. An agent that can retrieve information from a customer relationship management system should not be able to bulk export it simply because the underlying API permits it.
Framework 3.0 emphasizes risks of excessive authorization, credential compromise, and unauthorized access. Its treatment of agentic AI is consistent with a central control principle: permissions must be engineered precisely for the discrete, approved micro-task, never inherited from the broad access rights of the human employee commissioning the work.
Boards should ask management for a list of “irreversible acts” by business domain. These commonly include deletion of data, bulk data export, financial disbursement, external publication, privileged system changes, signing or submitting legal documents, and instructions that change production or safety conditions. These acts should be technically unavailable to autonomous execution unless a documented exception has been approved at an appropriate level.
Human oversight is not a reviewer’s signature at the end
Human-in-the-loop controls are frequently misunderstood. The point is not to have a person glance at a dashboard after an agent has completed an action. The point is to place a human checkpoint before the action crosses a threshold that changes legal, financial, security, or personal-data consequences.
The Framework recommends human approval for operations that may cause serious harm and describes the importance of retaining records of approvals. It also stresses that AI should remain under human control.
A well-designed control should answer five questions:
What specific event triggers approval?
Is the approving individual authorized to accept that risk?
What information is presented before approval?
If the human approver fails to respond within a defined time limit, does the system automatically terminate the action?
Are the reviewer's approval, rejection rationale, and timestamp recorded in an immutable, auditable log?
In China-facing environments, the fail-closed requirement is critical. Uncontrolled autonomous actions can trigger immediate regulatory consequences under data security, public content, and cross-border legal frameworks. Where systems operate in human resources, healthcare analysis, banking infrastructure, public utilities, or critical external communications, passive "human-on-the-loop" monitoring is insufficient.
Memory is a data store, not a feature
Agent memory is where the apparent convenience of AI can quietly undermine data governance. A short-term context window may contain a sensitive transaction, legal advice, customer complaint, access token, or employee matter. A long-term vector store may retain patterns that allow the system to reproduce or infer sensitive information long after the original task has ended.
Framework 3.0 targets these vulnerabilities, identifying memory retention, context distortion, semantic poisoning, memory theft, and accidental leakage as distinct agentic threats.
Enterprises must expand their data inventories. Data tracking can no longer stop at primary enterprise databases and file systems. It must catalog agent context memories, vector databases, cache stores, prompt logs, RAG indices, and evaluation benchmark sets. These components represent core governed information assets.
As an absolute control policy, internal secrets, administrative passwords, and bearer tokens must never be written to persistent agent memory.
Sensitive personal information must be systematically masked or cryptographically isolated.
Data retention schedules must be linked directly to specific business purposes, backed by technical controls that ensure complete data purging when an employee leaves, a project closes, or an agent deployment is retired.
Under China's Personal Information Protection Law (PIPL), organizations processing sensitive data, operating automated decision-making engines, or transferring personal information cross-border face strict disclosure, purpose-limitation, and statutory impact-assessment requirements. An enterprise cannot demonstrate compliance with statutory data-handling mandates if it cannot verify where its autonomous agents store, cache, and surface sensitive records.
Logs, rollback, and the difference between evidence and telemetry
Framework 3.0 mandates that system and user execution logs be retained for a minimum of six months. However, compliance requires more than just meeting a storage duration. The audit trail must maintain sufficient fidelity to fully reconstruct the causal decision and execution chain behind any automated action.
A forensically complete audit record must document six core elements:
Originating Identity: The authenticated user or system process that commissioned the task.
Runtime Configuration: The precise version of the model, prompt templates, toolsets, and security rules applied.
Data Context: The external knowledge sources, vector chunks, and system data retrieved for the task.
Execution Steps: Every tool invoked, parameters submitted, and payload returned by connected internal or external systems.
Oversight Actions: All human approvals, override actions, and exceptions logged during processing.
External Outputs: The final data transmitted across external network boundaries or written to enterprise databases.
There is a temptation to collect everything. That is not always wise. Comprehensive logs may themselves contain personal information, commercially sensitive material, or security credentials. They require access controls, tamper resistance, segregation, and retention rules consistent with applicable privacy obligations.
The mature position is therefore not “log less” or “log everything.” It is “log enough to prove governance, protect the logs as regulated data, and preserve them in a form that can be understood by someone other than the original engineering team.”
Version control and rollback are equally important. A commercial AI deployment should be capable of returning to a previously stable version where a safety or compliance regression appears. That sounds obvious, yet AI systems can change through more than a model update. A revised system prompt, a new retrieval source, a newly enabled plugin, a changed access permission, a supplier’s silent routing change, or a revised safety filter can materially alter behavior.
The board should require a release record that captures these dependencies. When an agent changes, management should be able to answer: what changed, why was it approved, what testing was conducted, which systems and populations are affected, and how can the organization reverse it?
This is the paper trail that matters. Not a certificate framed in a boardroom, but the evidence that a specific deployment was governed through its lifecycle.
Content controls and provenance: the China-specific overlay
Organizations familiar with Hong Kong, Singapore, or NIST-style governance will recognize much of Framework 3.0: lifecycle management, risk assessment, least privilege, human oversight, testing, security controls, traceability, incident response, and vendor governance.
Hong Kong’s PCPD Model Personal Data Protection Framework similarly advises a risk-based approach to AI strategy and governance, risk assessment and human oversight, implementation management, and stakeholder engagement. The PCPD has also used compliance checks to examine how organizations apply AI privacy and governance practices in practice.
Singapore’s framework for agentic AI likewise focuses on risk-bounding, meaningful human accountability, lifecycle controls, and transparency. US NIST’s AI RMF, while voluntary, organizes risk management around the continuous functions of Govern, Map, Measure, and Manage.
The difference is not that China rejects these controls. It is that China adds a state-supervised security and content-governance layer around them.
Framework 3.0 explicitly integrates requirements for content compliance, political value alignment, and the prevention of public misinformation. It targets the use of AI systems to influence public discourse, alter search outputs, or conduct coordinated cognitive manipulation. Concurrently, it emphasizes technological sovereignty, hardware supply-chain resilience, and multilateral international governance through the United Nations, explicitly rejecting external export controls and closed-door governance models.
For enterprises, this means that a globally standardized AI control framework cannot simply be copied into Mainland China. The technical architecture may transfer well. The compliance overlay will not.
Operations within Mainland China require specific technical adaptations:
Dual-Layer Synthetic Labeling: Systems must apply both explicit (visible notifications) and implicit (cryptographic markers, metadata watermarks) labels to AI-generated content across creation, transmission, and publication pipelines.
Context-Aware Input/Output Filtering: Organizations must deploy multi-turn guardrails to identify and block prohibited content, national security violations, and value misalignments.
Protected RAG Pipelines: Enterprises must protect knowledge bases against Generative Engine Optimization (GEO) attacks, third-party content poisoning, and malicious external injections designed to manipulate enterprise outputs.
Data Localization and Boundary Controls: System architectures must comply with PIPL, the Data Security Law (DSL), and the Cybersecurity Law (CSL), ensuring personal data and important data remain hosted domestically unless cleared through official statutory transfer channels.
Supply Chain Traceability: Organizations must verify the provenance of models, framework libraries, runtime environments, and agent extensions to protect against supply disruptions and unpatched security vulnerabilities.
Enterprises must maintain clarity regarding legal hierarchy. Framework 3.0 is standard-setting guidance rather than a primary statute. Its operational measures — logging durations, testing procedures, sandbox participation, and watermarking methods — do not constitute standalone legislative penalties on their own. However, in regulatory reviews under the CSL, DSL, or PIPL, these standards define the technical baseline by which supervisory authorities evaluate whether an enterprise implemented "necessary and reasonable" protections.
Cross-Border System Architectures: Navigating Divergent Legal Environments
The most significant compliance challenges emerge when multinational organizations deploy unified AI architectures across Mainland China, Hong Kong, and Singapore.
A regional company may want one enterprise assistant, one contract-review agent, one customer-service knowledge base, and one central security operations model. The operational logic is compelling. The legal logic is less tidy.
Hong Kong’s PDPO-centered model is principally concerned with appropriate personal-data governance, human oversight, transparency, and third-party accountability. Singapore’s governance approach is strongly oriented toward practical accountability, innovation-focused regulatory sandboxes, and international framework interoperability. Mainland China adds PIPL, data-security, cybersecurity, content, and sovereignty considerations, including rules on the cross-border provision of personal information. Under PIPL, transferring personal data outside the Mainland requires executing one of three statutory transfer mechanisms: passing a CAC security assessment, completing standard contract filings, or securing specialized certification. Furthermore, critical information infrastructure operators and organizations handling significant data volumes must store personal information within Mainland China.
The resulting danger is not merely that data is “sent overseas” but an agentic architecture creates multiple invisible transfers: prompt content may route to an external model; embeddings may be generated in a different location; logs may feed a global observability platform; vendor support personnel may access diagnostic records; a safety service may inspect inputs; and a global incident team may retrieve a transcript during an emergency.
A standard vendor assurance stating that "customer data is not utilized for model training" does not resolve these compliance requirements. That statement does not clarify where inference takes place, how long prompts remain cached in memory, which cross-border gateways receive telemetry, who holds administrative access to diagnostic logs, or how the company will produce audit documentation during a regulatory investigation.
Organizations cannot resolve these challenges through post-deployment policies. They require informed architecture decisions prior to deployment:
Fully Localized Deployment: For sensitive use cases involving critical operations, sensitive personal data, or important corporate records, organizations deploy local models hosted in domestic data centers, supported by domestic RAG knowledge bases, segregated system logs, and local engineering support.
Hybrid Partitioned Deployment: For lower-risk operational tasks, organizations route data through automated gateway layers that mask, de-identify, and tokenize all personal data within Mainland China before directing requests through approved cross-border transfer channels.
Restricted Deployment: If a global vendor cannot provide verifiable commitments regarding processing locations, log segregation, and compliance with regulatory audits, the application must not be connected to internal Chinese business systems.
These decisions are not administrative privacy details. They are foundational structural decisions that determine whether an enterprise can maintain lawful operations.
Action Items for the Board
Effective alignment with Framework 3.0 does not call for another passive compliance document. Boards and executive teams should mandate five core operational deliverables:
1. Enterprise Agent Inventory
Maintain a living technical registry of every autonomous agent and automated integration active across the enterprise. The inventory must identify business owners, connected model checkpoints, host infrastructure locations, authorized databases, allowed API tools, user groups, and scheduled compliance review dates.
2. Formally Defined Authority Matrix
Establish clear operational boundaries for all deployed agents. The matrix must define allowed autonomous actions, prohibited system calls, explicit triggers requiring human intervention, designated human approvers, emergency shutdown procedures, and incident response owners.
3. Deployment Evidence Package
Require a complete compliance package before any agentic workflow enters production. The package must include the initial business risk assessment, the Data Protection Impact Assessment (DPIA), vendor and model security due diligence, red-teaming and prompt-injection test results, boundary configuration records, logging protocols, and verified rollback procedures.
4. Direct Vendor Accountability Terms
Update third-party procurement contracts to establish clear operational requirements. Contracts must include binding covenants governing processing regions, model fallback controls, logging integrity, timely breach notifications, and mandatory cooperation during regulatory inquiries. Vendor liability caps should reflect the potential business and regulatory impact of the agent's authorized actions rather than basic software licensing fees.
5. Board Oversight Reporting
Implement recurring executive reporting centered on operational risk indicators: the volume of high-risk agents in production, integrations holding privileged system access, unverified configuration modifications, cross-border data dependencies, operational errors or near-misses, and overdue compliance reassessments.
The underlying message of AI Safety Governance Framework 3.0 is straightforward: AI governance has moved from high-level ethical statements to demonstrable technical and operational control. Enterprise accountability will not depend solely on the sophistication of the models deployed. It will depend on whether leadership established clear operational boundaries, secured the systems and data those models touched, and maintained verified audit records of the human authorities governing their actions.
That is the governance test for the agentic era.
Is China’s AI Safety Governance Framework 3.0 legally binding?
Framework 3.0 is a national standard-setting guidance document issued by TC260 under the guidance of the CAC, rather than a formal statute or administrative regulation. However, it serves as the operational benchmark utilized by Chinese supervisory authorities when assessing compliance under binding laws such as the Cybersecurity Law, Data Security Law, and Personal Information Protection Law. In the event of a security failure or regulatory audit, adherence to Framework 3.0 provides the evidentiary baseline for establishing whether an enterprise implemented reasonable and necessary safeguards.
How do China’s AI governance requirements compare to those in Hong Kong and Singapore?
All three jurisdictions share foundational technical risk controls: lifecycle risk assessments, human-in-the-loop safeguards, privilege minimization, red-teaming, and system auditability. Hong Kong addresses these through a privacy-focused framework under the PDPO; Singapore relies on practical assurance frameworks and collaborative regulatory sandboxes. Mainland China integrates these technical baselines with a comprehensive state-security framework, enforcing explicit content compliance, ideological value alignment, dual-layer synthetic media watermarking, and strict cross-border data transfer limitations.
What technical controls should an enterprise implement before deploying autonomous agents in China?
Enterprises should implement six core technical controls:
Assign distinct machine identities and unique authentication credentials to each agent.
Enforce strict least-privilege scoping across all tool integrations and API access endpoints.
Implement fail-closed human-in-the-loop checkpoints before executing irreversible transactions.
Isolate short- and long-term vector memory to prevent cross-tenant data leaks and memory poisoning.
Retain immutable, auditable execution logs for a minimum of six months.
Maintain technical rollback capabilities to immediately revert agent configurations upon discovering a safety or compliance failure.