On 9 September 2024, at the main forum of National Cybersecurity Awareness Week, the National Technical Committee 260 on Cybersecurity released version 1.0 of the AI Safety Governance Framework. The framework divides risk into model-inherent safety risk and application safety risk, sets out technical responses and comprehensive prevention measures, and stresses that innovation and safety should be pursued together. It is a methodological, standards-type document without administrative penalties, but it gives regulators, companies and third parties a shared vocabulary.
What the two-category split achieves
Model-inherent risk concerns the model’s own capabilities and defects: uncontrolled generation, fragility to adversarial samples, bias and memorisation carried in training data, theft or tampering of the model. Application risk concerns deployment: misuse after integration into business systems, supply-chain dependence, security gaps in the operating environment, and users over-trusting outputs.
The practical function of the split is allocation of responsibility. Inherent risk is largely borne by the developer; application risk is shared between developer and deployer. After an incident, deciding which category applies and who was in a position to control the risk produces a workable remediation plan more reliably than a general discussion of AI being unsafe.
Technical response and systemic prevention run in parallel
Technical response answers whether a risk can be prevented; systemic prevention answers who manages it and through what process. The former covers content filtering, data cleaning, model evaluation, access control and monitoring. The latter covers governance structure, written policies, staff training, incident response and external cooperation. Neither works alone: technical measures without decision-making mechanisms fail against novel attacks, and policy documents without technical measures fail against a concrete vulnerability.
Governance has to reach named roles
The framework emphasises safety governance, which companies often reduce to a committee charter. A workable structure answers three questions: who makes the final decision on launch, who monitors anomalies during operation, and who speaks externally after an incident. The answers belong to named roles with delegated authority, not to an org chart. Smaller AI companies need not copy the multi-layer committees of large enterprises, but they do need a clear decision-maker and a record of decisions.
Interaction with filings and the standards system
The framework is not itself filing material, but it can serve as the reasoning basis for a safety assessment. The assessments required for algorithm filing and generative AI service filing both need to explain how risks were identified and controlled. Organising materials around the framework’s risk categories reduces inconsistency between filings. The framework also corresponds methodologically to existing national and sector standards; when adopting it, companies should check the version and scope of application, and avoid treating recommendations as mandatory duties.
What companies can prepare
Re-label the existing model inventory by the two risk categories and fill gaps in assessment records. Check whether governance documents specify the launch approval and incident reporting paths. Map technical measures against institutional measures to produce a checkable matrix. That matrix can be used directly in internal audit, customer due diligence and regulatory enquiries.
To turn the framework into executable assessment and filing materials, see our algorithm filing service and cybersecurity compliance service; for training-data processing, see data compliance.
This article is based on version 1.0 of the AI Safety Governance Framework released by the National Technical Committee 260 on Cybersecurity on 9 September 2024, and on public information. It is for reference only and does not constitute legal advice.