On 30 August 2024 the State Council adopted the Regulations on the Administration of Network Data Security at its 40th executive meeting. The text will be published in due course, and the final provisions and effective date will follow that published version. The signal from the meeting is clear enough: network data security moves from departmental rules to administrative regulations, and generative AI training data is placed inside the general network data security framework rather than left on a separate technology-governance track.
Why treat this as an early signal
Legislation and product cycles run at different speeds. Model teams update weekly; regulations move yearly. Adjusting a data pipeline only after the text is published often means missing the window in which the product architecture could still be changed cheaply. Once the executive meeting has passed the regulation, its framework, scope and regulatory division of labour are largely settled, which is enough for companies to review existing arrangements without waiting for every final phrase.
Training data is first of all network data
The Regulations do not create a separate regime for generative AI. Training data is first treated as network data, subject to classification, processing rules and security measures. Any dedicated AI article adds obligations on top rather than replacing them. Understanding this avoids building AI compliance and data compliance as two unrelated sets of documents.
Training-data security is therefore more than lawful sourcing. Collection, labelling, cleaning, de-duplication, synthesis, storage, transmission and sharing each carry risk-control requirements. The question is not whether a company has a provenance statement, but whether these activities are manageable and traceable.
Three pressure points: source, processing and output
Sourcing and licensing. Public scraping, customer-provided data, third-party purchases and self-generated data should be recorded separately, with the licence scope checked against training, fine-tuning and external service. A broken licence chain often surfaces only after launch.
Processing activities. Management of labelling staff, prevention of data poisoning and contamination, cleaning of sensitive information, access control and operation logs form the core of processing security. Outsourced labelling teams must be brought inside the perimeter; data held elsewhere is not therefore someone else’s problem.
Output side. A model may reproduce personal information or protected content from its training data, which requires assessment and handling mechanisms. Output filtering is not a complete answer, but the absence of any mechanism leaves risk to surface at the complaint stage.
Classification and cross-border flows do not stop at the model
AI companies need to determine whether corpora, model parameters and logs contain important data or personal information, and calibrate obligations accordingly. Whether model parameters amount to important data depends on content and impact and cannot be answered in the abstract; interaction records in logs are more often overlooked.
Cross-border scenarios are more numerous than they appear. Exporting training data, calling overseas APIs, remote labelling by foreign teams and storing data on overseas cloud services may all constitute outbound transfer. The analysis starts with the nature and volume of data, then the mode of transmission; a domestic server is not a conclusion.
Platform responsibility travels through the ecosystem
Platform providers have management duties over the models, applications and data processors they host. Open platforms, model marketplaces and API aggregators need to embed data security requirements in onboarding agreements and maintain visibility over partners’ processing. Responsibility does not shift merely because a component is supplied by a third party.
What can be done before publication
Build a training-data register covering source, licence, processing steps, storage location and owner. Embed data security assessment in model iteration rather than treating it as an annual exercise. Add security-incident notice, audit rights, sub-processing limits and deletion obligations to contracts with data suppliers, labelling vendors and cloud providers. Leave time to track implementing rules and standards, since the operative detail will be refined in the published text and accompanying documents.
For a review of training-data pipelines and outbound scenarios, see our data compliance service and cybersecurity compliance service. Definitions are collected in the glossary.
This article is based on public information concerning the adoption of the Regulations on the Administration of Network Data Security at the State Council’s 40th executive meeting on 30 August 2024. The final text prevails. It is for reference only and does not constitute legal advice.